GPT-4 也会写出跑不通的 SQL，她给大模型装了一层护栏

2023 年 5 月，一个叫 Guardrails AI 的 Python 库上线没几周，GitHub 星标涨到 1200。做它的人叫 Shreya Rajpal，前苹果机器学习工程师、Predibase 创始工程师，更早之前在自动驾驶公司 Drive.ai 做感知。

主持人 Nathan Labenz 是被上一期嘉宾、Fixie.ai 的 CEO Matt Welsh 安利来的，录完上一期马上约了她。理由很直接：所有做大模型应用的人都被同一个问题折磨过，模型不总听指令，偶尔彻底跑偏。

Nathan 自己算过一笔账。他的公司 Waymark 做视频生成，一年半前微调 GPT-3，才勉强让模型学会写视频脚本；现在 GPT-4 零样本就能干，而 GPT-3.5 便宜大约 20 倍，只是不太稳。

便宜 20 倍的模型就在货架上，问题只剩一个：你敢不敢用。这期节目讲的就是怎么敢。

提示词不是万能旋钮

Shreya 做这个项目，最初是解决自己的痛。2022 年底她拿大模型做小应用，跟文档聊天那种，当时 Twitter 上最火的玩法。做的时候她就发现，demo 很惊艳，作为开发者反复测试，输出时好时坏，没法稳定复现。

她把这个麻烦拆成两层。

第一层，跟传统机器学习不一样，这个模型你没训练过。效果不好，你没法往里加数据，没法针对自己的场景调优。

第二层，开发者手里能拧的旋钮只有一个：提示词。大家怎么让模型听话？往提示词里堆字，加感叹号，一遍遍求它。

这些语言模型非常强大，但本质上高度随机，很难控制。

自动驾驶的经历给了她现成思路。感知模型是深度学习，输出喂给基于规则的决策系统，两个系统中间的接口必须稳健，感知偶尔失灵，整个系统不能散架。大模型应用缺的正是这个接口：随机系统和确定性软件之间，缺一层可靠的对接。

Guardrails 的定位是一套规格框架：开发者知道对的输出长什么样，把它拆解开，逐项验证，哪项不合格，就有一套工具去处理。

Nathan 追问了一个更根本的问题：可靠性到底什么时候值钱？她的回答分两种场景。写助手、做提纲这种，模型的创造力是优点，Notion AI Assist 就属于这类。另一类完全相反，比如给小企业做 AI 前台，接电话、排日程，创造力反而是麻烦，你得让它守着固定流程走，还不能套出客户隐私。

把大模型当文本生成器用，创造力是卖点；把它当软件抽象用，可靠性才是卖点。社区里有人拿 Guardrails 做了 Auto PR，一个 GitHub action，从 issue 自动生成 pull request，靠的就是这个逻辑。

信用卡协议和 SQL 沙盒

两个具体例子，一个软一个硬。

软的是她自己的 Chase 信用卡协议。任务：抽取关键条款，输出 JSON。她很清楚约束是什么：利率必须是数字，得带百分号，数值落在合理区间；每个抽出来的实体配一段描述，描述长度、跟实体的相关性都有要求。这些约束写进规格，输出不合格就处理。

硬的是 text-to-SQL，用自然语言查数据库。这里的约束更狠：生成的 SQL 必须能在你的数据库上跑通；有些表是私有的，客户永远不该查到；DROP、UPDATE、INSERT 这类谓词要过滤掉。

Guardrails 的做法很实在：拿你的数据库 schema 建一个 SQL 沙盒，每条生成的查询先在沙盒里跑一遍。跑不通，就把报错打包发回给大模型，让它自我修正，直到跑通为止。

两个例子共享同一个思路：开发者对“正确”有自己的领域定义，把它编码成约束，让失败被系统化处理，别再靠运气。

验证是个光谱：混着用，失败了还能救

Nathan 在节目里把错误排了个光谱。一端是传统代码就能抓的，语法错误、变量不存在；另一端是从前根本没法验证的，这段摘要忠实吗？这个翻译行吗？逻辑有没有漏洞？

Guardrails 两端都管，手段是混编：规则和启发式做程序化检查，用自己数据训的高精度小模型，再加 LLM 本身当裁判。几种验证器凑一起，效果比单押一个大模型稳得多。

