2026 AI/LLM黑话速通：Prefill、RLVR、GraphRAG，进阶概念怎么用？从小白到听懂面试官在说什么（下）

承接上篇第 12 节，本篇继续整理第 13 到第 20 个概念，重点放在推理加速、训练反馈、检索增强和 Agent 工程实践；文末会用两张表把上下两篇的概念放回同一套技术栈中对照理解。

13. Prefill / Decode：读题和答题

核心原理

一次 LLM 请求通常分为两个阶段：

Prefill 特点：

• 计算密集型。
• 主要消耗矩阵乘法算力。
• prompt 越长，这一阶段越重。

Decode 特点：

• 更偏内存带宽密集型。
• 需要频繁读取 KV Cache。
• 输出越长，这一阶段越明显。

工程实现

Prefill / Decode 增量推理伪代码：

defserve(prompt):# Prefill：处理完整输入logits,kv_cache=model.forward(prompt,past_kv=None)# Decode：逐 token 生成output_tokens=[]for_inrange(max_new_tokens):# 从当前概率分布中选出下一个 tokennext_token=sample(logits)# 把生成结果追加到输出序列output_tokens.append(next_token)# 如果已经生成结束符，就不再继续解码ifnext_token==eos:break# 只计算最新 token，并继续复用前面得到的 KV Cachelogits,kv_cache=model.forward(next_token,past_kv=kv_cache)returnoutput_tokens

实践建议

生产系统中可以根据负载做分离调度：

• 长 prompt 请求优先进入高吞吐 Prefill 资源池。
• 长输出请求需要更关注 Decode 阶段的延迟和 KV Cache 显存。
• 是否物理拆分 Prefill / Decode 节点，取决于系统规模、模型大小和网络传输成本。

14. RLVR：把可验证结果变成训练奖励

核心原理

RLVR是Reinforcement Learning with Verifiable Rewards，即基于可验证奖励的强化学习。

它的核心思路是：

如果一个任务能自动判断答案好坏，就可以把这个判断结果直接当作奖励信号。

和依赖人类偏好打分的 RLHF(Reinforcement Learning from Human Feedback) 不同，RLVR 更强调可验证、可程序化、可复现的奖励。

典型场景包括：

• 数学题：答案是否匹配，符号推导是否等价；
• 代码题：单元测试是否通过；
• 结构化输出：JSON Schema 是否通过；
• 格式任务：字段是否齐全，类型是否正确；
• 工具任务：调用结果是否满足目标条件。

工程实现

奖励函数设计：

训练流程概念版：

forpromptintrain_prompts:# 清空上一轮梯度，避免不同 batch 的梯度意外累积optimizer.zero_grad()# 同一个题目生成多个候选答案，方便比较好坏responses=model.generate_many(prompt,n=8)rewards=[]forresponseinresponses:# 用规则、测试或工具自动判断答案质量reward=verify_with_rules_or_tools(prompt,response)rewards.append(reward)# 根据奖励计算强化学习目标，让高奖励答案更容易被生成loss=rl_objective(responses,rewards)loss.backward()# 更新模型参数optimizer.step()

实践建议

RLVR 很适合“答案能验”的任务，但不适合所有任务。

比如开放式写作、审美判断、战略建议这类任务，很难用一个确定规则判断“对”或“错”。这时如果强行设计奖励，可能会出现奖励黑客、格式投机或表面优化。

• 奖励函数要尽量可靠，不能只奖励“看起来像正确答案”。
• 对代码任务，单元测试要覆盖边界条件，避免模型钻测试漏洞。
• 对数学任务，要避免只看最终字符串匹配，最好支持等价表达式或数值验证。
• 奖励太稀疏时，训练会不稳定，可以加入过程约束、格式约束或更细粒度检查。
• RLVR 是后训练工具箱的一部分，不是替代 SFT、RAG 或人工评测的万能方案。

15. Test-time Compute：推理时计算

核心原理

Test-time Compute，也叫测试时计算或推理时计算，最值得关注的地方不是“推理本来就要花算力”，而是：在模型参数不再更新的情况下，主动增加推理阶段的计算，让模型在交付最终答案之前多生成、多比较、多验证、多搜索。

这个概念在推理模型兴起之后变得重要，是因为它把“模型能力提升”从单纯的训练阶段扩展到了推理阶段：预训练时代主要问“训练时多给多少数据和算力”，推理模型时代还要问“回答这一题时，值得给多少思考、搜索和验证预算”。

可以把它理解成三件事的组合：

• 生成更多可能性：一次不够，就生成多个候选答案或多条推理路径。
• 判断哪些更可靠：用投票、规则、测试、奖励模型或验证器筛选。
• 把推理当成搜索：不是只让模型顺着一个答案写到底，而是在多个中间状态之间扩展、回溯和选择。

三条实现路径

这三条路径并不互斥：简单系统可以只做多候选选择，复杂系统可能同时使用长链推理、搜索和验证。

