L1 & L2让 AI 说准，比让它说多重要

一位顾客问客服机器人：“这台空气炸锅保修多久？”机器人答：“两年。”可售后政策里写的是整机保修一年，只有加热管保修两年。答案里的每个字都能在文档里找到，拼在一起却是错的。

导读里说过，系统只需要“说”、任务边界清楚、要在 3 秒内回答时，L1 和 L2 往往就是正确答案。但架构选对了，不等于答案自动就对。这一篇讲谱系的前两层：

• L1（基础响应者）：LLM 被动生成，流程完全由外部代码控制，典型架构是 Prompt + RAG Definition 检索增强生成——简单说，就是让 AI 在回答前先去你指定的知识库里找资料，再根据资料写答案，不凭空编造 。
• L2（路由分发者）：LLM 负责识别意图，并把请求交给预先定义好的路径，典型架构是 Intent Classification + Router。

它们最容易在两件事上出错：检索不准，以及路由不可预测。下面先拆原因和对策，再看界面怎么配合，最后说它们的天花板，也就是什么时候该上 L3。

精确定义：L1 与 L2 做什么，不做什么

在讨论优化之前，有必要精确划定两个层级的能力边界，避免后续架构决策的起点就出了偏差。

L1 做的是被动生成（Context-based Generation）：在给定的上下文内生成答案。这个上下文可以来自模型的训练知识，在企业端更多来自外部检索（RAG）。

边界在这里：L1 不改变任何业务系统的外部状态。它不写入数据库，不触发工作流，不调用产生副作用的 API。它是一个只读的信息处理层，能力边界是“阅读、对比、总结、呈现”。

L2 做的是静态路由（Static Routing）。它在 L1 基础上增加了一层意图识别能力：判断用户意图，并将请求分发到预定义的执行路径上。这些路径是写死的——如果是退货申请，走 A 路径；如果是查物流，走 B 路径；如果是查价格，调用 C 接口。

边界在这里：L2 的规划能力是静态的（Static）。它能处理 if-else 的分支逻辑，但一旦任务需要“根据中间结果临时规划下一步”或“动态调整执行策略”，L2 就会失效。它本来就是这样设计的，实现得再好也改变不了。

一个常见的误区：层级错配

在进入架构优化之前，有一个高频的工程误区值得先点破：

graph LR
  A[系统一开始是 L1] --> B[发现精度不够]
  B --> C[疯狂堆 RAG 优化]
  C --> D[效果仍不理想]
  D --> E[直接跨级上 Multi-agent（L4）]

这条路径的问题，出在跳级之前：L1 的基础设计还没做对，就放弃了它。过早引入 Multi-agent 只会让原本可以被精准识别的错误，在复杂的编排层中被放大和掩盖。Anthropic 工程团队在总结大量客户实践后得出的建议是直接的：找到能解决问题的最简方案，只在真正需要时才增加复杂度。¹

在大多数要求精确的场景里，“最简方案”往往就是一个设计对了的 L1/L2，用不到更复杂的 Agent 系统。

L1 架构：检索精度的三类失效模式

L1 架构靠 RAG 取资料。RAG 解决了模型知识过时的问题，但在要求精确的业务场景里，会在三个层面系统性失效。理解这三类失效，才能知道在哪里下手优化。

失效模式一：分块切割破坏语义完整性

RAG 的标准流程是把文档切成若干 chunk Definition RAG 系统在建立知识库时，需要先把长文档切成若干小片段再存入索引——这个过程叫做【切块】（Chunking），每个小片段叫做一个 chunk。检索时，系统找的是最相关的那几个 chunk，不会把整篇文档拿出来。 ，向量化后存入索引库，查询时召回最相似的 chunk 喂给模型。问题在于“切”这个动作本身。

当文本按照固定 token 数切割时，一份售后政策里的某个条款，可能被切成几段，分散在不同的 chunk 里。开头那台空气炸锅就是这样：“整机保修一年”和“加热管保修两年”落在了两个 chunk 里。每段单独拿出来都没错，合在一起才是完整的意思，但 RAG 系统在召回阶段只能看到片段，看不到这条跨 chunk 的逻辑。

