AI聊天机器人一本正经胡说八道，工程师的解法是装护栏

机制：预测下一个词

把一句话交给AI聊天机器人，模型先把它转成token。对每个token位置，模型要算一遍整个词表上的概率分布，然后采样下一个token。采样结果拼回上下文，再来一轮，直到生成完。整个过程没有“查答案”这一步。模型永远在做同一件事：给定已有的上下文，预测下一个token是什么。

一个token约等于0.75个英文单词。128000个token的上下文，容量接近一本完整的小说。为什么不用完整的单词？语言本身很乱——新词、拼写错误、代码、各种语言搅在一起。token是固定的、可复用的构建块，正好拿来拼这些混乱的表达。

这套机制在生产环境里有直接代价：按token计费，延迟随token数量增长。10万token的输入和1千token的输入，完全不是同一类请求。

幻觉是这套机制的必然结果，跟“忘了修bug”没什么关系。模型没有验证答案的步骤，核心过程始终是：给定已有上下文，预测下一个token。模型可能给"Stanford University“打出78%的概率。这个概率说明的只是：在这个语境里”Stanford“是个合理的延续。高概率不等于事实正确。

把温度调到0，输出确实更确定，但错误不会消失。模型只是每次都自信地生成同一个错误答案。同一个问题问100遍，得到100次”30天“。这证明的只是它够一致，离事实正确还差得远。

RAG：检索对了，答案不一定对

RAG（检索增强生成）是一种模式，不是数据库。它从SQL、Elasticsearch、向量数据库、知识图谱或API里检索信息，再交给模型。光是检索到位还不够。模型仍可能忽略文档里的条件，错误组合两个事实，漏掉例外。它也可能沿用在别处学到的模式，不理会文档本身。

举个例子。政策写着”已开封的电子产品不能退货“。有人问”这台开过封的笔记本能退吗“，模型看到14天退货窗口，回答”可以“。它漏掉了例外。这一步的失败发生在推理环节，不在检索。

后端验证，LLM提建议

到这里，职责可以分开了。RAG负责检索知识和信息。工具负责跟系统交互、获取实时数据、执行操作。对金融代理、退款系统这类有实际后果的场景，别让概率模型当确定性业务规则的唯一执行者。后端验证，LLM提建议。

这也是LLM在系统里该待的位置。只有工具组合的可能性很多、调用序列真正动态的时候，才值得用LLM规划器。如果只有两个可预测的依赖，后端编排用确定性方式处理就够了。

上下文工程

上下文窗口是模型单次请求能处理的最大文本量。初学者的错误是：窗口大，那就把什么都发过去。多塞上下文有三个实际成本：延迟增加、成本增加、准确性可能下降。信息太多，模型反而更难找到相关部分。上下文工程要解决的是放什么进去：放对的，别贪多。

LLM处理一次请求分两个阶段。预填充阶段处理整个输入，之后才开始生成第一个输出token。解码阶段逐个蹦token。TTFT是第一个token出现的时间，由预填充阶段决定。流式输出不会缩短TTFT，它只是让解码阶段看起来更快。AI停顿很久的时候，多半是在啃大段输入。

调试与学习路径

调试AI管道，先把管道拆成可测量的阶段。”我们的RAG不好“算不上工程诊断。”检索召回率96%，答案准确率68%，所以失败发生在推理或上下文构建环节“才算。

对后端工程师来说，分布式系统的经验可以直接迁移。新的那一层是LLM、代理架构、上下文工程和评估。一套6周路线图：第1周LLM基础，第2周提示与上下文工程。第3周工具调用与代理架构，第4周RAG与记忆。第5周多代理系统与生产，第6周评估、安全与面试准备。目标是能面AI工程师、应用AI工程师、代理工程师和LLM工程师的岗位。

第2部分会展开提示与上下文工程：系统消息、用户消息、工具消息、指令层次、上下文构建。还会讲动态提示、提示注入、上下文腐烂、压缩、交接和记忆。其中”上下文腐烂"这个词，没有给出定义。