实践建议

• 多数投票适合做基线，复杂任务更需要验证器、过程奖励或搜索。
• 不要只增加输出长度，真正有价值的是提高有效搜索密度。
• 在线搜索很强，但成本高；也可以把搜索得到的高质量轨迹沉淀为训练数据，用来提升后续模型。

16. Thinking Budget：给 AI 的思考预算

核心原理

Thinking Budget是显式指定模型推理时可用的计算资源。

它可以表现为：

• 最大生成 token 数；
• 搜索宽度；
• 迭代次数；
• 时间预算；
• 可调用工具次数；
• 候选答案数量。

核心是在速度和深度之间做取舍。

工程实现

应用层预算参数：

在应用层加入类似参数：

thinking_budget

它不一定是模型 API 的原生参数，也可以是系统自己维护的调度策略。

策略示例：

调度伪代码：

classThinkingScheduler:defget_budget(self,query):# 简单问题少花算力，优先降低延迟ifis_simple_question(query):return1# 代码和数学更容易从多步推理或工具检查中受益elifis_code_or_math_task(query):return8# 普通分析任务使用中等预算else:return3

实践建议

• 不要把“思考预算”简单等同于“越大越好”。
• 对用户可见的产品，要提供速度与质量之间的清晰选择。
• 对企业场景，要把成本、延迟和成功率放在一起评估。

17. Speculative Decoding：让小模型先写，大模型来审

核心原理

Speculative Decoding，即推测解码/投机推断。该方法实现了在不降低目标大模型输出质量的前提下，减少大模型逐 token 解码的次数，从而提升生成速度、降低延迟和成本。

它的思路是：先让一个便宜的小模型，也叫 draft model，快速生成几个候选 token；再让大模型，也叫 target model，一次性并行验证这些候选 token。

如果候选 token 被接受，就直接使用；如果某个位置不被接受，则从修正后的目标分布中重新采样。

**核心指标：**接受率（acceptance rate）。

接受率越高，加速效果越明显。

很多文章会把推测解码讲成：

小模型先猜，大模型看看猜得对不对。

这个说法便于理解，但不够严谨。

更准确地说，大模型不是只看“小模型猜出的下一个 token，是不是自己最想生成的那个 token”。它会比较这个候选 token 在小模型和大模型各自判断中有多大可能性，再决定接受还是拒绝，从而尽量让加速后的生成结果，接近“完全由大模型自己一步步生成”的结果。具体的算法原理在这位老师的博客写的很好：https://charlestar.github.io/2026/05/12/%E6%8E%A8%E6%B5%8B%E8%A7%A3%E7%A0%81SpeculativeDecoding%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/

通俗易懂的讲，Speculative Decoding能够提升生成速度的核心原因是：

普通解码：大模型生成 4 个 token，要跑 4 次大模型。 推测解码：小模型先猜 4 个 token，大模型只跑 1 次来验证这 4 个 token。

普通解码：

Prompt → 大模型 → token1 Prompt + token1 → 大模型 → token2 Prompt + token1 + token2 → 大模型 → token3 Prompt + token1 + token2 + token3 → 大模型 → token4

大模型跑了 4 次。

推测解码：

小模型先猜：token1 token2 token3 token4 Prompt + token1 + token2 + token3 + token4

→ 大模型一次 forward
→ 同时得到 4 个位置的概率

工程实现

基本步骤：

1. Draft 模型自回归生成k个候选 token。
2. Target 模型对这k个候选 token 做一次批量验证。
3. 对候选 token 逐个做接受 / 拒绝判断。
4. 一旦拒绝，就从修正后的目标分布中采样，并结束本轮。
5. 继续下一轮推测解码。

实践建议

• Draft 模型要足够快，也要和 target 模型分布足够接近。
• Draft 模型与 target 模型最好使用一致或兼容的 tokenizer。
• k不是越大越好；过大时接受率下降，反而浪费计算。
• 适合输出比较可预测的场景，例如代码补全、格式化文本、结构化回答。

18. GraphRAG：基于知识图谱的RAG

核心原理

GraphRAG是在 RAG 基础上引入知识图谱或图结构。

传统 RAG 更擅长找相关片段；GraphRAG 更适合处理关系密集、需要跨文档整合的问题，例如：

• A 依赖哪些 B？
• 某项目和哪些系统有关？
• 某客户投诉和哪些版本变更有关？
• 一个组织内部有哪些主题、社区和关系链？

工程实现

构建流程：

1. 从文档中抽取实体、关系、事件或主题。
2. 构建图结构，例如实体关系图、社区图或主题图。
3. 对图进行聚类或社区发现。
4. 为图节点、社区或关系生成摘要。
5. 查询时根据问题召回相关图结构和文本证据。
6. 将图结构描述与文本证据一起交给模型回答。

实际例子：客户投诉归因