一项问答系统的对照实验（30 个问题）显示，在其他条件相同的 RAG 流程中，把固定 token 切割换成 Adaptive Chunking 后，“至少部分准确”的回答比例从 50% 升到 87%，检索召回率从 0.40 升到 0.88。² 样本不大，但差距说明：在要求精确的场景里，切割策略本身就是一个会明显影响结果的设计决策，值得认真想，不能随手设一个值了事。

实践中可选的改进方向包括：语义切割（按语义边界切，而不是按字数切）、命题切割（把文本拆成一个个独立的“事实句”，每句自成一体）、以及层级索引（在小片段上方再建一层章节摘要，检索时像翻目录一样，先定位章节，再精读内容）³。

失效模式二：领域语义偏差导致向量空间错位

向量检索的底层逻辑是：语义相近的文本在向量空间里距离更近。但这个“语义相近”是由 Embedding 模型定义的——而大多数通用 Embedding 模型是在通用语料上训练的。

电商里的“价保”和“保价”就是一个例子：前者是商品降价后补差价，后者是快递按声明的价值赔付。两个词几乎一样，意思完全不同。通用的向量模型很容易把它们当成一回事：顾客问“这一单能价保吗”，系统召回的可能是快递保价的条款。

这是 RAG 的一个系统性盲区：Embedding 模型与业务领域的语义偏差。应对方向是在领域标注数据上对 Embedding 模型进行微调（Fine-tune），使其向量表示更贴近领域语义结构。Prompt Engineering Guide 也提到：在专业领域中工作时，可能需要微调 Embedding 模型。⁴

失效模式三：多跳推理超出单次检索的能力边界

前两类失效可以通过优化切割策略和 Embedding 质量来缓解，但第三类失效涉及的是 RAG 的架构性限制。

有一类问题，单靠一次检索无法回答——它需要跨文档、跨章节的组合推理。例如：“今年的售后政策和去年比，哪些条款有实质性的变化？”

要回答这个问题，系统需要：① 找到去年的相关条款，② 找到今年的相关条款，③ 理解两者的差异，④ 判断差异是否“实质性”。这是一个多跳推理链，标准 RAG 的单次“检索-生成”流程，结构上无法支撑这类任务。

这一类我放到后面“天花板”一节再细说，因为它直接指向了 L1 架构的极限。

L1 优化策略：混合检索与可追溯性设计

理解了三类失效模式，优化方向就清晰了。以下两个策略是在要求精确的场景里被验证有效的方向，但需要注意：它们是在 RAG 上补强，替代不了它：快速召回候选，还是要靠向量检索。

策略一：混合检索（Hybrid Retrieval）

混合检索的基本思路是将两种互补的检索能力组合使用：

• 关键词检索 Definition 也称为稀疏检索 （BM25）：基于关键词的精确匹配——类似传统搜索引擎，找的是包含同样词语的文档，意思相近但用词不同的，它找不到。对专业术语和精确数字（比如商品型号、SKU 编号）的召回特别可靠。
• 密集检索（Dense Retrieval）：基于向量语义，对语义近似、表达多样的查询效果好。

在要求精确的场景里，推荐的做法是：密集检索用于快速召回语义相关的候选集，BM25 或结构化索引用于精确核实术语和数值。Anthropic 在 2024 年做过一组实验可以参照：给每个文本块补上它在原文里的上下文，再把向量检索和 BM25 结合起来，前 20 个结果里漏掉相关内容的比例从 5.7% 降到 2.9%；再加一步重排序，降到 1.9%。⁵ 这里多了“补上下文”这一步，降幅不能全算在混合检索头上；但他们的结论里有一条说得很直接：向量检索加 BM25，比只用向量检索好。

对于需要处理商品参数表、售后政策这类结构化长文档的场景，可以在 chunk 层之上构建层级索引（Hierarchical Index）：在每个节点存储数据摘要，检索时先定位章节，再精确读取内容——这更接近人读文档的方式。³

策略二：可追溯性设计（Source Traceability）

在实际使用中，有一个常被忽视的用户行为：用户并不只是需要答案，他们更需要知道答案从哪里来。