摘要验证是她上周刚加的一批护栏。判断摘要是否忠实于原文，做法是逐句跟原文做相似度匹配，定位每句话的来源；开发者做实验定一个阈值，相似度低于阈值的句子直接过滤。冗余同理，摘要里两句话太像，删掉一句。

把一段看似整体的文本拆成小块，逐块独立验证，这是 Guardrails 处理“assert 语句管不了的问题”的核心思路。

拿它跟 OpenAI 的 moderation 端点比一下就清楚了。那个端点只能把输出归进有限的几类问题内容，脏话过滤在 Guardrails 里只是众多验证器中的一个，同一套模式可以套到代码、摘要、结构化数据上。

用大模型当裁判这件事，哈佛医学院教授 Zak Kohane 在《The AI Revolution in Medicine》里有类似发现：GPT-4 评文本比它自己生成文本更靠谱。Shreya 的原则是信任但验证，生成和评估分开做，评估器越多样，整体越稳。OpenAI 自家的 evals 库她也喜欢，理由不太技术：大家把模型用坏的方式都提交进去，等于众包了一份“用户到底想要什么”的清单。Nathan 还问到 Anthropic 的宪法 AI，她的态度是训练协议有意思，但光靠训练不够，运行时验证才是最值得做的事，而且开发者不用每次改定义就去重新训一个模型。

验证失败之后怎么办？Guardrails 给了一排选项。

重问是用得最多、也最有效的。把所有错误聚合起来，一次性发回给模型，只重问错的部分，新输出跟旧输出合并，对用户来说仍然是一次 API 调用。高风险场景，输出不合格就完全没用，这种就该用它。过滤适合摘要、脏话这类场景，句级粒度地删。默认选项叫 no-op，很聪明：验证照跑，失败什么都不做，输出原样给用户，跟没装护栏一样，但所有问题都进了日志，你翻日志决定下一步迭代什么。剩下的还有抛异常，以及能确定性修复就直接修。

边界她也讲得清楚。有一种约束没法验证：“生成的文本必须好笑。”她想不出一个给幽默打分的验证器长什么样，这种只能靠人。高风险领域也一样，错一次代价太大，人的确认省不掉。

Nathan 补了人的因素。他去坐过邻居的特斯拉 FSD，体验比大多数人想的好，手指按屏幕、点一下就开走。但提醒机制是三级递进：先是视觉提示，然后声音，最后警告再不接管就靠边停车，警告太多次直接踢出 FSD 项目。

他的判断跟直觉相反：人不需要被说服去信任这些系统，人会飞快地说“看起来能用就行”。护栏真正的作用，是把人从他们自己手里救出来。Shreya 在自动驾驶行业见过另一半真相：人太容易走神，永远提醒“注意注意”，提醒很快失效。好的界面应该只在最需要人的时候叫人。

安全这道题，模型自己答不了

Bing 的聊天机器人 Sydney 被用户几句套话就带偏，全互联网都看到了。提示注入成了大模型应用最大的运营风险之一。Nathan 还提了个细节，微软的方案是流式输出 token，发现跑偏再撤回，一家巨头明知会吐出问题内容、吐完再收回来，可见这个范式有多缺保障。

Shreya 的判断很干脆：安全没法指望模型自己。随机系统有长长的尾巴，你没法为人们将想出的所有奇怪用法准备数据。OpenAI 靠规模定律拿到了涌现能力，可保证这件事，规模给不了。

她的方案是三明治：LLM API 调用前后各包一层，输入验证加输出验证。已知的注入模式在输入侧拦截，把用户能问的东西守住在一个可控集合里；已知的危险行为在输出侧二次检查。她跟不少进了生产环境的团队聊过，这几乎是通用设计：没人做端到端的机器学习系统，都是 ML 组件接一个检查点，人或确定性组件验证输出，再接下一个组件。

Nathan 补了模型风险这一层。他现在的策略是所有事都用 GPT-4，把质量做到及格，再逐步优化成本和延迟。可一旦往开源模型上迁，比如微调版 LLaMA，问题就来了：OpenAI 和 Anthropic 的安全水平是辛苦做出来的，微调 LLaMA 不会自动继承。很多人把厂商的 SLA 误当成语言模型的固有属性，其实那是人家一点点做出来的。

