# 锚定不是一个功能。它是一种约束。 LLM 天生就是个猜测者——它永远会编造内容，而你无法用 prompt 把这一点消除。唯一可靠的办法是架构层面的：让一个确定性的数据源掌管事实，把模型降级为一个永远不许自行撰写事实的复述者。'加个 RAG' 并不等于这件事。这里讲清楚两者的区别，以及为什么这是一条分界线——一边是听起来自信的 AI，一边是你能信任的 AI。 - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** architecture, agents, methodology - **Source:** https://fedorthinks.com/zh/blog/grounding-is-a-constraint --- 你向一个助手提一个事实性问题。它用干净、自信的文字作答——名字、数字、还有一处引用。读起来就像是真相。但它完全错了。没有报错，没有警告，没有一丝犹豫。只是一个流畅、结构清晰、纯属虚构的答案，带着和正确答案一模一样的自信送到你面前。 每个用过 LLM 的人都遇到过这一刻。本能反应是把它当成一个 bug——以为更好的模型，或者更聪明的 prompt，迟早能修好它。修不好。而理解为什么修不好，正是锚定（grounding）必须是一个架构决策、而不是你最后撒上去的一个功能的全部原因。 ## 幻觉不是 bug。它就是机制本身。 语言模型并不存储事实再去查找。它一遍又一遍地从训练数据的模式中预测下一个最有可能的 token。当它知道答案时，最有可能的延续恰好是真的。当它不知道时，它不会停下来——它照样产出最有可能的延续，那个延续流畅、自信，且是编出来的。 Andrej Karpathy 说得比我更直白 （[来源](https://simonwillison.net/2023/Dec/9/andrej-karpathy/)）： > 在某种意义上，幻觉就是 LLM 所做的全部。它们是造梦机器……只有当梦境进入被认定为事实错误的领域时，我们才给它贴上"幻觉"的标签。幻觉不是 bug，它是 LLM 最了不起的特性。 同样这套机制，正是让模型能写诗、重构你的代码、或者用三种不同方式解释一个概念的东西。你没法在不抹掉它有用之处的前提下抹掉它的猜测。这种造梦 _本身_ 就是引擎。 而且它不会随着规模变大而消失。 [斯坦福 AI 指数 2026](https://sqmagazine.co.uk/llm-hallucination-statistics/) 测量了 26 个领先模型的幻觉率，发现根据任务不同，它们的幻觉率 在 **22% 到 94%** 之间。最好的模型远好于最差的，但没有一个是 _零_，也永远不会有——因为这不是一个可以打补丁修掉的缺陷。这是猜测者的本性。 所以别再试图修模型了。修它周围的系统。 ## 架构上的关键一步：别把事实交给猜测者 整个想法用一句话讲清楚：**模型可以为真相措辞，但它永远不许撰写真相。** 如果说幻觉就是模型一旦被迫产出事实时所做的事，那么解决办法就是永远不要把它放到那个位置上。别问模型什么是真的。用确定性的东西去计算或查找什么是真的——数据库、计算、API、规则引擎——然后把这些事实交给模型，只给它一项工作：把它们说得漂亮。一旦模型只能复述它被给定的事实，它就没有什么可以发明的了。 这就是锚定。不是"模型足够聪明所以会对"，而是"模型在结构上根本不负责对错"。 ## "加个 RAG" 不是锚定 这正是大多数团队以为自己解决了、但其实没有的地方。检索增强生成（Retrieval-Augmented Generation）——拉取一些相关文档，塞进上下文，盼着模型用上它们——是最常见的锚定尝试。它有帮助。但它和锚定不是一回事，而把它当成一个可以拴上去的功能，恰恰就是那个陷阱。 RAG 给梦境加了个锚；它并不禁止做梦。模型仍然自己决定说什么，仍然在检索不够时填补空白，而检索不够的情况时时刻刻都在发生。2026 年的行业分析发现，朴素的 RAG 流水线 [大约 40% 的时候会在检索环节失败](https://venturebeat.com/data/the-retrieval-rebuild-why-hybrid-retrieval-intent-tripled-as-enterprise-rag-programs-hit-the-scale-wall)， 而且当一个 RAG 系统给出错误答案时，失败出在检索——而非生成——的比例高达 **73%**。模型尽职地在错误的文档之上写出了一个自信、听起来锚定良好的答案。难怪 **77% 的数据负责人** [表示仅靠 RAG 不够可靠](https://atlan.com/know/what-is-rag/)， 撑不起生产环境。 真正要紧的区别不是"你检不检索"。而是 **当事实不在那里时，你允许模型做什么。** 拴上去的 RAG 让它去猜。真正的锚定不会——事实要么来自数据源，要么干脆不被陈述。这不是一条 prompt 指令。它是系统如何构建的一种属性。 ## 真正去强制执行它时是什么样子 我以此为生，所以让我讲具体些。我运营一个占星 API， [Astrolinkers](/work/astrolinkers)，以及一个建立在它之上的面向消费者的产品， [Alwenna](/work/alwenna)。占星是锚定的完美压力测试：它全是具体的位置、分数和关系，而模型非常乐意编造一个自信、看似合理、却完全虚构的解读。 所以模型根本没有机会这么做。Astrolinkers 确定性地计算星盘——真实的位置、真实的合盘、真实的数字，整个数学过程里没有任何 LLM 的影子。只有到这之后语言模型才登场，只承担一项工作：拿着这些算好的事实，用温暖、平实的语气把它们说出来。它从不被问到你的星盘 _说了什么_；它是被告知的，然后被要求把它说好。Alwenna 做出的每一个论断，都能追溯回一个真实、算出来的值。如果引擎没有产出某个事实，模型就没有什么可以拿来谈的——而不是"编一个听起来对的东西出来"。 那条规则—— _模型复述，引擎决定_ ——是接进设计里的，不是写在 prompt 里的。模型不是被 _请求_ 去守规矩；它在 _结构上无法_ 撰写一个事实，因为事实是预先算好之后才到来的，而它处在它们的下游。这就是盼望和强制之间的区别。 ## 为什么是"约束"，而不是"功能" 这正是标题所讲的那个区分，而它并非咬文嚼字。 **功能** 是你加上去、又能关掉的东西。它栖身在一条 prompt 里（"请只使用提供的上下文"），它是可选的，而且它会无声地退化——检索失手的那天，模型悄悄地猜了，没人注意到，直到某个客户注意到。一条 prompt 是对一个本性就是产出看似合理文本的系统提出的礼貌请求。看似合理不等于真。 **约束** 由系统的形态来强制执行。模型处在真相来源的下游，而且不存在任何一条路径能让它陈述一个来源没有提供的事实——不是因为我们好言相求，而是因为架构根本没提供这样一条路径。你不是盼着它保持锚定；它 _无法_ 离开地面。 这和工程里其他所有地方的纪律是同一种。你不是靠请开发者小心来预防某一类 bug；你是让那个 bug 根本无法被表达出来——用一个类型、一道边界、一条代码无法违反的不变式。锚定就是把这一招用在那个唯一会自信地对你撒谎的组件上。把不变式放进架构里，它在那里站得住，而不是放进 prompt 里，它在那里只是一条建议。 ## 回报 这么做之后，有件事会悄悄地翻转过来。LLM 不再是你系统里那个你必须事后猜疑的部分，而成了你可以依靠的部分——因为你把它的工作收窄到了它真正出色的那一件事（语言），并拿走了它结构上不擅长的那一件事（知道什么是真的）。 这就是全部的诀窍。LLM 恰恰在最不被托付事实时最有用——当一个确定性的数据源拥有真相，而模型被留下来做它出类拔萃的事：把那份真相说得有人情味。 锚定不是你为了让模型更好而加上的一个功能。它是你强制执行的一种约束，好让模型无法在它最想犯错的那个方向上犯错。