在售后、价格、赔付这类容易起纠纷的场景里，AI 给出的回答只是第一步——客服或顾客随后需要核对原始条款，确认措辞是否准确，再决定是否采纳。如果系统不能把每一个回答精准绑定到文档的章节甚至条款编号，人就只能自己去翻——这不只是效率问题，答错了还会引起纠纷。

因此，可追溯性是 L1 系统的基本要求：

• 每个生成结论必须附带来源文档名、章节、页码（如有可能，精确到段落或表格编号）。
• 当同一结论有多个来源时，需要标注来源之间是否存在矛盾。
• 当无法找到支撑来源时，系统应该拒绝生成，不自行推断。

这一步把 L1 系统从“给出答案的模型”变成了可验证的信息入口——这个定位的转变，是建立用户信任的第一步。

L2 架构：路由确定性的工程实现

如果说 L1 解决的是“如何找对信息”，那 L2 解决的是：在对的路径上处理对的请求。

L2 架构最难的是“确定性”——但这个词在工程上需要被精确定义，否则容易产生误导。

确定性的三个工程维度

• 可重现性（Reproducibility）：相同的输入，无论何时查询，都能定位到同一份文档或数据源。这靠的是索引稳定、有版本管理，和 LLM 无关。
• 路由一致性（Routing Consistency）：相同的用户意图，永远走相同的逻辑路径。这依赖分类器的稳定性和路由规则的显式定义。
• 输出结构化（Output Structuring）：LLM 的原始输出即使在 temperature Definition temperature 是控制 LLM 输出随机性的参数：设为 0 时理论上输出最确定，设为 1 时输出更有创意但也更不稳定。但即使是 temperature=0，不同版本的模型之间仍可能给出不同的措辞。 =0 的设置下，不同模型版本之间仍可能产生漂移。真正的确定性来自将输出约束在预定义的结构内（如 JSON schema、枚举选项、格式模板；例如规定 AI 只能输出“是／否／不确定”三种结论，不能随便写一段话），再加上下游的规则校验层。别指望模型自己每次都写出一字不差的输出。

L2 路由的两层架构

L2 路由在工程上是一条两层的流水线，前一层做完才轮到后一层。

第一层是意图分类器（Intent Classifier），负责将用户输入映射到预定义的意图类别。这一层的设计原则是：使用轻量、高确定性的分类模型，不把意图识别交给同一个生成型 LLM 来判断。

典型的分类粒度可以是：

• 开放式咨询（如“这两款空气炸锅有什么区别”）→ 进入 L1 检索流程
• 固定格式查询（如“导出我上个月的订单”）→ 直接调用对应 API 接口
• 范围外请求（如查别人的订单）→ 拦截并引导用户澄清
• 敏感请求（如要求赔偿的投诉、涉及人身安全的商品问题）→ 强制转人工

第二层是基于分类结果的路由策略，意图识别完成后才进入。这一层的原则是：最要紧的业务路径用硬编码（Hard-coded）规则，不让 LLM 自行决定。

例如，当顾客问某个商品的安全使用说明（比如电热毯能不能整夜开着），L2 路由应该直接指向经过人工审核的说明书和售后文档，不进入通用检索流程。这类信息必须权威，容不得任何“模糊召回”。

graph TD
  Input([用户输入]) --> Classifier[意图分类器]
  Classifier -- "意图评分/分类" --> Router[路由规则层]
  
  Router -- "A" --> L1[调用 L1 检索流程]
  Router -- "B" --> API[直接调用 API 接口]
  Router -- "C" --> Audit[走人工审核队列]
  Router -- "拒绝" --> Reject[触发引导响应，要求用户补充信息]

拒绝回答：最被低估的系统能力

在 L2 层级，最重要的控制逻辑，不是“如何回答”，而是“什么时候不该回答”。

学术界将这种能力称为“Abstention”（弃答/拒答）。Wen 等人在 TACL 发表的一篇 LLM 弃答机制系统综述中将其定义为：LLM 拒绝给出答案的行为，被认为具有减少幻觉、提升安全性的潜力。⁶ 在退款、赔付、商品安全这类问题上，一个过度自信的错误回答，代价往往远大于一句“我无法回答”。

在工程上，L2 系统的拒绝能力可以由三个层次叠加实现。

