L1 & L2：当你需要 AI"说准"而非"说多" - AI系统的检索精度、路由确定性与架构边界

本篇聚焦谱系的前两个层级：

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

在导读中我们提到，当一个系统只需要”说”（输出信息）、任务边界清晰、时延要求低于 3 秒，L1/L2 往往就是正确答案。

但”正确答案”不等于”自动奏效”。在制药、金融、法律合规等对数据精度要求苛刻的行业里，L1/L2 架构若设计不当，会在两类核心问题上系统性失效：检索精度不足，以及路由行为不可预测 。

本篇将逐一拆解这两个问题的根因、工程应对策略，以及 UI 设计的配套逻辑。最后，我们将正面分析 L1/L2 的架构天花板——理解这个边界，是决定何时需要引入 L3 的前提。

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

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

L1：被动生成（Context-based Generation）

L1 的核心能力是：在给定的上下文内生成答案。这个上下文可以来自模型的训练知识，在企业端更多来自外部检索（RAG）。

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

L2：静态路由（Static Routing）

L2 在 L1 基础上增加了一层意图识别能力：它可以判断用户意图，并将请求分发到预定义的执行路径上。这些路径是写死的——如果是合规问询，走 A 路径；如果是报表导出，走 B 路径；如果是价格查询，调用 C 接口。

关键的边界约束：L2 的规划能力是静态的（Static）。它能处理 if-else 的分支逻辑，但一旦任务需要”根据中间结果临时规划下一步”或”动态调整执行策略”，L2 就会失效——这不是 L2 的实现缺陷，而是它的设计定位。

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

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

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

        

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

在大多数高监管行业的场景中，“最简方案”往往就是一个被正确设计的 L1/L2，而不是更复杂的 Agent 系统。

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

RAG 是 L1 架构的核心机制。它解决了模型知识过时的问题，但在高精度业务场景下，会在三个层面系统性失效。理解这三类失效，才能知道在哪里下手优化。

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

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

当文本按照固定 token 数切割时，一份年度合规报告里的某个政策条款，可能被切成三段分散在不同 chunk 中。每段单独拿出来都是合法的文字，拼在一起才有意义。但 RAG 系统在召回阶段只能看到片段，无从知晓这个跨 chunk 的逻辑链条。

来自医疗领域的对照实验显示，在相同 RAG pipeline 中，将固定 token 切割替换为语义感知的 Adaptive Chunking 后，准确率从 50% 提升到 87%，检索相关性也显著改善。² 这个数字的规模说明，在高精度场景下，切割策略本身就是一个可以产生量级差异的设计决策，而不是一个可以随手设定的配置项。

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

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

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

在制药领域，“适应症”、“禁忌症”、“批准路径”这类专业术语，在通用向量空间里的表示质量会显著低于日常词汇。用户提问”该药品的孤儿药认定条件”，系统可能召回的是”孤儿”相关的无关文本，而不是监管政策条款。

这是 RAG 的一个系统性盲区：Embedding 模型与业务领域的语义偏差。应对方向是在领域标注数据上对 Embedding 模型进行微调（Fine-tune），使其向量表示更贴近领域语义结构。Prompt Engineering Guide 的工程建议也明确指出：在特定垂直领域中工作时，对 Embedding 模型进行微调通常是必要的步骤，而非可选项。⁴

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

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

有一类问题，单靠一次检索无法回答——它需要跨文档、跨章节的组合推理。例如：“根据 2023 年和 2024 年的合规报告，哪些政策条款在两年间发生了实质性修改？”

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

这个失效模式我们会在本篇末尾进一步分析，因为它直接指向了 L1 架构的天花板。

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

理解了三类失效模式，优化方向就清晰了。以下两个策略是在高监管场景中被验证有效的方向，但需要注意：它们是 RAG 的补充增强，而非替代——向量检索仍然是快速召回候选的核心机制。

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

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

关键词检索（BM25）：基于关键词的精确匹配——类似传统搜索引擎，找的是包含同样词语的文档，而不是语义相近的内容。对专业术语和精确数字的召回特别可靠。

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

在高监管场景中，推荐的实践是：密集检索用于快速召回语义相关的候选集，BM25 或结构化索引用于精确核实关键术语和数值。研究表明，混合检索在领域专项 RAG 部署中，检索正确率和排序精度最高可提升 13.1%。⁵

对于需要处理表格、年度报告等结构化长文档的场景，可以在 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 路由应该直接指向经过人工审核的 SOP 文档库，而不是进入通用检索流程——因为这类信息的权威性要求，不允许任何”模糊召回”的可能性。

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

        

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

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

学术界将这种能力称为”Abstention”（弃答/拒答）。MIT Press 在一篇对 LLM 弃答机制的系统综述中将其定义为：LLM 拒绝给出答案的行为，被认为具有减少幻觉、提升安全性的潜力。⁶ 研究还发现，在高风险领域（医疗、法律、合规），过度自信但错误的回答所造成的损害，远大于明确告知”我无法回答”。

在工程上，L2 系统的拒绝能力可以通过以下三个层次叠加实现：

