跳到主要内容

查询流与生成 — 从问题到答案的最后一公里

这一章讲三件事: 用户的问题为什么不能原样拿去检索; prompt(给模型的那段指令)里哪几句话是承重墙; 以及「选哪个模型、用哪个模板」怎么从拍脑袋变成一套评测流程。 读完,基础栈(第 2-6 章这条线)就闭环了——你将看到一个 从 PDF 到带引用答案的完整走查。

1. 顶层全景:查询流的全貌​

把前几章的零件装到一起,查询流的完整版是1:

  用户输入一句话
     │
     ▼  ① 查询改写:把「指令」和「要检索的内容」拆开
     ▼  ② 嵌入 + 向量搜索(第 04、05 章)→ 得到候选块
     ▼  ③ (规模化时)混合搜索 + 重排 —— 第 08 章
     ▼  ④ 拼 prompt:原始问题 + 候选块 + 指令
     ▼  ⑤ 生成模型写答案
     ▼  ⑥ 护栏检查 —— 第 08 章
     ▼
  带引用的答案

  图说:本章管 ①④⑤,外加「怎么评 ⑤ 用得好不好」。
  主走查:书里的《爱丽丝梦游仙境》例子,一份 PDF 从头走到答案。

2. 核心原理(一):查询为什么不能原样拿去检索​

看这句用户输入:「Write a poem based on my travels in 2025」 (根据我 2025 年的旅行写一首诗)2。

把整句原样丢去向量库,会发生什么?检索器会去找「和写诗最像的文本」 ——很可能检回一堆别人的诗。而用户真正想检索的是他的旅行记录; 「写一首诗」是指令,不是检索目标。

所以查询流的第一步是把输入拆成两半:指令(要模型做什么)与 检索查询(retrieval query——真正拿去检索的那部分)3。

主走查第 ① 步:爱丽丝的问题​

我们的演示例子不用旅行,用书里的《爱丽丝梦游仙境》PDF。用户问: 「What did the Mad Hatter say at the tea party?」(疯帽子在茶会上说了什么) ——这句本身就是纯粹的检索查询,不需要拆。走查从第 ② 步开始:

  ① 摄入已完成:PDF 全文 → 切块(每块 1000 字符、相邻重叠 200)→ 嵌入 → 存 LanceDB
  ② 查询嵌入:问题过同一个嵌入模型(text-embedding-3-small)
  ③ 向量搜索:k=3,检回三块茶会场景的原文
  ④ 拼 prompt:「根据 context 回答 question……」+ 三块原文 + 原始问题
  ⑤ gpt-4o-mini(温度=0,即永远挑最高概率的词,输出稳定)生成
  ⑥ 输出:疯帽子的台词,完整且可在原文中核对

  图说:这是书里的第一个完整 RAG 链,组件是 LangChain 串起来的:
  retriever → format_docs → prompt → llm → parser,一棒接一棒。

这条链里每个参数都有出处:切块 1000/200、嵌入用 text-embedding-3-small、 库用 LanceDB、生成用 gpt-4o-mini、温度(控制输出随机程度的旋钮,0=永远挑概率最高的词)设为 0、k=34。 这不是最佳配置,是「能跑」的起点配置——怎么把它调对,是第 11 章的主题。

3. 核心原理(二):生成这一站——选哪个 LLM 来写答案​

检索回来的块,最后要靠一个 LLM 写成答案。书里给这一站定了两个任务: 摘要(把检索块连贯精炼地改写)与问答5。

选型:速度、质量、隐私的三角形​

  • 速度 vs 质量:书里的经验是,在 RAG 的常见任务上,最大的模型只比 中等模型好一点点——常为这点提升付的钱与延迟不值。正确做法是建一个小评测集, 找「满足质量期望(你设定的目标线)的最便宜模型」这个甜蜜点(怎么评测见第 5 节)6;
  • 隐私:内网隔离(air-gapped,物理上断外网)或强合规场景不能用公网 API, 只有开源模型可选;书里的判断是,70B 参数以上的开源模型在 RAG 常见任务上 已经「够好」7。

让推理变快的三件事(只点名)​

自部署时的提速手段,书里点了三个名字:量化(quantization——把参数从 32 位浮点压缩到 16/8/4 位存储与计算,省显存(显卡上的高速存储,模型参数与中间计算都占它)提速)、FlashAttention (一种省内存的注意力算法,注意力是模型内部「每个词回头看前文」的机制)。

第三个是推理服务器(专门承载模型推理、供程序调用的服务进程),代表是 vLLM 与 Ollama8。第 09 章会把它们放进生产架构里。

4. 核心原理(三):prompt 里哪几句是承重墙​

prompt 工程(prompt engineering)是设计打磨给模型的指令的手艺。 作者先摆明态度:没有绝对最优的模板——但有几条反复有效的经验9:

做法为什么
生成时用用户的原始问题,不用改写后的检索查询检索查询是为检索器调到最好的,生成要对着用户的真实意图答
问题放前、材料放后多数模型在这个顺序上表现更好(训练数据的形态使然)10
防幻觉指令:「如果答案无法从材料中合理推断,就直接说『我不知道』」给模型一条明确的退路,它才不会硬编11
复杂问题加一句「请先一步步思考」这是思维链(CoT,chain-of-thought——让模型先写推理过程再给结论)的指令版12
用 <query> <context> 这样的 XML 标签把指令与材料划开划清「可信指令」与「待处理数据」的边界——第 08 章会看到,这同时是防注入攻击的手段13

5. 核心原理(四):「哪个模型+哪个模板」怎么评​

这一节是全书评测思想的预演,正式展开在第 11 章。步骤只有三步14:

第一步,准备评测查询。 有真实用户查询最好;没有就凭你对这份资料和用户行为的了解, 让 LLM 仿造出一批查询(这叫合成——人工造数据)充当评测材料15。

第二步,造「裁判」。 让一个 LLM 当裁判给答案打分,这叫 LLM-as-a-judge。打分沿两个轴:relevance(切题——答了用户问的吗)与 faithfulness(忠实——答案里的每个说法,检索回来的文档里有支撑吗)16。 同一个模型可以既当选手又当裁判,因为「按指令打分」也是它训练过的能力。

但书里没有粉饰,LLM 裁判有三个明摆着的缺点:慢且贵(多一次模型调用)、 会幻觉(它的推理链错,判断就跟着错)、不一致(同一个裁判, 不同时刻判同一个答案可能给不同分)17。替代方案是专用的评测小模型: 书里点名 HHEM(Hughes Hallucination Evaluation Model,一个专测 「答案有没有脱离材料」的分类器(给输入打类别标签的小模型),本书作者之一是它的共同作者) 和 Galileo Luna——小、快、便宜、稳定18。

金标准仍然是人工评测——最准但最贵,放在自动化评测之后做小规模终检19。

第三步,加权计分。 把多个维度的分数按你的业务权重(每个维度各占多大比重)加起来, 选总分最高的「模型+模板」组合20。

6. 作者的判断与证据​

  • 「多数模型 query 在前效果更好」是经验性陈述,作者归因于训练数据形态, 没有给实验数据——属判断。
  • HHEM 的引用量(2024-08 至 2025-08 下载 500 万+次)来自作者自家产品的 生态,数字真实性高,但要注意作者身份21。
  • 爱丽丝例子的每个组件参数都来自书中代码,可复现。

7. 边界与局限​

  • 本章的 prompt 经验都基于 2026 年的模型行为,下一代模型的指令跟随习惯 可能不同;「没有最优模板」这句是不会过时的。
  • 查询改写本章只讲了「拆指令与检索查询」这一种;更复杂的改写(多轮对话(来回多轮交谈)里 「它」指谁)留到第 13 章 agent 记忆处才有上下文。
  • LLM-as-a-judge 的偏差细节(self-referential bias 等)第 11 章展开。
  • 「够好的 70B」是写作时点的判断,小模型进步很快。

8. 可带走的​

  1. 检索查询 ≠ 用户问题:先把指令拆出去,再拿剩下的去检索;生成时用回原始问题;
  2. prompt 承重墙三句:材料给全、「不知道就说不知道」、XML 标签划界;
  3. 选模型找甜蜜点:满足质量期望的最便宜模型,靠评测集找,不靠感觉;
  4. 隐私是硬约束:air-gapped 只有开源模型一条路;
  5. LLM-as-a-judge 三缺点:慢贵、会幻觉、不一致;专用小模型(HHEM 类)是补充;
  6. 人工评测是金标准,但只放在自动化之后做终检;
  7. 基础栈到此闭环:解析→切块→嵌入→入库→检索→拼 prompt→生成,每一站你都能说出它在解决什么。

9. 原文地图​