第一层是规则拦截（Rule-based Blocking）：对明确已知的边界条件硬编码。例如：如果问题涉及别人的订单、或者超出数据覆盖范围的时间段，直接拦截，返回标准化的引导语句（“当前系统只能查询近 12 个月的订单，您的查询超出范围，请确认时间”）。

这是最确定、成本最低的拒绝机制，适用于可以被规则穷举的边界情形。

第二层是检索置信度阈值（Retrieval Score Threshold）。在 RAG 流程中，每次检索都会产生一个相似度分数（Similarity Score）。当最高分的召回结果仍低于设定阈值时，意味着系统没有找到可靠的支撑材料——此时应该拒绝生成，别拿低质量的检索结果硬凑一个答案。

retrieval_results = retrieve(query)
if retrieval_results[0].score < CONFIDENCE_THRESHOLD:
    return "当前知识库中未找到与该问题直接相关的资料，
            请核实问题描述，或转人工客服"
else:
    return generate(query, retrieval_results)

第三层是边界识别分类器，用来识别“这个问题超出系统能力范围”。对于不能被规则穷举、但可以被语义识别的边界请求，训练一个专门的分类器来判断“这个问题是否在系统能力范围内”。也可以直接约束模型本身：IBM 的一项实验发现，域外问题的样本足够多样时，对模型做监督微调（SFT）效果最好；样本多样性有限时，Circuit Breakers（在模型内部表征层面拦截的方法）表现不错；两者叠加通常能兼得。⁷

UI/UX：约束输入，减少不确定性的来源

架构层面的确定性设计，需要前端交互设计的配合。对于非技术背景的业务人员，UI 设计要做的，是减少输入的模糊性——与其让系统猜用户的意图，不如让界面引导用户说清楚自己的意图。

以下是三个在实践中可以落地的设计模式。

模式一：意图感知的表单式对话

当意图分类器识别到高度结构化的意图类型（如“退货申请”“开发票”），系统主动弹出参数收集界面，让用户在下拉菜单里选择订单、退货原因、退款方式，而不是让用户手写一段话。

表单的每个字段直接对应路由规则中的一个参数槽位（Slot）。用户提交表单即等于完成了意图识别和参数提取，后端直接进入 L1 检索或 API 调用，无需再经过 LLM 的意图推断流程。

这适合任务结构高度可预期、用户大多不懂技术、系统只需要在固定的参数范围内工作的场合。

模式二：领域术语的分面引导（Faceted Search Guidance）

用户开始输入自由文本时，系统实时识别可能涉及的术语类别，在输入框旁提供术语联想列表，帮助用户在输入过程中选择标准化术语，免得最后输入一个写法不标准的说法。

术语标准化后的输入，显著降低了意图分类器的歧义，同时提升了 L1 检索阶段的向量召回精度（标准术语比自由表达有更稳定的向量表示）。

这适合术语和编号密集（商品型号、SKU、售后条款编号等）、用户对标准说法的掌握程度参差不齐的地方。

模式三：拒绝引导设计（Refusal UX）

当系统决定拒绝回答时，用户体验的处理方式直接影响用户对系统的信任评估。

错误做法：只显示“无法回答”，不给出任何下一步。

正确做法：拒绝响应应该包含三个要素：① 明确说明拒绝原因（“该查询超出当前数据覆盖范围”，不只是一句“我无法回答”）；② 引导用户修正输入（“请选择近 12 个月内的订单，或从下面的问题类型里选一个”）；③ 提供人工升级路径（“如需协助，请联系人工客服”）。

拒绝不等于失败。一个能正确识别自己边界的系统，本身就是可信度的体现。

L1/L2 的架构天花板：它们无法解决的三类问题

以上所有优化方向，都是在 L1/L2 的架构框架内工作的。但有三类业务场景，无论如何精细化 L1/L2 的设计，仍然会遭遇结构性失效。实现得再好也绕不过去，因为边界来自层级本身的定义。

判断“要不要引入 L3”，主要就看这三类问题。

天花板一：多跳推理（Multi-hop Reasoning）

运营问：“今年的售后政策和去年比，哪些条款改了，对我们的家电品类有什么影响？”