假设知识库里有三类材料：客服工单、版本发布记录、系统依赖文档。负责售后的技术支持收到投诉后，问AI助手：

客户 Alpha 升级到 3.2.1 后订单支付失败，可能和哪些系统变更有关？

普通 RAG 可能只召回“支付失败”的工单片段；GraphRAG 会先把材料抽成图关系：

(Alpha)-[:提交]->(工单 T-1023) (工单 T-1023)-[:提到]->(payment-service) (版本 3.2.1)-[:修改]->(payment-service) (版本 3.2.1)-[:引入]->(签名算法调整) (payment-service)-[:依赖]->(auth-service)

查询时可以沿着“客户 → 工单 → 服务 → 版本变更 → 依赖服务”这条关系链召回证据：

MATCH (c:Customer {name: 'Alpha'})-[:SUBMITTED]->(t:Ticket)-[:MENTIONS]->(s:Service) OPTIONAL MATCH (r:Release {version: '3.2.1'})-[:CHANGED]->(s) OPTIONAL MATCH (r)-[:INTRODUCED]->(change) OPTIONAL MATCH (s)-[:DEPENDS_ON]->(dep:Service) RETURN t.id, s.name, r.version, change.name, dep.name

最终交给模型的上下文就不只是几个相似文本片段，而是：

图结构摘要：Alpha 的工单 T-1023 提到 payment-service；版本 3.2.1 修改了 payment-service，并引入签名算法调整；payment-service 依赖 auth-service。 原文证据：工单中的错误描述、发布记录中的变更说明、依赖文档中的服务链路。 用户问题：客户 Alpha 升级到 3.2.1 后订单支付失败，可能和哪些系统变更有关？

这样模型更容易回答：“优先排查 3.2.1 中 payment-service 的签名算法调整，以及它与 auth-service 的鉴权兼容性。”

实践建议

• 对小型 FAQ 或简单知识库，普通 RAG 往往已经够用。
• 对长报告、组织知识、跨文档主题分析，GraphRAG 更有优势。

19. Worktree：给每个 AI 分一个独立工位

核心原理

工作树严格意义上并不算LLM相关的黑话，只是在AI coding“更高更快更强”的过程中，该工具的优势逐渐凸显。Git Worktree允许在同一仓库下创建多个独立工作目录，是AI辅助代码开发时代的神器。

在普通开发里，它的作用是让你不用反复切分支，也能同时打开多个分支。

在 AI Agent 辅助的开发过程中，它更像是给每个 Agent 或每个任务分配一张独立工位：

主仓库 main ├─ ../wt-fix-login 分支 agent/fix-login，交给 Agent A 修登录问题 ├─ ../wt-add-tests 分支 agent/add-tests，交给 Agent B 补测试 └─ ../wt-update-docs 分支 agent/update-docs，交给 Agent C 改文档

这些目录共享同一份 Git 仓库历史，但各自有独立的文件树、分支和未提交状态。

这样做的好处是：多个 Agent 可以并行工作，互不覆盖对方正在修改的文件；每个 Agent 的改动也可以单独测试、单独审查，最后再决定是否合并回主分支。

为什么我们要在开发中使用worktree:

工程实现

典型流程：

1. 为每个任务创建一个独立分支和 worktree。
2. 把 Agent 的工作目录限制在对应 worktree 中。
3. Agent 在自己的 worktree 里修改、运行测试、提交结果。
4. 主仓库统一 review、比较差异并合并。

创建两个 Agent 工作区：

gitworktreeadd-bagent/fix-login../wt-fix-login maingitworktreeadd-bagent/update-docs../wt-update-docs main

此时可以让两个 Agent 分别在不同目录中运行：

Agent A 的 cwd = ../wt-fix-login Agent B 的 cwd = ../wt-update-docs

如果两个 Agent 都改了同一个文件，冲突会在合并阶段暴露，而不是在工作过程中互相覆盖。

实践建议

• 多个 Agent 并行处理不同 issue。
• 避免多个任务在同一个工作目录里相互覆盖。
• 避免未提交状态相互污染。
• 便于回滚和审查。
• 每个任务都要绑定清晰分支名。
• Agent 修改前先同步主分支，减少后续冲突。
• 合并前要跑测试和代码审查。
• 临时 worktree 要及时清理，避免仓库膨胀。
• Worktree 只隔离代码目录和 Git 状态，不等于安全沙箱；运行命令、访问网络、改数据库仍然需要额外权限控制。

把这些概念串起来看

假设你要做一个 AI 编程助手，可以这样理解整套技术栈：

进一步拆成四个核心问题：

总结一下

2026 年的 LLM 相关概念，已经不只是“模型参数多大”这么简单。

真正重要的变化是：

AI 正在从聊天框，变成一个能接工具、会查资料、能写代码、能按流程执行任务的数字员工。

本篇只是建立直觉性的理解，真正做到方法应用，还需要对各个概念进行深入的理解和研究。