主题原书章原文位置
查询改写、retrieval queryThe Query Flowtext/10-fm-the-query-flow.txt:17(搜「retrieval query」) · :4(搜「Write a poem」)
LLM 两大任务LLMstext/25-fm-llms.txt:4(搜「summarization」)
量化/FlashAttention/vLLMLLMstext/25-fm-llms.txt:12(搜「quantization」) · :18(搜「FlashAttention」)
air-gapped、70B 够好LLMstext/25-fm-llms.txt:7(搜「air-gapped」) · :36(搜「decent enough」)
prompt 工程各条RAG Prompt Engineeringtext/26-fm-rag-prompt-engineering.txt:7(搜「no absolute best」) · :34(搜「step by step」) · :40(搜「I don't know」) · :56(搜「XML」)
query 放前的顺序RAG Prompt Engineeringtext/26-fm-rag-prompt-engineering.txt:19(搜「original user query」)
评测三步Evaluating LLMs and Prompt Templatestext/27-fm-evaluating-llms-and-prompt-templates.txt:7(搜「evaluation queries」) · :13(搜「critics」) · :42(搜「weighted」)
judge 三缺点Evaluating LLMs and Prompt Templatestext/27-fm-evaluating-llms-and-prompt-templates.txt:33(搜「may not be consistent」)
HHEM、人工金标准Evaluating LLMs and Prompt Templatestext/27-fm-evaluating-llms-and-prompt-templates.txt:36(搜「HHEM」) · :39(搜「human evaluation」)
爱丽丝端到端例Chapter 1text/07-ch01-chapter-1-introduction-to-retrieval-augmented-ge.txt:311(搜「chunk_size」) · :292(搜「LanceDB」) · :347(搜「gpt-4o-mini」) · :370(搜「Mad Hatter」)

Footnotes​

  1. 出处:「The Query Flow」第 17-44 段(text/10-fm-the-query-flow.txt:17,搜「retrieval query」)。 ↩

  2. 出处:「The Query Flow」第 4 段(text/10-fm-the-query-flow.txt:4,搜「Write a poem」)。 ↩

  3. 出处:「The Query Flow」第 17 段(text/10-fm-the-query-flow.txt:17,搜「retrieval query」)。 ↩

  4. 出处:「Chapter 1」第 299-370 段(text/07-ch01-chapter-1-introduction-to-retrieval-augmented-ge.txt:311,搜「chunk_size」;:292,搜「LanceDB」;:347,搜「gpt-4o-mini」;:370,搜「Mad Hatter」)。「温度=0」的含义见样板解释:每次都挑概率最高的词,输出最稳定。 ↩

  5. 出处:「LLMs」第 4 段(text/25-fm-llms.txt:4,搜「summarization」)。 ↩

  6. 出处:「LLMs」第 33 段(text/25-fm-llms.txt:33,搜「sweet」)。 ↩

  7. 出处:「LLMs」第 36 段(text/25-fm-llms.txt:36,搜「decent enough」)。 ↩

  8. 出处:「LLMs」第 12 段(text/25-fm-llms.txt:12,搜「quantization」)与第 18 段(同文件,搜「FlashAttention」)。补充(不在书里,依据我们的 frontier 书架):vLLM 的高吞吐来自 PagedAttention 与连续批处理。依据: shelf=ai-frontier-reference/vllm 事实=该库的拆解覆盖了这两项核心机制。 ↩

  9. 出处:「RAG Prompt Engineering」第 7 段(text/26-fm-rag-prompt-engineering.txt:7,搜「no absolute best」)。 ↩

  10. 出处:「RAG Prompt Engineering」第 19-30 段(text/26-fm-rag-prompt-engineering.txt:19,搜「original user query」)。 ↩

  11. 出处:「RAG Prompt Engineering」第 40 段(text/26-fm-rag-prompt-engineering.txt:40,搜「I don't know」)。 ↩

  12. 出处:「RAG Prompt Engineering」第 34 段(text/26-fm-rag-prompt-engineering.txt:34,搜「step by step」)。 ↩

  13. 出处:「RAG Prompt Engineering」第 56 段(text/26-fm-rag-prompt-engineering.txt:56,搜「XML」)。 ↩

  14. 出处:「Evaluating LLMs and Prompt Templates」第 7-42 段(text/27-fm-evaluating-llms-and-prompt-templates.txt:7,搜「evaluation queries」)。 ↩

  15. 出处:「Evaluating LLMs and Prompt Templates」第 10 段(text/27-fm-evaluating-llms-and-prompt-templates.txt:10,搜「synthesize」)。 ↩

  16. 出处:「Evaluating LLMs and Prompt Templates」第 18 段(text/27-fm-evaluating-llms-and-prompt-templates.txt:18,搜「relevance」)与第 24 段(同文件,搜「faithfulness」)。 ↩

  17. 出处:「Evaluating LLMs and Prompt Templates」第 33 段(text/27-fm-evaluating-llms-and-prompt-templates.txt:33,搜「may not be consistent」)。 ↩

  18. 出处:「Evaluating LLMs and Prompt Templates」第 36 段(text/27-fm-evaluating-llms-and-prompt-templates.txt:36,搜「HHEM」)。 ↩

  19. 出处:「Evaluating LLMs and Prompt Templates」第 39 段(text/27-fm-evaluating-llms-and-prompt-templates.txt:39,搜「human evaluation」)。 ↩

  20. 出处:「Evaluating LLMs and Prompt Templates」第 42 段(text/27-fm-evaluating-llms-and-prompt-templates.txt:42,搜「weighted」)。 ↩

  21. 出处:「Evaluating LLMs and Prompt Templates」第 36 段(text/27-fm-evaluating-llms-and-prompt-templates.txt:36,搜「HHEM」)。 ↩