L1 在这里失效，因为这个问题需要跨多个文档、跨时间维度进行比较推理——系统首先需要找到两年的相关条款，比较它们的差异，判断差异的“实质性”程度，再把它对应到具体的品类。这是一个至少包含四个推理步骤的链式任务。

标准 RAG 的“单次检索-单次生成”流程，在结构上只支持一次检索、一次生成。它无法在中间步骤的输出上再次检索，也无法将一个问题分解成子问题逐步求解。RAGFlow 的工程实践报告也指出，“多跳问题”是 RAG 系统中语义鸿沟明显的典型场景之一，传统检索方法在此类场景中效果有限。⁸

这需要能够将问题分解为子任务、迭代执行的能力，这正是 L3（工具执行者）要做的事。

天花板二：动态规划（Dynamic Planning）

运营想把一款商品同时上架到三个国家的站点。每个国家对标签、认证和退货的要求不同，而且彼此牵连：为一个国家改了包装，可能影响另一个国家的认证。

L2 在这里失效，因为这个任务的处理路径无法在事前写死。系统需要先了解三个国家的基本要求，再识别它们之间的冲突点，然后基于冲突点决定下一步查询什么。换句话说，“第 N 步要做什么”取决于“第 N-1 步的结果”——这正是 L2 硬编码路由无法处理的动态规划需求。

L2 可以处理“如果是上架咨询，走 A 路径”的静态逻辑，但无法处理“根据检索结果，再决定走 A 还是 B 路径”的动态逻辑。

这需要能够在执行过程中，根据中间结果重新规划后续步骤的能力，这同样是 L3 要做的事。

天花板三：跨系统状态协调（Cross-system State Management）

运营要把一次大促的价格调整，同步到商品系统、会员系统和客服知识库三个地方。

L1/L2 在这里失效，因为如前所述，L1 的定义是“不改变业务系统的外部状态”，L2 的执行路径是预定义的。两者都无法处理需要协调多个外部系统、维护跨系统一致性、且需要根据每个系统的响应状态动态决定后续操作的任务。

这类场景需要调用外部工具，还要在几个工具之间维护状态、处理部分失败（比如商品系统改好了，客服知识库却超时没更新）。这些都是 L3（工具执行者）要处理的问题；只是跨几个系统，还用不到 L4。

这三类失效模式，勾勒出了 L1/L2 的系统性边界：当任务需要跨步骤的动态推理、跨系统的状态协调、或基于中间结果的路径重规划时，L1/L2 架构就走到了极限。这也是 L3 存在的根本理由，我会在下一篇里细拆。

商业决策：何时停留在 L1/L2，何时升级

在实际的业务决策中，以下判断框架可以帮助评估当前场景是否需要超出 L1/L2：

如果以下条件全部成立，L1/L2 是正确的选择：

• 任务有明确的对/错标准（不靠主观判断）
• 系统只需要输出信息，不需要改变外部系统状态
• 每次查询是独立的，不需要跨步骤积累中间结果
• 响应时延要求在 3 秒以内

如果出现以下任何信号，应该认真评估是否引入 L3：

• 用户的问题需要跨多个文档组合推理才能回答
• 系统需要根据第一步的检索结果，决定第二步查询什么
• 有效回答需要调用外部 API 并根据返回值做判断
• 存在需要“思考再思考”的复杂场景（如对答案的自我验证）

精度不够，先查检索，再考虑换模型。 如果 L1 的回答不够准确，第一步应该审查 Chunking 策略、Embedding 质量和检索召回逻辑，之后才轮到换一个更大的模型，或者跳到 L3。

结语：说准，比说多重要

回到开头那台空气炸锅。机器人答“两年”，问题出在模型之外：两个条款被切开了，检索没把它们一起找回来，系统也没附上出处让人自己核对。L1 和 L2 的功夫，多半就花在这些地方：切对、找准、标出处，该拒绝的时候拒绝。

这样做出来的系统看起来不算聪明，但行为稳定、边界清楚，用户不需要每次都去验证它。每一次有出处的回答，都在积累一点信任；每一次没有依据却硬答，都在消耗它。

可预测也意味着有边界。问题要拆成几步、下一步取决于上一步的结果，或者要真的去改几个系统时，L1 和 L2 就接不住了。下一篇讲 L3：从这一层起，下一步由模型来定。