用 AIP Evals 将 AI 投入运营：Chad 与 Colton 谈智能体评估

摘要

Palantir 架构师 Chad Walquist 与前向部署工程师（FDE）、隐私与公民自由团队成员 Colton 对话，主题是 AIP Evals——把生成式 AI 应用从原型推进到生产的关键工具。Colton 解释：Evals 是 AIP 全部工具链（AIP Logic、Agent Studio、TypeScript/Python 函数）中集成的测试与评估套件，专门应对生成式 AI 模型"强大但笨拙、易错"的特性。它本质上是把经典机器学习的评估思想与软件工程的单元测试实践"联姻"，用来检验非确定性（nondeterministic）的随机函数。

演示围绕 Onyx 公司的库存管理应用展开：订单履行流程中，智能体在每一步与人类协同，把需要判断的场景明智地委派给用户。核心洞察是"培训 AI 智能体就像培训刚毕业的聪明孩子"——它没有你的机构知识，需要时间、反馈与护栏；Evals 就是那些护栏。一个精彩的案例展示了非确定性：两个几乎相同的 10cc 注射器订单，一个智能体找到了已批准的替代原则（20cc 可用），另一个没有——两次执行结果不同，这正是 LLM 的本质。

反馈闭环是 Evals 的心脏：用户在界面上点赞/点踩、选择本体论定义的标签或输入自由文本；反馈工作台把"未标记→已标记→测试用例→训练样本"串成状态机；一键把失败反馈加入评估套件，用"LLM 作裁判"计算准确率；再用另一个智能体做失败分析、提出提示词修改建议；最后用"实验模式"对提示词 × 模型做网格搜索——示例中 GPT-4.1 加结构化清单提示词把准确率从 0% 提升到 50%。没有这套工具，智能体只是玩具。

正文

一、评估的本质：从确定性到随机性

Colton 在 Palantir 快两年了，如今协助领导 AIP Evals 工作，同时是隐私与公民自由（PCL）团队成员。什么是 Eval？它本质上是与 AIP 全部工具链（用于构建生成式 AI 应用：AIP Logic、AIP Agent Studio、普通 TypeScript 或 Python 函数）集成的测试与评估套件，让你以专门设计的方式测试和评估这些应用，处理这些"强大但笨拙、易错"的生成式 AI 模型带来的所有挑战。Chad 点出本质：这是评估非确定性（nondeterministic）随机函数的工具——我们在确定性经典机器学习上一直有 ML Ops 工具，但生成式 AI 与智能体时代的问题是：我怎么知道这东西做对了？它什么时候在幻觉？

Colton 补充：AI 智能体尤其有趣，它需要经典机器学习系统的测试评估与软件工程单元测试实践的融合——AIP Evals 的产品起源正是填补这个空白。Chad 的思维模型：在智能体流程中，Eval 就是"我的业务流程期望达成的结果"，通过工具确定这些智能体是否在朝那个业务结果推进。Colton 确认：可以把评估或特定测试用例连接到业务 KPI，还可以对智能体执行过程中的链式计算做更细粒度的中间评估。

二、人机协同与"新员工"培训

谈到人机协同（human-AI teaming）与评估的关系，Colton 说：在生产级用例的推广中，最有效的评估是传统单元测试与用户反馈的混合——用户往往要真正看到、交互、把它放进运营工作流语境后，才知道"好的总结"长什么样。所以必须建立反馈回路：让用户标记什么时候特别对或特别错，并把反馈运营化、转化为评估或改进工作流的方法。

演示应用是 Onyx 的库存管理：智能体面板展示从客户邮件/语音邮件进单，到库存分配、配对卡车、备货发运的完整流程。智能体在每个环节协助，但不会全盘自动化——在合适的时候把事委派给用户、智能路由、在客户需要行动时暂停自动化。Chad 的框架："AI 做平凡之事，人类做非凡之事，1 加 1 等于 3。" Colton 则抛出"新员工"类比：你雇了一个很聪明的应届生，但他对你的业务流程、机构知识零上下文——那些知识在某人脑子里，甚至不在系统里。培训这个"恰好是 AI 智能体"的新员工需要时间、反馈和护栏：给他一点绳子，他做错了，纠正他、给他反馈。Evals 就是那些护栏——教会智能体、随时间融入机构知识，最终从原型走到生产。

三、透明的推理链：当智能体出错时