层次一：规则拦截（Rule-based Blocking） 对明确已知的边界条件硬编码。例如：如果问题涉及竞争对手尚未公开的财务数据、或数据库覆盖范围之外的时间段，直接拦截，返回标准化的引导语句（“当前系统仅覆盖 2020–2024 年数据，您的查询超出范围，请确认时间区间”）。

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

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

retrieval_results = retrieve(query)
if retrieval_results[0].score < CONFIDENCE_THRESHOLD:
    return "当前知识库中未找到与该问题直接相关的资料，
            请核实问题描述或联系数据管理员"
else:
    return generate(query, retrieval_results)

层次三：边界识别分类器（用于识别”这个问题超出系统能力范围”） 对于不能被规则穷举、但可以被语义识别的边界请求，训练一个专门的分类器来判断”这个问题是否在系统能力范围内”。研究表明，当系统积累了足够多样的”超出范围的问题”样本时，训练一个专门的分类器来识别这类问题效果最好；当样本数量有限时，基于规则的拦截方法也能取得不错效果；两者组合使用通常能同时覆盖两种情况。⁷

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

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

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

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

表单的每个字段直接对应系统后端需要的一个参数。用户提交表单，就等于完成了意图识别和参数收集，系统无需再经过 AI 推断，直接进入检索或调用流程。

触发条件：意图分类器识别到高度结构化的意图类型（如”竞品分析”、“合规查询”）。

交互方式：系统主动弹出参数收集界面，要求用户在下拉菜单中选择药品名称、时间范围、分析维度，而非让用户手写自然语言 Prompt。

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

适用场景：任务结构高度可预期，用户群体以业务人员为主（非技术背景），系统需要在特定参数范围内工作的场合。

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

触发条件：用户开始输入自由文本时，系统实时识别可能涉及的术语类别。

交互方式：在输入框旁提供术语联想列表，帮助用户在输入过程中选择标准化术语，而非最终输入一个可能存在拼写变体的非标表达。

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

适用场景：专业术语密集（药品名、监管条款编号、疾病 ICD 编码等），用户对标准术语的掌握程度参差不齐的领域。

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

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

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

正确做法：拒绝响应应该包含三个要素：① 明确说明拒绝原因（“该查询超出当前数据覆盖范围”，而不是模糊的”我无法回答”）；② 引导用户修正输入（“请将时间范围缩短至 2020–2024 年，或选择以下可查询的数据类型”）；③ 提供人工升级路径（“如需协助，请联系 [数据支持渠道]”）。

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

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

以上所有优化方向，都是在 L1/L2 的架构框架内工作的。但有三类业务场景，无论如何精细化 L1/L2 的设计，仍然会遭遇结构性失效——这不是实现质量的问题，而是层级定义本身的边界。

理解这三类失效模式，是判断”是否需要引入 L3”的核心依据。

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

场景描述：用户提问”2023 年至 2024 年间，哪些合规条款发生了实质性修订，对我们的产品线有直接影响？”

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

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

需要什么：能够将问题分解为子任务、迭代执行的能力——这是 L3（工具执行者）的核心能力。

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

场景描述：用户提交了一个新型药品的上市准入咨询，涉及三个国家的不同监管框架，且各国要求之间存在相互制约关系。

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

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

需要什么：能够在执行过程中，根据中间结果重新规划后续步骤的能力——同样是 L3 的核心能力。

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

场景描述：用户需要将一份内部研究报告的关键结论，同步更新到 CRM 系统、内部知识库和合规审批系统三个平台。

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

这类场景不仅需要调用外部工具（L3 的能力），还需要在多工具之间维护上下文状态、处理部分失败的情况（如 CRM 更新成功但合规系统超时）——这进一步涉及到 L4（协同编排者）的能力边界。

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

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

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

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

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

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

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

精度问题应该优先通过检索路径解决，而不是模型规模。 如果 L1 的回答不够准确，第一步应该审查 Chunking 策略、Embedding 质量和检索召回逻辑，而不是换一个更大的模型或直接跳到 L3。

结语：确定性是信任的基础，也是边界

回到导读中提出的一个核心观点：在高监管行业，AI 产品的成败不取决于它能做多少事，而取决于它在多大程度上是可预测的。

如果把 L1/L2 系统的每一次可追溯的引用视为一次”信用存款”——用户看到了来源，验证了准确性，建立了一次信任——那么每一次系统在没有可靠依据的情况下仍然强行生成，就是一次”信用违约”。几次违约之后，用户开始对所有输出持怀疑态度，系统的业务价值就从根本上被侵蚀了。

L1/L2 的设计目标，不是让系统看起来更聪明，而是让系统的行为稳定、边界清晰、不需要被反复验证。这种可预测性，在高监管行业里是准入门槛，在其他场景里则是用户信任的基础。 两者的要求程度不同，但设计方向是一致的。

但可预测性也意味着有边界。当业务需求的复杂度超出了静态路由和单次检索的能力范围，强行让 L1/L2 “撑住”只会制造一个看似稳定、实则脆弱的系统。

承认边界，是架构成熟度的体现；而识别边界，是迈向 L3 的起点。

下一篇，我们将进入 L3（工具执行者）：当系统开始主动决定调用什么工具、以什么顺序执行，LLM 从”被动生成”变成了”主动规划”——这个转变带来了真正的能力跃升，也带来了必须正视的工程复杂性。