FDE Times 数据在招 FDE 职位 863▼55 近 7 天在招职位数的变化(同口径比较):不计入本周新开始追踪的公司的职位近 7 天新增 71在招公司 181支持远程 24%美国薪资中位数 $200k招聘最多 Palantir 95
ENVI

前线部署工程师(FDE)的专业媒体

书籍与课程

一门停在生产环境门口的护栏课

DeepLearning.AI 与 GuardrailsAI 的 1 小时 42 分钟课程,notebook 课时值得学,护栏服务化部署要课外补。

分享微博

要点速览

  • DeepLearning.AI 与 GuardrailsAI 合作的入门短课,由 Shreya Rajpal 讲授,只需基础 Python
  • 最大价值在于基于 NLI 的幻觉检测,以及围绕每个客户的特定风险构建护栏的思路
  • 课程止步于 notebook,为客户部署前请先读 Guardrails Server 的相关资料
流程图:客户的问题先经过 Input Guard(过滤账号),再进入 LLM + RAG,然后经过 Output Guard(用 NLI 将回答与检索到的文档比对),最后才到达客户。Output Guard 以橙色突出显示,表示这是最值得反复学习的部分。
在银行聊天机器人的例子中,Input Guard 过滤客户可能粘贴进来的账号,Output Guard 在回答发出前用 NLI 进行检查。来源:DeepLearning.AI 与 GuardrailsAI 的 Safe and reliable AI via guardrails 课程。

一个客服聊天机器人回答流畅,内部文档引用准确,却突然夸起了竞争对手的产品。对企业客户来说,这样的回答出现一次,就足以叫停整个项目。DeepLearning.AI 的课程 Safe and reliable AI via guardrails 正是为应对这类问题而设计的。

课程由 GuardrailsAI 参与制作,讲师是该公司创始人兼 CEO Shreya Rajpal。课程页面显示最近一次更新是 2026 年 7 月 17 日。全长 1 小时 42 分钟,包含 10 个视频、7 个代码示例和一次计分测验,面向初学者,只要求基础 Python。

对前线部署工程师(FDE)而言,这门课的价值在于:它不止于让检索增强生成(RAG)聊天机器人跑起来,还教你如何让它安全到可以向真实用户开放。课程的大部分内容都值得花时间。唯一没讲的是把护栏带进生产环境,这部分需要自己去补。

根源在概率,不在提示词

课程用一句话点明问题:大模型(LLM)的输出本质上是概率性的。由此,它把护栏定义为内置在 AI 应用中的安全机制和校验工具。这个框架值得记住,因为它决定了你该向客户承诺什么。

设想一家银行的聊天机器人每天回答 1,000 个问题。假设提示词好到只有 2% 的回答是编造的,每天仍有 20 位客户拿到错误信息。

继续打磨提示词可以压低这个数字,但无法降到零。你能卖给客户的,是一层检查机制:在客户读到之前,把这 20 个回答拦下来。

值得带给客户的三个思路

第一个思路是在两端都设护栏。开源框架 Guardrails AI 围绕 Input Guard 和 Output Guard 构建,用于检测、量化和缓解风险。

Guardrails Hub 提供现成的校验器,多个校验器可以组合进一个护栏。在银行的例子里,Input Guard 负责过滤客户误粘贴到对话框里的账号,Output Guard 则在每个回答发出前进行检查。

第二个思路,也是最值得反复看的一课,是用自然语言推理(NLI)检测幻觉。在 RAG 场景下,需要检查的是回答中的每一条陈述是否有刚检索到的文档作为依据,而不只是模型有没有给出回答。

学会把这种比对自动化,是一项可以带到任何 RAG 项目中的技能,即便项目不用 Guardrails AI。

第三个思路是围绕每个客户的特定风险构建护栏。课程分别用单独的课时讲解如何让聊天机器人不跑题、防止个人身份信息(PII)泄露,以及拦截对竞争对手的提及。

Hub 上列有 65 个校验器,其中 Detect PII、Toxic Language 和 Competitor Check 与这些课时一一对应。做客户需求调研时,可以问客户:哪种回答会让法务部门找上门?你需要的校验器清单就在他们的答案里。

可以快速略过的部分

如果你做过 RAG,开头讲 RAG 失败模式的几课会很眼熟,可以倍速观看。但不要跳过构建第一个护栏的那一课,那里讲的是这个库如何组织校验器。最后的测验适合自查,不值得写进简历。

真正的缺口在别处。动手项目是一个完全在 notebook 里运行的 RAG 客服聊天机器人。而在客户现场,护栏必须与多个团队共用的现有系统一起运行。

这时问题就不再是护栏能否发现错误。你必须约定:每个校验器最多能增加多少响应时间;护栏误拦时由哪个团队负责;护栏本身出故障时,系统是拦下所有回答,还是全部放行。

学完之后读什么

建议按以下顺序:先看完课程,再读 GitHub 上 guardrails-ai 仓库的 README,弄清 Input Guard 和 Output Guard 在代码中的位置。接着浏览 Hub,在自己写校验器之前先了解已有哪些现成的。最后,读一读 2024 年 7 月发布的 0.5.0 版本中关于 Guardrails Server 的公告。

Guardrails Server 可以把护栏作为服务运行,并提供与 OpenAI SDK 兼容的端点。对 FDE 来说,这是最有价值的一点:客户应用如果已经在调用 OpenAI 风格的 API,几乎不用改调用代码,就能让请求经过护栏。

提出方案之前还要做一件事:在客户的真实数据上测出每个校验器增加的延迟,因为每个回答都跑一遍 NLI 并不是没有代价的。

还有一个能省下几周时间的法律细节:这个库采用 Apache-2.0 许可证。客户采购团队问起开源许可时,你可以当场回答。

把课程变成简历上的一行

一张不到两小时课程的证书说服不了任何人。能打动招聘经理的是一个小仓库:基于公开文档集的 RAG 聊天机器人,带有拦截 PII 的 Input Guard 和用 NLI 检测幻觉的 Output Guard,再附一张表,列出被拦截的回答数量和原因。

浏览 FDE 招聘启事时,留意 guardrails、AI safety、PII 或 production LLM 这类字眼。启事里出现这些词,这样一个仓库就是你做过他们所需工作的直接证据。

简历上要写成果,例如“为 RAG 聊天机器人构建护栏层,拦截 PII 泄露和缺乏依据的回答”,这比课程名称更有分量。

学完这门课,你会知道如何在 notebook 里拦住错误。而把同样的护栏层放进客户系统,在真实数据上运行且不拖慢产品,这部分没有哪门课能替你完成。

这篇文章对你有帮助吗?

4 个信源
路线图上的下一篇 · 阶段 3: AI 应用Anthropic的computer use课,正题仅10分钟前五课的 API 基础才是重点;从可运行的演示到客户机器上的 Agent,这门课几乎没有涉及。