演示中，库存分配智能体有 101 个订单被标记为需要人工。两个相邻订单都是 10cc 注射器：上面的智能体说"10cc 可用 20cc 替换，依据已批准原则 OF-012"——这是编码在本体论（Ontology）里的领域知识；下面几乎相同的订单，智能体却说"需要关于 10cc 已知替代材料的额外信息"——它没有找到那条原则。同一个流程，两次执行，结果不同——这就是非确定性的本质。

但关键在透明度：点击进入 AIP Logic 可以看到智能体的完整动作日志。钻入那个错误输出：条件分支里的那次 LLM 调用，提示词要求先使用库存再分配模型找替代来源；找不到（如之前案例中的 DC-14）就进入方案二——语义搜索文档并做检索增强生成；方案二也没有结果，则使用原则对象工具查找已批准的原则。成功的案例正是从原则对象（本体论上下文）里拿到的；失败的案例里，LLM 执行了前两步却在第三步"放弃了"。Chad 强调：这种 AI 加本体论的透明性与可审计性，不仅让你调试，也让业务用户理解"答案怎么来的"——数据的出处与谱系建立信任。就像你盘问新员工"你为什么这么做、你看了什么数据、把电子表格发我"——这一切透明地摆在这里。这些不是黑箱。

四、反馈工作台：从拇指朝下到测试用例

反馈入口就在智能体最终评论旁边：点赞/点踩。点击点踩后，还有更多反馈形式：本体论定义的标签（比如"没有咨询原则"），以及自由文本——用户说"应该咨询原则并找到 OF-012"。用户有多种方式表达对输出的"品味"。这些反馈去哪了？Colton 强调很多应用的点赞/点踩是"对虚空喊话"；而 Palantir 有完整流程：反馈工作台是面向开发者的治理应用，四列状态把反馈从"未标记"推进到"已标记"，再到"测试用例"或 LLM 的"训练样本"——这是反馈回路的状态机，重点在于尽快闭环。

点击一条反馈，得到全息视图：用户的文字、被评论的输出、以及智能体执行日志——可以做错误分析：哪里对了、哪里错了。还有 AI 帮手：AIP 标签提案智能体自动建议把反馈关联到现有标签，一键接受。然后一键"添加为测试用例"——反馈被标记，动态拉入 AIP Evals 评估套件：左侧是测试用例（当前 6 个：客户订单输入加用户非结构化反馈），右侧是评估器设置——内置的"LLM 作裁判"评估器检查用户反馈的关键点是否被 AI 输出满足。有趣的是，这个评估器本身也是逻辑函数，而它也有自己的 Evals 套件——"一路向下都是评估"。运行评估套件：执行全部测试用例、计算准确率指标，然后聚合视图、测试用例视图、钻入 agent trace 做错误分析——不止准确率，还有时间（即潜在成本）与交互性能，所有你在意的东西。

五、实验模式：提示词 × 模型的网格搜索

规模化之后，几十上百甚至上千个测试用例（某些智能体确实有上千个），人工逐个调试不可行。Evals 可以把整套结果写入 Foundry 数据集，Colton 在上面构建了一个智能体自动化来做调试：失败的评估显示在左侧，另一个基于 AIP Logic 的智能体做失败分析——检查 trace、看指标、提出"哪里错了、怎么修"的建议，输出是提示词提案（比如"优先考虑原则"或"改为 LLM 必须遵循的结构化清单"）。Chad 惊叹"智能体检查智能体——全是智能体"。但人类的 gut check 仍然必要：回到 Evals 看失败、核对智能体的输出、判断提示词是否真的更好。

最终验证要靠实验模式（experiments）：把提示词与模型当作超参数组合，做网格搜索。演示中对比 GPT-4.1、Claude Sonnet 4.1 等模型与三版提示词（生产原版加两个提案）；分组查看结果：GPT-4.1 表现最佳，且"GPT-4.1 加结构化清单提示词"把准确率从 0% 提升到 50%——50% 不算好，但失败的测试用例会再次喂回智能体调试流程，产生新的提示词提案，循环往复直到闭环。Chad 总结：从原型与传闻级用例，到几百个智能体并行自动化整个业务流程（保险等行业已在做），没有这类工具到不了生产——"没有它，那只是个玩具"。Colton 最后说：LLM 是强大工具，但要让它落地生产，需要大量的爱、与用户的迭代、围绕开发的结构化流程——"从原型到生产，这是唯一的路径"。