还有一个正在逼近的变化：模型之间直接传向量。Nathan 提到 BLIP-2，冻结的视觉模型接冻结的语言模型，中间只训一个小连接器，图像编码直接翻译进语言模型的嵌入空间。Shreya 硕士论文做的就是这类联合嵌入，时尚领域，图像和文本投进同一个空间做相似度检索。

她在 Drive.ai 的经验支持这个方向：只用 LIDAR，跟 LIDAR 加相机一起用，后者对车辆状态的理解明显更好，决策也更准。多一路传感，多一路接地，也多一路自我验证的依据。Nathan 的担忧是，向量空间大到无法穷举测试，输入侧完全不可测。他的建议很直接：开始验证你的输出吧，各位，这件事只会越来越重要。

Agent 之前，先解决“对错谁说了算”

聊到 Agent，Shreya 指出了一个结构性缺口。现在的 Agent 框架，目标和任务由大模型自己配置，模拟小镇里 GPT-4 演所有居民，研究 Agent 里 planner、coder、retriever 各管一段。开发者没有细粒度的介入点，没法在每一步插进自己的约束。

链条上每一步都有出错概率，最弱的一环决定整体，所以最朴素实现的 Agent 失败率很高。Nathan 听完直接改了预期：护栏是多 Agent 系统里角色之间的连接组织，他对 Agent 什么时候能用的判断得往前调。

约束和对错规格，是 Agent 能被真正雇用之前的必要条件。难点在于，当你不是配置 Agent 的那个人，怎么动态评估它每一步做得对不对。

Nathan 正在给一家叫 Athena 的高管助理公司做顾问，测的就是这个。AI 理解请求、提跟进问题已经很漂亮，卡在执行：真去网页上按对按钮、结账、登录。双因素认证暂时还挡着 AI。Shreya 认为还有一层信任赤字：就算 Agent 完美，人敢授权多少也是个问题。每一步可验证、可监督的框架，得在 Agent 走出 demo 之前建好。

往远看，她猜开发范式会走向配置优先。提示词不够用，选个模型、调个温度也不够用，输出怎么验证、怎么修正、怎么后处理，全都应该可配置。模型版本偷偷更新、行为悄悄变化，开发者手里那份规格不变，Guardrails 负责把同一份规格编译成对不同模型最有效的提示。她管这套规格叫 RAIL，Reliable AI Markup Language，会写 XML 就能上手。Nathan 顺带考了个古：让模型按格式输出的 format trick，经 prompt 工程师 Riley Goodside 走红，他说是 OpenAI 的 Boris Power 传给他的，Guardrails 把这类技巧产品化了。

正确性还会因人而异。脏话过滤是最大共识，但她聊过做角色扮演聊天机器人的团队，机器人模仿的真人本来就满口脏话，过滤掉反而毁了真实性。全局标准很难成立，定义“对”的权力会留在开发者和领域专家手里。市场那边她倒是乐观：有人直说 OpenAI 太贵，转开源模型，不同价位、不同延迟的模型都会活得好，标准和模型一起演进，牌桌迟早会更平。

明天就能用上的几件事

快问快答里有个细节挺有味道。她最离不开的 AI 工具是 Copilot，重装开发环境那几天没装上，明确感觉自己变慢了。Neuralink 那题她拒了，理由很有职业风格：开会走神的时候，幻灯片可能已经切到别的东西上了，思考和执行之间得有过滤层。

回到正事。如果你在用大模型做产品，这期节目里有几件事明天就能动手：

• 把输出约束从提示词里拆出来，写成独立规格，输出 schema 归 schema，提示词只写任务描述。土办法也行，XML 标签加正则，Nathan 自己就这么干。
• 先开 no-op 模式跑几天，验证照跑、只记日志、不改行为，用日志看清模型到底错在哪，再决定迭代方向。
• 生成和评估分开，让另一个调用、另一个模型当裁判，评估器越多样越稳。
• SQL 和代码类输出，先过沙盒再上线，报错打包喂回去让它自己修。
• 算一算你的场景里，“正确”的定义哪些能编码成规则，哪些必须人看。能编码的交给护栏，必须人看的，把界面设计成只在关键时刻叫人。

模型会越来越便宜，越来越强，但随机这件事不会消失。可靠性从来都是系统工程挣来的，护栏就是那个挣法。