外观
第 2 章 大模型是怎么工作的
第 1 章立了三个直觉，也亲手用过了模型，本章把直觉底下的机制拆开讲透。模型是智能体的判断中枢，它怎么接话、记得住什么、为什么错，后面每一章的产品判断都踩在这些行为上；先懂模型，第 3、4 章看智能体产品和值不值得的判断时，才知道盒子里面是什么。本章拆的是模型这半边，工具和自主权那半边留给第 5 章。产品经理要懂到机制这一层，有两件事躲不开。头一件，研发拿上桌讨论的头两样东西多半就是提示词和知识库，这两样跟不上，方案会上只能点头。另一件，业务方迟早要问“它到底知道什么、能保证多准”，这个承诺的边界全写在模型机制里，不懂机制，承诺就没法定。
本章四节。2.1 把第 1 章的“输出不确定”直觉讲到底，把上下文窗口和成本这两件事算清；2.2 讲提示词，为什么它是产品逻辑的一部分；2.3 讲 RAG，为什么检索决定答案质量，这一节是全章重头；2.4 收口，讲模型能力边界的读法，读完能向同事解释清楚模型为什么会一本正经地胡说，本章就算过关。深度上这一章不教造，造模型是算法工程师的事，造智能体系统是姊妹卷《悟道智能体开发》的事，本章给的是产品经理看这个模型的底子，深度以能向工程师提对问题、能向业务方讲清机制含义为限，再往下的工程细节，每节末尾的深挖指路都指向姊妹卷。起点不设门槛，第 1 章立过三个直觉，按概率接话、知识截止、一本正经地胡说，本章 2.1、2.3、2.4 各接一个往下挖，2.2 讲的是最直接的抓手。
2.1 大模型的概率机制
大模型按词元（Token）处理文本，输出是一步接一步抽出来的，两件事合起来决定了产品经理必须建立的认识，输出不确定是这个模型的工作方式，不是故障，上下文窗口按词元计，钱也按词元算。第 1 章留了个尾巴，模型眼里的最小单位比“词”还要细，现在补上，因为它正是这一章的度量衡。
词元是从连续文字里切出来的片段。一个汉字通常折成一两个词元，一个英文单词可能是一个词元，也可能拆成几段，标点也算。粗估的口径是，一千汉字的中文，折合约一千五百到两千个词元；各家模型的切法不同，这个数有出入，精确数以各家产品的用量统计为准。往后读到“窗口多大”“按什么计费”，换算的都是这个词元。
单位有了，看模型本身。1.3 说过，模型接话靠一张清单，几万个候选词各排各的位置，各带一个把握程度，生成就是从清单里抽一个。当时只说到这一层，往下还有关键一层，一段回答靠循环接出来，接一个词只是其中一圈。抽中一个词元，拼回句尾，把变长的句子再算一遍，得到下一张清单，再抽，如此一圈圈转下去。一段一千词元的回答，中间有一千次抽签。哪怕每次抽签走岔的机会都很小，一千次叠下来，两次生成逐字一致的机会已经小到可以忽略。这就是 1.1 那个实验的全部答案，同一个问题问两遍，两次回答不完全一样，问题不在产品不稳，在一千次抽签步步都带随机性。
抽得有多随机，还有一个可调的参数管着，研发叫它温度。温度动的是抽签这一步，模型本身不变，它调的是候选之间把握程度的差距。温度压低，差距拉大，把握最高的候选几乎稳赢，模型每次都抽把握最大的那个词，同一个问题的答案基本不动；温度调高，差距抹平，排在前面的不再稳赢，排在中后的也时常胜出，答案花样多，也更容易跑偏。产品上的用法对应任务的性质，取数、核对、分类这类要稳的活用低温度，起标题、想文案这类要变化的活可以调高。参数由研发设置，每个功能定什么档是产品决策，5.6 的词汇表把它列成了与研发对齐的一问。
这套机制还解释了另一个日常抱怨，就是“时灵时不灵”。问题的候选清单有宽有窄，让模型给奶茶店写一句开业横幅，怎么写都行，清单宽，连问五次五个样；问 2 的 10 次方是多少，清单窄到几乎只剩一个答案，连问五次全是 1024。很多时候毛病不在模型状态忽好忽坏，在题的宽窄不一样。这对产品经理是个实打实的提醒，拿一道题去试模型，说明不了什么，决定表现的是题的分布；要量能力，得拿一批真实任务批量测试，这件事第 11 章展开成评测方法。
顺着这套机制再看传统软件，差别就更清楚了。传统软件的行为写死在代码里，同样的输入永远同样的输出，出了错，定位到那行代码修掉，这个错就永远消失。模型没有这行代码可修，它的规律不在哪一行里，在几千亿个参数里，参数装的是“什么话后面常接什么话”的统计规律，1.3 讲训练时说过。所以“答错”是它工作方式自带的波动，修不掉，只能管，用提示词把行为收拢（2.2），用评测把波动量出来（第 11 章），用兜底把错拦下（第 10 章）。本书后半部分的兜底设计和评测方法，本质上都是这个“管”字的具体展开。
模型要接话，先得看见前文，而它一次能看见的量有硬上限。这个上限叫上下文窗口（Context Window），一次请求里模型能处理的词元总数封顶，输入和输出共用这一块额度。截至 2026 年年中，主流模型的窗口普遍在几十万词元量级，旗舰型号给到百万级，具体数字以各家官方说明为准。几十万词元是什么概念？按一千字折一千五到两千词元倒推，二十万词元大约装得下十万字出头的中文，一部书稿的量级。听着不小，消耗起来很快，写给模型的角色指令、整段对话历史、喂给它的资料、本轮问题，再加上给回答留的余地，全部从这一块额度里出。
窗口装满了有两种下场，选哪种看产品设计。一种是裁剪，产品在后台把最早的对话摘要掉或压掉，腾位置给新内容，用户的感受是“聊得久了它开始忘事”。另一种更硬，内容超出上限，请求直接失败，窗口之外的东西对模型等于不存在。这里还藏着一个多数人想不到的事实，模型服务那边不保存任何对话。1.1 观察过“它记得同一窗口里聊过什么”，机制其实是，每发一句新话，产品都把之前整段历史连同这句一起打包重发一遍，模型谈不上记性好，它每一轮都重新读了一遍全部聊天记录。
这笔额度在聊天产品里还算宽裕，到智能体手里消耗得飞快。智能体干活要调工具，工具返回的结果同样要进窗口，查一次销售系统，返回的明细就顶得上几十轮对话；一个多步任务跑下来，几次工具调用能把窗口占掉大半。所以真正限制智能体“能干多长的活”的，往往不在模型够不够聪明，在这块窗口的预算够不够花。给多步任务做产品设计时，“中间要看多少东西”得先粗算一遍，具体怎么估，第 5 章讲工具时再展开。窗口里装什么、装满了的两种下场、每轮重发的历史，画在图 2-1 里。
这个“每轮重发”直接连到钱上。模型服务按词元计费，输入和输出分开定价，有一条在谈判桌上用得上的直觉，输入便宜，输出贵，输出普遍比输入贵好几倍。贵有贵的道理，输入是整段文字一起送进模型，可以并行处理，一遍过；输出必须一个词元一个词元往外接，后一个要等前一个接完，串行，算力占用时间长得多，价格差体现的就是这个计算量的差。再叠上每轮重发全部历史这条，长对话的成本就出来了，第一轮发一小段，第十轮比第一轮重，第二十轮更重，每轮都比上一轮沉。所以智能体产品的成本有个结构性规律，任务越长、轮次越多，成本涨得比线性还快。细算留到第 12 章，这里先立直觉。
这套机制换算成谈判桌上的三句话。头一句，输入按词元算，长资料进窗口就是成本，资料该不该全量进、进多长，是设计决策。第二句，输出贵好几倍，让模型少说废话不只是省时间，是省钱，回答的详略是产品规格，不是随口的事。最后一句，轮次越多每轮越贵，“多聊几轮再说”的功能设计，每一轮都在计费。与研发核对成本时，不要问“调一次模型多少钱”，一次调用可长可短，这个数没有意义；要问“一单任务进来，输入大概多少词元、输出多少、中间跑几轮”。按任务算、不按次数算，这个口径才能拿去定价和砍需求。
这三句话合成产品经理的三个判断。凡是“每次都对”的承诺都不能给，一千次抽签的模型给不出这种承诺，能给的是“十次里对几次”，第 3 章讲三大特殊性时立过这句话，现在机制也补齐了。长对话也不是白来的功能，轮次设计要有收敛机制，该总结的总结、该截断的截断，放任聊下去，窗口和账单一起出问题。“把资料全塞给它”更不是方案，资料进窗口，一占额度二花钱，窗口再大也装不下一个公司的报表，何况塞得越多，关键内容稀释得越厉害。资料到底该怎么递到模型眼前，这个问题的正式答案就是 2.3 整节。
深挖指路：怎么发请求、怎么实测词元数、怎么限制输出长度这些工程做法，《悟道智能体开发》第 1 章逐件展开，产品经理不必动手，评审时听得懂即可。
2.2 提示词为什么影响产品体验
提示词是产品经理在这个模型上最直接的抓手，它在机制上就是模型接话的前文，是模型行为的第一决定项，写清与写糊是两个不同的产品。先回到 1.1 的第二个问题，让它改一段话，要求说得越具体，结果越好，当时只记下了这个规律，这一节把机制讲清。
写提示词这门手艺有正式的名字，提示词工程（prompt engineering），业界攒了成套的写法与纪律。本书讲到产品够用的深度，成套方法有两处可去，工程深挖见姊妹卷《悟道智能体开发》，系统方法见前作《悟道提示工程》。
提示词（Prompt），就是发给模型的全部文字，包括用户当下敲进去的问题，也包括产品预先写好、用户看不见的那段指令。它在机制上就是前文，2.1 讲过，模型接话接得像不像，取决于它看到的前文，提示词就是那段前文，产品写下的每一个字都在参与塑造“接下来接什么话”。这就是提示词影响体验的根源。同样一个模型，接进写作产品显得能说会道，接进工单系统就按规程办事，模型没换，换的是最前面那段指令。这段预置指令有个专名，叫系统提示（System Prompt），是设定角色、规则与边界的高优先级指令。第 1 章讲过，模型训练时专门补过“听吩咐”这一段，系统提示就是吩咐的头一条，同样一条要求，放在开头指令里，模型执行的力度普遍比放在对话中间强。一份能用的系统提示通常写三块，角色，它是谁、服务谁、什么语气；规则，按什么流程办事、冲突时以什么为先；边界，什么不做、越界时走什么出口。写边界有一条配对的纪律，每个禁区配一条出路，光写“不许”、不写碰到时该怎么办，模型遇到没写过的情况会僵住。
写清与写糊差多少，拿案例线走一遍最直观。给周报归因智能体写指令，糊版一句话：“分析上周销售情况，给出原因。”模型收到的信息就这么点，剩下的全靠自己补，分析到多细？看哪几家店？要不要拆品类？口径跟现有报表一致吗？它接出来的东西像周报，像模像样，能不能直接用，大概率要大改。清版把话说全，分析对象是 ST001 到 ST003 三家门店上周的销售明细；先给结论，再给依据，每条依据注明来自哪张报表；指标口径与现有周报一致；查不实的原因明确写“未查明”，不推测。
两版的差别不在文采，在一件事，糊指令等于把产品逻辑外包给模型的想象。自由发挥的机制还在 2.1 的概率清单上，指令空着的地方，模型就按训练语料里“这类话通常怎么接”来接。换一个任务看得更直观，给客服智能体写糊指令，语料里客服对话一套一套的，热情寒暄、主动给补偿都是现成接法，“通用客服”的接法概率不低，指令没写清角色，模型就顺着接了。糊指令没有让模型停在原地，反而让它按全网的平均水平发挥；模型的默认行为从来不值得赌，“客服大概会怎么说话”这种想象，它有一整套，擅自承诺、答非所问，都可能从想象里接出来。把“显然该这样”逐条写成字面指令，才是把行为收拢住的写法。
收拢行为还有一个性价比最高的写法，就是给示例。抽象规则写十条，不如示例给一对。“语气专业”是抽象的，模型各凭想象；给一对示例，输入长这样、输出该长那样，它照着样子接，比揣摩规则准得多。道理还是在接话上，示例直接演示了“这类话后面接什么话”，恰好是它最擅长模仿的东西。周报归因的指令里放一份历史周报的片段当样子，比写十句“要专业、要有依据”都管用。
系统提示还有个写什么、不写什么的讲究，分不清这个，最容易把好提示写坏。内容分三个去处。不变的指令进系统提示，角色、规则、边界，一次写好长期有效。随对话变化的内容进对话历史，用户刚才交代了什么、上一轮改到哪一版，这些跟着会话走，不进预置指令。客观事实不要写进提示，五十条商品问答、一整本产品手册粘进指令，是新手最常犯的错，一是指令越写越长，规则互相干扰，二是资料一更新，提示就过期了。事实性知识的正式去处是 2.3 的知识库，按需检索，常换常新。三块去处分清，提示词才写得短、写得稳。
业务方嘴里的“调一调它”，到了研发手里，可能是改十行提示词。这里有一层产品认识要立住，提示词是产品逻辑的一部分，不是研发的私有财产。传统产品的逻辑写在需求文档和代码里，改功能要走流程；智能体产品的逻辑，有相当一块写在提示词里，改一段提示词，产品行为就变，连版都不用发。这带来三个后果。其一，提示词要有版本管理，谁改的、为什么改、改完行为变没变，都要留痕，当产品资产管。其二，改提示词与改功能一样要过验收，拿一批任务，改前改后各跑一遍对比，不凭“感觉顺多了”上线。其三，权限要事先说清，哪些能直接调、哪些必须过评审，产品经理在这个环节要有一票。第 6 章讲研发周期时，这条会列为智能体与传统产品的差异之一。
提示词谁来写，这个组织问题迟早要面对，分两半看。产品语义归产品经理，角色是谁、什么语气、边界在哪、什么样的输出算好，这些本来就是产品定义，不该交给研发凭感觉写。实现约束归研发，输出格式、字段结构、跟程序怎么衔接，这些是工程细节。两头合成一份完整的提示词，谁改哪一半、改动怎么过验收，事先说好。这个分工的日常怎么落地，第 11 章讲研发协作时正面展开。
提示词还是个敏感的东西，措辞的小改动可能带来行为的大变化，换一个模型版本，同一段提示的效果也会漂。所以提示词没有“一次写好”这回事，它跟产品一起活，上线只是第一版，往后每一个坏案例，都可能回流成一条新规则、一个新示例。这门手艺往深里走自成体系，本系列前作《悟道提示工程》整本讲它，产品经理读到能评审、能亲手把糊版改成清版就够用。最小认知收拢成四句话，提示词是前文，模型照它接话，写清写糊是两个产品；角色、规则、边界三块立住；一个具体示例抵好几条抽象规则，给模型看的示例直接演示“输入长这样时，输出该长那样”；每个禁区配一条出路，只写“不许”，它碰到没写过的情况会僵住。
深挖指路：系统提示的完整结构、示例怎么挑、上线后怎么随坏案例迭代，《悟道智能体开发》第 1 章 1.5 节有工程版展开，方法论的完整展开在《悟道提示工程》。
2.3 RAG，检索决定答案质量
提示词管“怎么答”，这一节管“答的料从哪来”，它是本章的重头。做法有个正式名字，检索增强生成（Retrieval-Augmented Generation，RAG），拆开就三个词，检索、增强、生成，顺序也是干活顺序，先检索，再生成；先从一堆资料里把相关的几段找出来递给模型，模型照着这几段作答。这一节的结论先给出，RAG 系统的答案质量上限卡在检索上，两处最容易出的事故，切块切坏和检索取错，都在检索侧。
从一个具体问题看为什么需要它。老陈打烊后问：“上周三我们店的试饮报废怎么比平时高这么多？”这句话发给任何一个不带资料库的对话产品，答案只有一个下场，就是编。训练数据里没有这家店、这杯茶、这一天的任何数字，模型学问再大也够不着这里。这正是第 1 章第二个直觉说的情况，它读书有截止日期，公司的报表更不在它读过的书里。让模型用上最新的、内部的知识，路子有两条。一条是重新训练，把公司资料掺进训练数据再训一版模型，这条路对多数产品不成立，贵，周期以月计，资料每次更新都得重来一遍。另一条不动模型动资料，模型不变，把相关资料在提问的那一刻递到它眼前，就是 RAG。第 1 章提过“很多对话产品答得上新鲜事，那是产品在模型外面配了联网搜索”，那是同一件事的另一个用法，把全网当资料库；RAG 把这套做法搬进公司，库换成自家的报表、文档和记录。
这套做法分两段，先看备料这一段，它发生在用户提问之前。切块是第一步，把长文档切成一段一段的小块，比如几百词元一块。必须切的原因有两个。一个是量，不切块，一份长文档整篇塞进窗口，2.1 刚算过这笔成本，装不下也花钱。更重要的是质，检索要找的是“哪几段跟问题相关”，不是“哪几份文档相关”。老陈问试饮报废，相关的可能就是损耗表里的三行数和当天的一条备注，整份报表递过去，反而把关键几行淹掉了。有了块，“只取相关的部分”这个动作才做得成。
切好的块要变成能比对的样子，这一步叫嵌入（Embedding）。嵌入模型把每一段文字变成一串数字，行业里叫向量。这串数字不是随机编的，嵌入模型训练的目标，就是让意思相近的文本变出相近的数字串。两段话用词完全不同，只要说的是一件事，数字串就挨得近；不沾边的，离得远。于是“比意思”这件事变成了“比距离”，损耗表里“试饮报废偏高”那一行，跟老陈那句“报废怎么这么多”，字面几乎不重合，向量距离却很近，检索靠的就是这个。块存进一个专门的库，数字串连同原文一起备好，备料就完成了。
再看问答这一段，用户提问的那一刻开始走。问题本身也过一遍嵌入，变成一串数字；拿它与库里每一段的数字串比距离，挑出最近的几段，取回原文；取回的几段跟问题拼在一起，一起发给模型，提示词的大意是：“以下是相关资料，照资料回答，答不了就明说。”模型接话，这一次它的前文里有真数了，接出来的就是有依据的回答。六步全流程画在图 2-3 里。
骨架就这些，并不神秘，产品经理要看住的是骨架里最容易出事的两处，它们恰好都不在“生成”上，在“检索”上。第一处，切块切坏了。生产系统里常见的一种事故长这样，按固定字数硬切，把一条完整的规定切成两半，前一半写着“一律照此办理”，例外条款写在后一半；用户问到时，检索只取回了前一半，模型照着答，结论与规定的本意正好相反。模型没有错，它确实照着取回的内容答了，错在递到它眼前的内容不完整。切块在研发的任务清单里看着是个不起眼的预处理步骤，实际上它定的是知识库的颗粒度，什么该整段保留，表格和条款要不要单独处理，切多大合适，这些是产品要参与的决策，不是研发随手定掉的琐事。
第二处，检索取错了。语义检索靠意思相近配对，这对“意思”灵，对“字面”钝。问“ST002 上周的损耗”，语义检索完全可能取回 ST003 的记录，因为意思最相近；问一个指标名，取回的是另一段长得像的说明。精确的编号、人名、指标名，靠比意思配不上，得靠字面对字面。所以生产级的检索通常两条腿走路，语义检索管意思，关键词检索管字面，两边结果合起来再排先后，混合检索说的就是这么个做法。合出来的长名单还要精排一道，拿每个候选跟问题细致比对一遍，重新打分排出先后，这道处理有个专名叫重排序（Rerank），打分的活通常交给一个专门做比对的模型。业务里内部编号、行话、专名越多，字面那条腿越不能省。
经营分析场景里，这种错一点也不抽象。问“华东区上周的客单价”，库里存的是各区的明细，语义检索觉得“华南区上周的客单价”那段意思最相近，原文只差一个字，取回来的就是另一个区的数。模型照着答，数是对的，区是错的。这类错最隐蔽，链条上每一步都没坏，答案整体是歪的，好在查得出来，对照原始报表就现形。
两处看住了，就到了这一节标题这句话，检索决定答案质量。分工本来就是这么切的，模型负责照着取回的内容组织语言，写得好不好归它；内容对不对、全不全，归检索。取回的内容是对的，差一点的模型顶多答得笨；取回的内容是错的，最好的模型也答不对，它只会流畅地把错的说出来。检索质量还能亲手查，不需要懂技术，抽一批真实问题，让研发把每次取回的片段列出来，对着问题看，该取回的取没取回、取回的是不是相关的，人眼一看便知。这一栏将来就该长在第 11 章的评测计划里，是产品经理可以直接主导的检查项。
拿案例线预演一遍。小周手里的三张报表，加上历史周报和运营群里的归因讨论，整理切块入库，就是这家品牌的知识库。老陈问“上周三报废怎么偏高”，产品先检索，损耗表那几行、当天备注、上周周报里相关的归因段，取回；模型照着这几段答，结论挂在真数上。检索要是漏了那条备注，或者取成了别家店的数，答案当场就歪。第 4 章把店长问答排在第二单，理由是验收关口要另立，现在能看得更清，那道关口的第一项考核就是检索质量。
还有一笔运营成本要说清，建库不是一次性工程。报表每周在出，促销日历每月在换，群里的归因结论天天在攒；库不跟着更新，答案就悄悄过期，资料删了、口径改了，库里的旧块不同步清理，产品还会拿新旧两套数打架。知识库比模型更容易过时，模型一年换一回，库一周不更新就旧了。它与第 3 章讲的持续进化是一对，模型在变，库也在变，两头的变都要有人管，第 15 章的运营迭代就是管这个的。
最后立“知识在库里，不在模型里”这条认识，三层含义。第一层，换知识不用换模型，库里的资料日更，产品的答案就能日更，不用等模型升级；反过来，别指望换模型解决知识问题，学问在库里，两件事不相干。第二层，知识库的质量就是产品质量的一半，脏数据、过期数据、口径不一的数据进了库，错误答案就有了稳定的出处。传统软件讲垃圾进垃圾出，RAG 产品把这句话接了过来，数据治理从后台工作变成了产品工作。第三层是权限，库里的内容都会进模型上下文，谁能问、答给谁看，这道边界要在检索层做，做在前面比事后补救便宜得多，第 14 章安全设计正面讲。
深挖指路：向量库选型、重排序、检索质量评测这些工程深水区，《悟道智能体开发》第 6 章讲外挂知识库时逐一展开。
2.4 模型能力的边界
读模型能力边界有三条，能力的参差、学问的新旧、幻觉的根源，一条比一条往深去，读完能向同事解释清楚模型为什么会一本正经地胡说。
头一条读法，能力是参差的。同一个模型，上一道题答得惊艳，下一道题错得离谱，而且错的那道在人看来明明更简单，写一篇像模像样的行业分析它信手拈来，数一段长文里某个词出现几次，它可能数错。能力强弱不按人类眼里的任务难度排，这是这一代模型的共同特征。参差对产品经理意味着两件事。头一件，别拿一道题给模型定能力，演示日它答好一道难题，不代表业务里的五十道题它都答得好；它做错一道简单题，也不代表这个场景不能用，量能力只有一个办法，拿一批真实任务批量测试，统计通过的比例，这是第 11 章评测的主题。第二件，别把别家的结论直接搬，能力边界跟着“哪个模型配哪个场景”走，换个场景就是一条新边界，每个产品都得给自己的场景量自己的边界，别人的评测报告最多当参考。
参差还有一个实用读法，把任务按“语料里有没有”分堆，稳的那堆多半是语料里有的，晃的那堆多半是没有的。常识题、通用写作题稳，内部数据题、小众事实题晃。这个分法跟 2.3 正好接上，晃的那堆，先问该不该进知识库，再问模型行不行。这样读边界，读出来的结论直接变成产品动作，比“感觉它挺聪明”有用得多。演示日的漏洞也埋在这里，演示的题目往往经过排练，从头顺到尾，全场点头；真上了线，用户的问题千奇百怪，边界上的漏洞全露出来。第 3 章讲过拆穿贴牌演示的办法，当场改条件再让它跑；自己产品防这一手，用的是同一个道理，上线前拿没排练过的问题测试它，测试的量要够，评测集干的就是这件事，第 11 章展开。
第二条读法，学问有新旧。知识截止第 1 章讲过，这里补产品侧的话术。对外承诺别写“它知道最新的事”，要写“知识截至某年某月”；用户问“它怎么不知道上周的事”，机制一句话讲清，它的学问在训练结束那天就定型了，之后的世界靠产品外挂的搜索和知识库补，2.3 的库就是干这个的。还有一层容易漏掉，升级模型等于换了一批学问，截止日期挪了，答过的题可能换答案，整个产品行为要重新测试一遍。这就是第 13 章要讲的换型风险，根源在这里就埋下了。
这套话术具体用在三个地方。宣传页写“覆盖截至某年某月的公开信息”，不写“实时掌握最新资讯”。客服答“它的知识停在训练那天，联网和资料库是产品补上的功能”，一句机制讲清，比道歉十句管用。对外协议里，知识时效写成边界条款，不写成承诺条款。三处的说法出自同一个机制，产品经理讲得清机制，运营和法务就不用各编各的。
最后一条读法，幻觉为什么断不了根，值得拆到最细。1.3 那句话，模型算的是“接什么话最像”，不是“查资料对不对”。放到 2.1 的概率清单上看，这句话就具体了。问它一个训练语料里有答案的问题，清单上排第一的是正确答案，抽中它的机会大，答得又快又稳，珠峰多高就是这类。问它一个语料里没有的问题，清单照样开出来，只是排在前头的换成了“像模像样的答案”，一段有零有整的数字，一套有头有尾的说法。为什么“像模像样”反而排前面？因为训练语料里，这类问题后面常常确实跟着一段像样的回答，“像样的回答”本身就是高概率的接法。抽出来，语气与答对时一模一样笃定，因为语气也是接出来的，一段正常回答该有的语气，它照接。信息是错的，语气是真的，两件事在机制上根本不相干。这就是“一本正经地胡说”的全部机理，画在图 2-4 里。
哪类问题最容易碰上？越具体、越小众、越内部，越危险。问“损耗率是什么”，它答得头头是道，这个概念语料里写得很多；问“ST002 上周三的损耗率是多少”，语料里根本没有这家店，编一个有零有整的数的机会立刻上来。第 1 章拿虚构书名做过这个实验，经营分析场景的版本更棘手，因为业务问题大多是后者。需求评审时拿这个标准把问题过一遍，哪些必须配知识库、哪些直接答就行，当场分得清。
说断不了根，先看两条常有人指望的路。一条指望调参数，把随机性调到底，让它每步都抽概率最高的那个。没用，只要错答案排在概率第一位，它只会稳定地答错，从“偶尔错”变成“每次都错同一个错”。另一条指望 RAG，2.3 讲过它大幅压低幻觉，因为答案有了出处；但压不到零，检索空手而归时模型还可能硬答，取回的内容它也可能用串。
真正的治理是产品设计三件套，1.3 收尾点过名，这里配齐，给它配资料，让答案有出处；给它设检查，答完过一道核验，看说的与资料一致不一致；关键处留人工，错了有人拦。检查的做法先记一句，数字类的错，程序核对就能抓；说法类的错，拿取回的资料当参照再判一遍，也能抓住大半。拦不下来的那一小截，才轮到人工兜底。承诺口径照这条定，不说“保证正确”，说“常见问题覆盖到什么程度、答不准时怎么兜底”。这套思路展开，就是第 9 章的期望管理和第 10 章的兜底设计，机制在这一章讲到了底。
三句话复述模板，本章的过关标准在这里兑现，一，模型按概率接话，算的是接什么最像，不是真不真；二，答案不在它读过的东西里时，像模像样的话反而排在概率前面；三，语气是照着“正常回答长什么样”接出来的，与对错无关，所以听起来永远笃定。能把这三句讲给同事听，本章就过关了。
深挖指路：怎么建评测集，把“十次里对几次”变成可量化的数字，《悟道智能体开发》第 12 章有整套工程方法，本书第 11 章给产品版。
本章小结
- 2.1 概率机制。模型按词元接话，步步抽签，输出不确定是工作方式不是故障；上下文窗口是一次能看的全部，输入输出共用额度，装满要么裁剪要么失败；每轮重发全部历史，输入便宜输出贵，贵在串行，任务越长轮次越多，成本涨得比线性快；按任务算、不按次数算。
- 2.2 提示词。提示词是模型接话的前文，写清写糊是两个产品；角色、规则、边界三块立住，示例抵抽象规则，禁区配出路；改提示词就是改产品，版本、验收、权限三样都要管，产品语义归产品经理，实现约束归研发。
- 2.3 RAG。知识在库里不在模型里；切块、嵌入、比对、取回、拼进提示、生成答案，六步里最容易出事的两步都在检索侧，切块切坏和检索取错，混合检索补字面那条腿；知识库的质量就是产品质量的一半，库比模型更容易过时，更新要有人管。
- 2.4 边界。能力参差，一道题定不了能力，量能力只有批量测试；学问有截止日期，新事靠产品外挂，对外承诺写“知识截至某年某月”；幻觉是接话机制的必然产物，调参治不了，RAG 压不到零，治理靠配资料、设检查、留人工。
本章收起来一句话，模型按概率接话，只看得见窗口之内，答不出没读过的东西；产品经理的工作，是在这个模型外面用提示词塑造它，用检索喂它，用边界设计管住它。模型再强，也只会说话，订不了票，发不了邮件，算好的周报也只是一个字一个字的输出。下一章给它装上工具和自主权，看它怎么从会说话变成会干活。
试一试
- 拿一个只有自己公司才知道的问题，问任何一个对话产品，比如某条内部流程的第几步、某份内部文档里的某个数。把它编造的样子记下来，这就是没有 RAG 的样子。再把相关那段原文贴进对话框，问同一个问题，对比前后两个答案，亲手量一次“检索递资料”值多少钱。
- 同一个开放问题（给奶茶店写一句开业横幅）连问五遍，再同一个封闭问题（2 的 10 次方是多少）连问五遍，用“清单宽窄”把两组结果的不同讲给自己听。
- 找一段自己写给任何 AI 产品的模糊指令，按角色、规则、边界三块改写一遍，每个禁区配一条出路，对比两版输出，把差距归因到“模型自己补了什么想象”。
- 开一个长对话，聊够二十轮，中途问它第一轮说过的细节，看它记不记得，再判断这是上下文窗口的哪种下场。
- 费曼检验，不看这一章，把“模型为什么会一本正经地胡说”用三句话讲给一位同事，讲完对照 2.4 的复述模板，缺哪句补哪句。
参考资料
各家模型官方文档的上下文窗口规格页（截至 2026 年 9 月核对：主流档位 20 万至 40 万词元，旗舰档位 100 万至 200 万词元，各家分档不同，以官方页为准），正文 4.1 窗口量级口径的出处，核实于 2026-09
《悟道智能体开发》（本书工程姊妹卷）第 1 章（概率机器与逐步抽签机制、词元估算口径、上下文窗口与每轮重发全部历史的成本累积、输入并行与输出串行的计费机制原因、系统提示的角色规则边界、分布宽窄两类问题、低温治不了幻觉：本章 4.1/4.2/4.4 的知识底本，产品向转述），工程深挖按该书对应章指引
《Agentic AI For Dummies》（Pam Baker，Wiley 2026）第 4 章（RAG 作为智能体访问训练数据之外信息的基础组件、上下文工程的角色），见 txt/agentic-ai-for-dummies.txt（英文原文，第 4 章行 3760-3830）
《Hands-On RAG for Production》（Ofer Mendelevitch、Forrest Bao，O'Reilly 2026）前言（按固定字符切块把法律条款切成两半、检索只取回前半导致答案与合同相反的生产事故）、第 1 章（摄取流与查询流：切块、嵌入、语义检索、答案附引用出处）、第 3 章（语义检索懂意思不懂字面、字面检索懂字面不懂意思、混合检索互补），见 txt/hands-on-rag.txt（英文原文，前言行 127-152、第 1 章行 700-775、第 3 章行 3811-3870）
《The AI Product Playbook》（Marily Nika、Diego Granados，Wiley 2026）第 3 章（提示词是模型生成时接续的起始文本、模型对措辞小改动敏感、提示设计须迭代测试），见 txt/the-ai-product-playbook.txt（英文原文，第 3 章行 3477-3482、3752-3765）