@LangChain：在Interrupt大会上，@Rippling登台分享了他们如何构建并推出Rippling AI——一个用于解答人力资源、薪资和福利问题的自然语言助手。

在 Interrupt 大会上，@Rippling 分享了他们构建并发布 Rippling AI 的过程。Rippling AI 是一个自然语言助手，能够回答关于薪酬、人力资源和福利的问题，覆盖所有记录系统。https://t.co/Jv8vg5RLvG https://t.co/x2khmd2zed

TL;DR： Rippling 通过在统一的员工关系图谱之上叠加一个基于 LangGraph 的扁平化智能体，并利用通用工具、SQL 驱动的数据访问和评估驱动开发，构建并发布了 Rippling AI，这是一个用于 HR 和薪酬任务的自然语言助手。

架构：从嵌套子智能体到扁平智能体

Rippling 的数据围绕一个核心的员工关系图谱组织——这是一个连接 HR、薪酬、设备、福利等信息的统一系统。在此基础上，他们构建了一个 AI 层。最初的智能体栈包含一个顶层助手和许多由不同团队构建的子智能体，这种做法带来了问题：

• 子智能体之间的上下文共享混乱。
• 智能体之间的交接不可预测。
• 跨越多个子智能体的查询经常失败。

解决方案： 他们简化了架构。现在只有一个运行在 LangGraph 上的扁平智能体。所有领域上下文（例如如何处理福利、薪酬、设备）都由产品工程师编写为**声明式技能和标准操作流程（SOP）**注入。用户的消息历史直接就是 LLM 看到的内容——没有额外的抽象层。这简化了系统并提升了性能。

工具：更少、更通用的工具

每个团队最初构建了许多窄领域的工具，导致工具目录庞大且工具选择频繁出错。他们转向了通用、可组合的工具——遵循 Unix 哲学，即做好一件事。例如，不再有单独的 getEmployee、getDevice、getTax 工具，而是有一个统一的 getData 工具，接受实体类型和查询等参数。智能体通过组合这些原语来回答复杂问题。

数据检索：让 LLM 写 SQL

Rippling 的用户会提出大量数据相关的问题——个人或聚合数据。幻觉是不可接受的。他们没有将原始数据塞入 LLM 的上下文，而是：

1. 向 LLM 提供数据的模式（结构）。
2. 让 LLM 生成 SQL 查询。
3. 对核心数据湖执行该 SQL。

这种方法：

• 避免将原始数据放入上下文窗口。
• 利用 LLM 强大的 SQL 能力。
• 减少工具数量和选择风险。
• 自然地处理 HRIS、薪酬和福利的跨表连接。

他们还缓存检索到的数据，以便 LLM 可以迭代——探索、修正错误和优化答案，而无需重新获取数据。这加快了后续问题的响应速度，并降低了成本。

评估驱动开发（EDD）

Rippling 实践评估驱动开发：任何更改（提示、工具、技能）都必须通过一组评估。关键洞见：

• 多次重复评估，因为 LLM 的输出是随机性的。一次评估不够。使用威尔逊置信区间：1/1 通过可能意味着真实通过率低至 20%；3/3 通过仍可能低至 44%。更多重复能提供更高置信度。
• 重复次数取决于：
  • 基线（当前成功率）
  • 期望回退规模（检测 95%→94% 需要比 95%→70% 更多的重复）
  • 对假阳性的容忍度
• 这形成一个权衡三角：成本、不确定性、延迟。只能选两个。

Rippling 的两层评估管道

1. 冒烟评估 – 少量评估、少量重复，每次提交时运行。低成本、低延迟、较高不确定性（能捕捉大的回退）。
2. 健康评估 – 大量评估、大量重复，每天两次针对一批提交运行。较高延迟、较低不确定性。通过健康评估后才能部署到生产环境。

他们还构建了自定义工具用于探索生产数据，以及一个包含真实 PII 数据的保险库工作区。从该保险库生成合成测试数据，避免在评估中暴露客户数据。

关键要点

1. 保持智能体扁平。 移除试图协调子智能体的胶水代码。随着模型改进，让 LLM 处理复杂性。
2. 构建通用、可组合的工具。 当数据可用时，让 LLM 写 SQL 而不是构建许多狭窄的 API 调用。这更强大，并减少错误发生面。
3. 评估优先。 测试每一次更改。即使直觉很强，评估也会揭示真相。接受你只能在成本、不确定性、延迟中优化两个。

来源： @LangChain：在 Interrupt 大会上，@Rippling 分享了他们如何构建并发布 Rippling AI（https://www.youtube.com/watch?v=3lb_4OEOykc）