TensorZero 评估实战:从俳句生成到数据集构建与 LLM Judge 对比评估

TensorZero 评估实战:从俳句生成到数据集构建与 LLM Judge 对比评估 TensorZero 评估实战从俳句生成到数据集构建与 LLM Judge 对比评估【免费下载链接】tensorzeroTensorZero is an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation.项目地址: https://gitcode.com/GitHub_Trending/te/tensorzeroTensorZero 是一个开源的 LLMOps 平台将 LLM 网关Gateway、可观测性、评估Evaluation、优化与实验统一到一个工作流中。本文以仓库中的 examples/evaluations/tutorial 教程为骨架完整演示一条定义函数与变体 → 配置多种评估器 → 批量生成样本 → 构建数据集 → 用 CLI 与 UI 运行评估 → 对比不同变体效果的评估闭环。读完本文你将掌握 TensorZero 评估体系的核心配置语法exact_match 与 llm_judge、Evaluations CLI 的完整用法以及如何在 TensorZero UI 中直观对比不同模型变体的质量差异可直接迁移到自己的 LLM 应用评测流程中。教程概览与目录结构本教程位于仓库的 examples/evaluations/tutorial 目录其核心是一个俳句Haiku生成与评估示例定义一个write_haiku函数提供gpt_4o与gpt_4o_mini两个变体并为它配置精确匹配exact match与多种 LLM 裁判LLM judge评估器。整个目录结构如下examples/evaluations/tutorial/ ├── config/ │ ├── tensorzero.toml # 函数、变体与评估器的核心配置 │ └── functions/write_haiku/ │ ├── user_schema.json # 用户输入 JSON Schema │ ├── user_template.minijinja # 提示词模板 │ └── evaluators/ │ ├── valid_haiku/system_instructions.txt │ ├── metaphor_count/system_instructions.txt │ └── compare_haikus/system_instructions.txt ├── data/nounlist.txt # 100 个俳句主题词来源 ├── docker-compose.yml # Gateway / UI / ClickHouse / Evaluations 编排 ├── main.py # 批量生成 100 首俳句的脚本 ├── pyproject.toml # Python 依赖tensorzero 客户端 └── uv.lock需要说明的是README 中提到的.env.example示例文件并未包含在当前仓库快照中稍后我们按 docker-compose.yml 中实际引用的环境变量手动创建.env即可。环境准备Docker、Python 与 OpenAI API Key开始之前需要满足以下前置条件与 README 一致安装 Docker用于启动 Gateway、UI、ClickHouse 与 Evaluations 服务安装 Python 3.10教程脚本与客户端运行环境见 pyproject.toml 中的requires-python 3.10安装 Python 依赖推荐使用uv包管理器在 examples/evaluations/tutorial 目录下执行uv sync核心依赖只有一个tensorzeroPython 客户端生成 OpenAI API KeyOPENAI_API_KEY因为两个俳句变体与所有 LLM judge 变体都指向openai::gpt-4o/openai::gpt-4o-mini模型。然后创建.env文件写入 OpenAI 凭据OPENAI_API_KEYsk-...这一步之所以必须是因为 docker-compose.yml 中 gateway 与 evaluations 两个服务都对OPENAI_API_KEY做了强校验${OPENAI_API_KEY:?Environment variable OPENAI_API_KEY must be set.}未设置时容器启动会直接失败。如果还使用了其他模型提供方如 GCP Vertex同样在此追加对应凭据。一键启动基础设施docker compose up在 examples/evaluations/tutorial 目录下执行docker compose up它会拉起三个默认服务该 compose 文件为学习用途做了刻意简化生产部署请参考官方部署指南服务镜像端口作用clickhouseclickhouse:lts8123HTTP/ 9000Native开发用 ClickHouse存储推理记录、数据集与评估结果数据卷clickhouse-data持久化gatewaytensorzero/gateway3000TensorZero 网关以--config-file /app/config/tensorzero.toml加载配置通过TENSORZERO_CLICKHOUSE_URL连接 ClickHouseuitensorzero/ui4000TensorZero 管理界面通过TENSORZERO_GATEWAY_URL: http://gateway:3000连接网关编排上依赖关系已自动处理gateway 等待 ClickHouse 健康wget ... :8123/ping探活ui 等待 gateway 健康/health探活。另外还有一个evaluations服务镜像tensorzero/evaluations默认不会启动——它带有profiles: [evaluations]标记只在显式运行时被拉起这正是后续用 CLI 跑评估的入口。网关健康检查地址为http://localhost:3000/healthUI 地址为http://localhost:4000启动完成后即可打开 UI 浏览。理解评估对象write_haiku函数与两个变体评估的第一步是定义被评估的函数。config/tensorzero.toml 中定义了write_haiku[functions.write_haiku] type chat user_schema functions/write_haiku/user_schema.json [functions.write_haiku.variants.gpt_4o_mini] type chat_completion model openai::gpt-4o-mini user_template functions/write_haiku/user_template.minijinja [functions.write_haiku.variants.gpt_4o] type chat_completion model openai::gpt-4o user_template functions/write_haiku/user_template.minijinjatype chat声明这是一个聊天型函数user_schema指向 user_schema.json规定用户输入必须是一个包含topic字符串字段的对象required: [topic]且additionalProperties: false网关据此对输入做结构校验两个变体gpt_4o与gpt_4o_mini都声明为chat_completion分别路由到 OpenAI 的gpt-4o与gpt-4o-mini共享同一个提示词模板 user_template.minijinja内容只有一行Write a haiku about: {{ topic }}模板采用 MiniJinja 语法{{ topic }}会在推理时被用户输入中的topic字段填充。两个变体共享函数与模板、仅模型不同这为后面的同配置、不同模型对比评估创造了条件——评估结论可以直接归因于模型本身的差异。定义评估器精确匹配与 LLM 裁判tensorzero.toml 的 EVALUATORS 段落在write_haiku函数下挂载了四个评估器覆盖了 TensorZero 两类核心评估器类型。1.exact_match零成本精确匹配[functions.write_haiku.evaluators.exact_match] type exact_matchexact_match无需模型调用直接比对输出与参考答案是否完全一致常作为快速、确定性的基线指标。从源码结构看crates/tensorzero-core/src/config/rehydrate.rsTensorZero 的评估器类型体系还包括Regex、ToolUse、TypescriptTypeScript 裁判与LLMJudge等exact_match只是其中最简单的一种。2.valid_haiku布尔型 LLM 裁判[functions.write_haiku.evaluators.valid_haiku] type llm_judge output_type boolean optimize max [functions.write_haiku.evaluators.valid_haiku.variants.gpt_4o_mini_judge] type chat_completion model openai::gpt-4o-mini system_instructions functions/write_haiku/evaluators/valid_haiku/system_instructions.txt json_mode strict active true [functions.write_haiku.evaluators.valid_haiku.variants.gpt_4o_judge] type chat_completion model openai::gpt-4o system_instructions functions/write_haiku/evaluators/valid_haiku/system_instructions.txt json_mode strict关键点type llm_judge表示由另一个 LLM 充当裁判output_type boolean声明裁判输出为布尔值是否合格optimize max声明该指标越大越好后续优化功能如 GEPA会以它为优化目标裁判本身也是chat_completion变体可以配置多个裁判变体并指定active true来选定默认裁判这里gpt_4o_mini_judge为激活态gpt_4o_judge未标activejson_mode strict强制裁判以严格 JSON 模式输出结构化结果。裁判的系统指令见 valid_haiku/system_instructions.txtEvaluate if the text follows the haiku structure of exactly three lines with a 5-7-5 syllable pattern, totaling 17 syllables. Verify only this specific syllable structure of a haiku without making content assumptions.即只校验三行、5-7-5 音节、共 17 音节的形式结构不做内容层面的假设——这保证了判定标准的客观性。3.metaphor_count浮点型 LLM 裁判[functions.write_haiku.evaluators.metaphor_count] type llm_judge output_type float optimize max [functions.write_haiku.evaluators.metaphor_count.variants.gpt_4o_mini_judge] type chat_completion model openai::gpt-4o-mini system_instructions functions/write_haiku/evaluators/metaphor_count/system_instructions.txt json_mode strictoutput_type float表示裁判输出一个浮点数。其指令 metaphor_count/system_instructions.txt 非常简短How many metaphors does the generated haiku have?即让裁判统计生成的俳句中包含多少隐喻用于评估创意维度。4.compare_haikus带参考输出的 LLM 裁判[functions.write_haiku.evaluators.compare_haikus] type llm_judge include { reference_output true } output_type boolean optimize max [functions.write_haiku.evaluators.compare_haikus.variants.gpt_4o_mini_judge] type chat_completion model openai::gpt-4o-mini system_instructions functions/write_haiku/evaluators/compare_haikus/system_instructions.txt json_mode strict与前面不同这里多了include { reference_output true }评估时会把数据集中预先保存的参考输出reference output一并注入裁判上下文让裁判进行生成结果 vs 参考结果的对照评判。其指令 compare_haikus/system_instructions.txtDoes the generated haiku include the same figures of speech as the reference haiku?即判断生成的俳句是否使用了与参考俳句相同的修辞手法——这是典型的有参考对比型评估器适用于需要与标注数据对齐的质检场景。生成样本数据运行main.py批量产出 100 首俳句评估需要数据集而数据集来自真实推理。执行python main.pymain.py 会通过 TensorZero Python 客户端向网关发起 100 次推理流程如下固定随机种子random.seed(0)保证每次运行结果可复现用AsyncTensorZeroGateway.build_http(gateway_urlhttp://localhost:3000)建立指向网关的异步 HTTP 客户端从 data/nounlist.txt 读取主题词列表随机打乱后取前 100 个作为俳句主题以asyncio.Semaphore(10)将并发限制在 10创建 100 个任务并发调用t0.inference(function_namewrite_haiku, variant_namegpt_4o, input{messages: [{role: user, content: [{type: text, arguments: {topic: topic}}]}]})生成俳句最后asyncio.gather(*tasks)汇聚结果。注意请求体的结构content列表中的元素是带arguments的文本块topic会被模板引擎填入user_template。这些推理会被网关自动写入 ClickHouse成为后续构建数据集的素材。这些推理数据本身就是评估的数据池——评估数据集就是从这些已产生的推理记录中筛选出来的。在 UI 中构建数据集推理完成后打开 UIhttp://localhost:4000按以下步骤构建评估数据集导航到Datasets页面选择Build Dataset直达地址http://localhost:4000/datasets/builder新建数据集命名为haiku_dataset选择write_haiku函数metric 选择None不需要显式指标数据集输出dataset output选择Inference直接使用推理输出作为数据集内容。构建完成后haiku_dataset就包含刚才生成的 100 首俳句及其输入主题可供评估运行使用。选择 Inference 作为输出意味着评估对象是真实线上推理的产出而非人工构造的标注数据。运行评估一Evaluations CLI 评估gpt_4o变体TensorZero 提供独立的 Evaluations CLI 工具对应 crates/evaluations 与 Docker 镜像tensorzero/evaluations一条命令即可对指定函数、指定变体、指定评估器组合发起批量评估docker compose run --rm evaluations \ --function-name write_haiku \ --evaluator-names valid_haiku,metaphor_count,exact_match,compare_haikus \ --dataset-name haiku_dataset \ --variant-name gpt_4o \ --concurrency 5逐项解读参数参数取值含义--function-namewrite_haiku被评估的函数--evaluator-namesvalid_haiku,metaphor_count,exact_match,compare_haikus逗号分隔的评估器名列表本次同时跑 1 个精确匹配 3 个 LLM 裁判--dataset-namehaiku_dataset评估所用的数据集--variant-namegpt_4o被评估的模型变体--concurrency5并发度控制同时执行的评估请求数docker compose run --rm evaluations会临时拉起带evaluationsprofile 的服务容器--rm表示任务结束后自动清理容器内部加载 config/tensorzero.toml 与 ClickHouse 连接配置TENSORZERO_CLICKHOUSE_URL对haiku_dataset中的每条数据运行gpt_4o变体并逐项套用四个评估器结果写回 ClickHouse。exact_match直接比对输出valid_haiku、metaphor_count、compare_haikus则由配置中active true的gpt_4o_mini_judge裁判变体以严格 JSON 模式给出结构化判定。运行评估二UI 评估gpt_4o_mini变体并对比结果CLI 评估完gpt_4o后再用 UI 评估gpt_4o_mini从而横向比较两个变体在相同数据集、相同评估器下的质量差异导航到Evaluations页面http://localhost:4000/evaluations选择New Run发起一次针对gpt_4o_mini变体的评估运行数据集与评估器沿用haiku_dataset及同一组评估器保证变量可控评估完成后在下拉框中选中之前那次gpt_4o的评估运行UI 会将两次运行的结果并排对比。对比视角可以落在valid_haiku的合格率布尔型、越大越好、metaphor_count的平均隐喻数量浮点型、越大越好、exact_match的精确命中率以及compare_haikus的修辞一致性通过率。由于两个变体共享同一函数、模板与评估器任何差异都可归因于gpt-4o与gpt-4o-mini本身的能力差距——这正是变体对比评估的核心价值用数据而非主观印象决定哪个模型方案上线。小结与延伸本教程走完了 TensorZero 评估的完整闭环定义函数与变体 → 配置exact_match与llm_judge布尔/浮点/带参考输出三种形态→ 批量推理生成样本 → UI 构建数据集 → CLI 与 UI 双通道运行评估 → 变体间结果对比。四个评估器分别对应了确定性基线、形式合规、创意量化、参考对照四类常见评测诉求而其output_type/optimize字段同时为 TensorZero 的优化与实验能力如 GEPA、DICL 等提供了可直接消费的指标目标。如果希望继续深入可以阅读 crates/evaluations 了解 CLI 的完整实现与更多参数如数据集筛选、指标聚合查看 crates/tensorzero-core/src/config 中评估器配置的解析与校验逻辑UninitializedEvaluatorConfig/StoredEvaluatorConfig的各类评估器分支或参考 docs/evaluations 下的推理评估与工作流评估文档将同一套评估机制扩展到更复杂的多步骤工作流上。【免费下载链接】tensorzeroTensorZero is an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation.项目地址: https://gitcode.com/GitHub_Trending/te/tensorzero创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考