假设我们需要为一家企业搭建员工制度 AI 助手，让员工可以直接询问：

正式员工每年有多少天年假？申请年假需要提前多久？

出差住宿费可以报销多少？需要提供哪些材料？

上班迟到几分钟会被记录？忘记打卡应该怎么办？

这些问题看起来只是简单的问答，但要让 AI 稳定、准确地回答，就需要解决一系列工程问题：

1. 如何将员工手册、报销制度和考勤规则转换为可检索的知识？
2. 什么是 Chunk？为什么不能简单地把整份员工手册直接交给大模型？
3. 如何结合 BM25 关键词检索与向量检索，找到真正相关的内容？
4. 为什么初步召回之后，还可能需要 Rerank 重排序？
5. 如何让大模型基于制度原文回答，并提供引用来源？
6. 如何评估答案质量，并在准确性、延迟和成本之间取得平衡？

本文先总结 RAG 的核心概念，再通过一个完整的员工制度示例，逐步说明知识处理、检索、生成与评估的实现思路。

一、RAG、Chunk 与相关概念

1.1 什么是 RAG？

RAG 是 Retrieval-Augmented Generation 的缩写，中文通常称为“检索增强生成”。

它的核心思路是：

先从外部知识库中检索相关资料，再将这些资料提供给大语言模型，让模型基于检索结果生成答案。

传统的大模型问答通常可以简化为：

flowchart TD
    A[用户问题] --> B[大语言模型（LLM）]
    B --> C[生成答案]

RAG 则在生成之前增加了知识检索：

flowchart TD
    A[用户问题] --> B[检索知识库]
    B --> C[获取相关资料]
    C --> D[大语言模型（LLM）]
    D --> E[生成答案]

这里的知识库可以包含企业内部文档、产品手册、技术文档、合同、FAQ 和业务规范等。

RAG 并不是重新训练一个大模型，也不是让模型永久记住所有企业资料。它是在每次处理问题时，动态地检索相关知识，并将其作为生成答案的依据。

对于企业内部问答，这种方式有三个重要价值：

• 知识可更新： 制度变更后，可以更新知识库，而不必为了这些变化重新训练大模型。
• 答案可追溯： 可以将回答关联到原始文档、章节或页码。
• 知识可控制： 可以结合元数据、用户身份和访问权限，限制检索范围。

但 RAG 并不保证答案一定正确。如果检索阶段漏掉了关键内容，或者检索到了过期制度，模型仍然可能给出错误答案。

1.2 什么是 Chunk？

Chunk 是将一份较长的文档切分后得到的文本片段。

例如，一份员工手册可能包含以下章节：

• 员工手册
  • 第一章：入职与离职
  • 第二章：考勤管理
  • 第三章：休假制度
  • 第四章：费用报销
  • 第五章：绩效管理

如果直接把整份员工手册当作一个检索单元，那么当员工询问年假时，系统可能只能找到整份手册，而无法精准定位到年假条款。

因此，可以将文档切分为多个 Chunk：

Chunk 001：年假额度与适用范围
Chunk 002：年假申请流程
Chunk 003：年假结转规则
Chunk 004：迟到与早退规定
Chunk 005：忘记打卡处理流程
Chunk 006：差旅住宿报销标准
Chunk 007：报销材料与审批流程

每个 Chunk 都是一个相对独立的检索单元。

当用户询问年假申请流程时，系统可以直接检索与申请规则有关的片段，而不是把整份员工手册重新交给模型处理。

需要注意，Chunk 不一定对应一个完整的自然段，也不一定对应一个固定长度的字符串。它可以是一个段落、几个连续段落、一个表格片段，或者一个经过语义切分的制度条款。

Chunk 的设计目标，是让每个片段尽量保留完整的业务含义，同时便于检索、排序和引用。

1.3 Chunk Size 和 Overlap 是什么？

Chunk Size 表示一个 Chunk 的目标大小，通常可以按 Token 数量衡量，也可以在某些系统中按字符数衡量。

Overlap 表示相邻 Chunk 之间重复保留的内容，用于降低切分边界造成的信息丢失。

例如，原始制度文本为：

员工每年享有 10 天带薪年假。
申请年假时，应至少提前 3 个工作日提交申请。
连续休假超过 5 个工作日的，需要额外经过部门负责人审批。

如果切分得过细，可能得到：

Chunk A：员工每年享有 10 天带薪年假。

Chunk B：申请年假时，应至少提前 3 个工作日提交申请。

Chunk C：连续休假超过 5 个工作日的，需要额外经过部门负责人审批。

这在很多情况下是合理的，但如果某条规则必须结合上一段的适用条件才能理解，过细切分就可能破坏上下文。

如果切分得过粗，则可能把年假、考勤、报销等不同主题放进同一个 Chunk，降低检索的精确性。

因此，切分策略需要在上下文完整性和检索精度之间取得平衡。

Chunk Size 和 Overlap 没有适用于所有场景的固定最优值。实际项目需要根据文档结构、查询类型、Embedding 模型和评测结果进行调整。

1.4 RAG 中几个重要的技术组件

这些组件并不意味着每个 RAG 项目都必须使用全部技术。合理的工程设计应当从最简单、可验证的方案开始，再根据真实问题的失败情况增加复杂度。

二、员工制度 RAG 知识库的整体设计

2.1 明确业务目标

假设一家企业希望将员工手册、报销制度和考勤规范接入 AI 助手。

业务目标不是让模型泛泛地解释人力资源知识，而是让员工能够查询本企业当前有效的制度。

例如：

• 年假：额度、申请时间、审批流程、结转规则。
• 报销：费用标准、适用范围、所需凭证、审批流程。
• 考勤：迟到定义、打卡要求、漏打卡处理、异常申诉。

这类业务具有几个典型特点：

1. 制度文本相对稳定，但会定期更新。
2. 部分规则具有明确的数字、时间、金额和条件。
3. 同一个词可能在不同制度中具有不同含义。
4. 员工只能访问其有权限查看的信息。
5. 回答错误可能导致员工依据错误政策采取行动。

因此，知识库不应只关注语义相似度，还需要考虑制度版本、适用对象、有效日期和原始出处。

2.2 系统架构

一个基础的企业员工制度 RAG 系统可以分为离线知识处理和在线问答两条链路。

flowchart TD
    A[员工手册、报销制度、考勤规范] --> B[文档解析]
    B --> C[清洗与结构识别]
    C --> D[Chunk 切分]
    D --> E[添加元数据]
    E --> F[生成 Embedding]
    F --> G[向量数据库]
    E --> H[关键词索引]
    I[员工提问] --> J[身份认证与权限确定]
    J --> K[问题处理]
    K --> L[BM25 关键词检索]
    K --> M[向量检索]
    L --> N[合并去重]
    M --> N
    N --> O[Rerank]
    O --> P[上下文组装]
    P --> Q[大语言模型]
    Q --> R[答案与引用来源]

图中的关键词索引和向量数据库属于两种不同的检索基础设施，可以使用不同的存储系统，也可以使用支持混合检索的统一系统实现。

在线请求并不一定要执行所有环节。例如，简单查询可以跳过 Query 改写；如果基础检索的排序质量已经足够好，也可以不使用 Rerank。

2.3 为什么要区分离线处理和在线问答？

离线处理负责将原始资料转换为可以检索的知识。

例如：

• 读取员工手册。
• 提取章节、段落和表格。
• 生成 Chunk。
• 添加文档版本与权限元数据。
• 生成 Embedding。
• 建立向量索引和关键词索引。

在线问答负责使用这些知识回答员工问题。

例如：

• 确认当前员工身份和权限。
• 理解员工的问题。
• 从知识库中召回候选 Chunk。
• 对候选内容排序。
• 将相关制度交给 LLM。
• 输出答案及其出处。

这种分工可以避免每次用户提问时都重新解析所有文档和生成全部向量，从而降低在线处理成本。

制度发生变化时，系统通常只需要处理受影响的文档或片段，并更新相应索引。具体如何增量更新，取决于系统是否能够可靠识别文档版本和内容变更。

三、详细示例：将员工手册切分为 Chunk

3.1 原始员工制度

假设企业当前有效的员工手册中存在以下示例条款：

第三章：休假管理

3.1 年假额度
符合公司规定的正式员工，每年享有 10 天带薪年假。

3.2 年假申请
员工申请年假，应至少提前 3 个工作日提交申请，
经直属主管审批后方可休假。

3.3 年假结转
当年度未使用的年假，按照公司另行发布的结转规则处理。

第四章：费用报销

4.1 差旅住宿
员工因公出差产生的住宿费用，应符合对应职级的报销标准。

4.2 报销材料
员工提交住宿费报销时，应提供合规发票、费用明细
及符合公司要求的出差审批材料。

这里的具体条款和数字仅用于演示知识库设计，不代表任何真实企业的制度。

原始文档通常按照章节、条款、段落和表格组织。但检索系统需要将它们转换为适合查询的片段。

3.2 设计 Chunk

可以按照制度主题和条款边界，将上述内容切分成以下 Chunk：

Chunk 001：年假额度

符合公司规定的正式员工，每年享有 10 天带薪年假。

Chunk 002：年假申请流程

员工申请年假，应至少提前 3 个工作日提交申请，
经直属主管审批后方可休假。

Chunk 003：年假结转规则

当年度未使用的年假，按照公司另行发布的结转规则处理。

Chunk 004：差旅住宿报销标准

员工因公出差产生的住宿费用，应符合对应职级的报销标准。

Chunk 005：住宿费报销材料

员工提交住宿费报销时，应提供合规发票、费用明细
及符合公司要求的出差审批材料。

这些 Chunk 并非随机切分，而是尽量让每个片段表达一个相对完整的制度主题。

当用户询问年假额度时，Chunk 001 是主要候选；当用户询问申请时间和审批要求时，Chunk 002 更有价值。

3.3 为什么不把整个章节放进一个 Chunk？

假设把第三章全部内容合并为一个 Chunk：

Chunk A：
年假额度、年假申请流程、年假结转规则……

这种方式也能工作，但存在一些潜在问题：

• 一个 Chunk 中可能包含多个不同问题的答案。
• 检索结果可能包含较多无关文本。
• 上下文变长，增加生成成本。
• 相关性排序可能更难判断具体条款是否直接回答了问题。

不过，切分也不能过度细化。

例如，将年假申请条款拆成两个 Chunk：

Chunk A：员工申请年假，应至少提前 3 个工作日提交申请。

Chunk B：经直属主管审批后方可休假。

如果用户问“年假需要经过审批吗”，第二个片段可以独立回答。但如果问题是“年假申请需要提前多久，以及由谁审批”，系统就需要同时召回两个片段。

因此，对于实际制度文档，可以考虑按条款切分，并在条款包含多个紧密相关的条件时，将它们保留在同一个 Chunk 中。

判断切分是否合理的标准，不是 Chunk 越短越好，而是它能否完整支持目标问题的回答。

3.4 为 Chunk 添加元数据

仅保存 Chunk 的正文还不够。企业知识库还需要保存文档来源、版本、适用范围和权限等信息。

例如：

{
  "chunk_id": "EMP-LEAVE-002",
  "document_id": "EMP-HANDBOOK-2026",
  "document_title": "员工手册",
  "section": "第三章 休假管理 / 3.2 年假申请",
  "content": "员工申请年假，应至少提前 3 个工作日提交申请，经直属主管审批后方可休假。",
  "document_version": "2026.1",
  "effective_from": "2026-01-01",
  "department": "all",
  "access_scope": "all_employees",
  "chunk_index": 2
}

以上 JSON 是示例结构。实际字段应根据企业的数据治理要求设计。

这些字段可以支持：

• 按文档版本筛选当前有效制度。
• 根据适用对象确定哪些条款可以使用。
• 将答案关联回具体章节。
• 在制度更新时定位需要替换的 Chunk。
• 对访问受限的资料执行权限过滤。

尤其需要注意：权限过滤不能只依赖大模型的提示词。 应在检索系统或其可信的服务端逻辑中执行访问控制，避免未授权内容进入模型上下文。

四、从用户提问到检索结果

4.1 用户提出问题

假设员工在 AI 助手中输入：

正式员工休年假需要提前多久申请？需要谁审批？

系统首先需要理解问题中包含哪些信息：

• 主题：年假申请。
• 目标信息：提前申请时间、审批人。
• 适用对象：正式员工。
• 可能涉及的制度章节：休假管理。

这里不一定需要调用 LLM 改写查询。对于表述清晰的简单问题，可以直接使用原始查询进行检索。

只有在问题过于口语化、存在指代不清或需要拆分多个子问题时，Query 改写或查询拆分才可能带来收益。

4.2 什么是召回？

召回（Retrieval）是从知识库中找出可能与用户问题有关的资料。

假设企业知识库有 10 万个 Chunk。系统不可能每次都把全部 10 万个片段交给大模型，因此需要先用检索算法缩小候选范围。

例如：

flowchart TD
    A[整个知识库：100,000 个 Chunk] --> B[初步召回：100 个候选 Chunk]
    B --> C[Rerank 重排序：选出最相关的 5 个 Chunk]
    C --> D[将相关内容交给 LLM]

以上数量只是示例，不是固定配置。

召回阶段通常更关注 Recall，也就是尽可能找回所有真正相关的资料。

假设测试问题有 10 个真正相关的 Chunk：

• 找回 9 个，Recall 为 90%。
• 找回 5 个，Recall 为 50%。
• 找回 2 个，Recall 为 20%。

召回率越高，漏掉有用资料的风险通常越低。

但这不意味着应该无限增加召回数量。候选内容越多，重复和无关信息也可能越多，增加后续排序与生成的成本。

4.3 BM25：根据关键词匹配进行检索

BM25 是一种经典的信息检索排序算法，用于评估查询词与文档之间的匹配程度。

例如，员工询问：

年假申请要提前几个工作日？

知识库中的原文是：

员工申请年假，应至少提前 3 个工作日提交申请。

BM25 可以利用“年假”“申请”“提前”“工作日”等词语的匹配情况，给这个 Chunk 较高的相关性分数。

BM25 通常会综合考虑：

• 查询词是否出现在文档中。
• 某个词在文档中出现的频率。
• 该词在整个文档集合中的区分能力。
• 文档长度等因素。

它的优势是适合精确词项匹配。例如：

• 报销制度编号。
• 考勤异常代码。
• 特定制度名称。
• 明确的金额、型号或业务术语。

但关键词检索也有局限。

例如：

我想请几天假，最晚要什么时候报备？

如果原文使用的是“年假申请”，而不是“请假报备”，纯关键词检索可能无法稳定找到最相关的条款。

这就需要考虑向量检索。

4.4 向量检索：根据语义相似度进行检索

Embedding 模型可以将文本编码为向量表示。

例如：

用户问题：
我想请几天假，最晚要什么时候报备？

知识库 Chunk：
员工申请年假，应至少提前 3 个工作日提交申请。

虽然两者使用的词语不完全相同，但它们表达的意思接近。

向量检索通过比较查询向量和 Chunk 向量之间的距离或相似度，找出语义上接近的候选片段。

通常可以使用余弦相似度或其他向量距离指标，但具体方法取决于 Embedding 模型和向量数据库的配置。

向量检索的优势是能够处理同义表达、自然语言问题和不同措辞之间的语义联系。

但必须区分：

• 语义相似，不代表事实相同。
• 语义相似，不代表制度适用范围相同。
• 语义相似，不代表某条制度当前仍然有效。

例如，旧版员工手册中的年假规则可能与新版非常相似，但两者的有效期限不同。仅凭向量相似度，无法判断应该采用哪一个版本。

因此，企业知识库需要将语义检索与版本、权限和业务规则结合起来。

4.5 为什么使用 BM25 + 向量检索混合召回？

两种检索方式擅长处理不同类型的查询。

混合召回的基本思路是：

flowchart TD
    A[用户问题] --> B[BM25 检索]
    A --> C[向量检索]
    B --> D[关键词候选]
    C --> E[语义候选]
    D --> F[合并与去重]
    E --> F
    F --> G[候选 Chunk 集合]

例如，BM25 找到了年假申请条款，而向量检索找到了使用“请假报备”措辞的相关内容。合并两路结果，可以提高找到有效答案的机会。

合并结果时，可以采用 Reciprocal Rank Fusion（RRF，倒数排名融合）等方法，根据候选在不同检索结果中的排名进行融合。

一个简化的 RRF 形式为：

其中：

• $d$ 表示候选 Chunk。
• $R$ 表示不同检索器的结果集合。
• $\operatorname{rank}_r(d)$ 表示 Chunk 在某个检索结果中的排名。
• $k$ 是用于平滑排名影响的常数。

RRF 不要求 BM25 分数和向量相似度必须处于相同数值范围，因此是一种常见的结果融合方式。

但混合检索不是必然优于单一检索。是否需要两路召回，应通过实际测试集比较 Recall@K、Precision@K、延迟和成本后决定。

4.6 Rerank：对候选 Chunk 进行精细排序

混合召回解决的是“哪些资料值得进一步考虑”，而 Rerank 解决的是“哪些资料最值得优先使用”。

假设初步召回了以下候选：

对于问题：

正式员工休年假需要提前多久申请？需要谁审批？

Chunk B 是最直接的答案。

其他 Chunk 可能包含“年假”“员工”“申请”等相关词语，但并不能完整回答问题。

Rerank 模型可以将用户问题与每个候选 Chunk 结合起来，对它们的相关性进行更精细的评估。

常见的实现方式是 Cross-Encoder 类模型：模型同时读取查询和候选文本，再输出相关性分数。

需要注意，Rerank 不一定是通用大语言模型。实践中常用专门训练的排序模型，因为它们更适合高效地比较查询与候选文本之间的相关性。

经过排序后，系统可以选取前几个 Chunk，交给后续生成模型。

Rerank 的优势是改善候选排序，但也会引入额外的计算成本和延迟。因此，是否启用、处理多少候选，以及选用哪种模型，都应该通过实际评测确定。

五、从检索结果生成答案

5.1 组装上下文

经过召回与排序后，系统获得与问题最相关的制度片段。

例如：

[来源：员工手册 / 第三章 休假管理 / 3.2 年假申请]

员工申请年假，应至少提前 3 个工作日提交申请，
经直属主管审批后方可休假。

接下来，系统将用户问题和检索到的资料一起提供给 LLM。

可以采用类似下面的提示词：

你是企业员工制度问答助手。

请根据提供的制度资料回答员工问题。

要求：
1. 以提供的制度资料为主要依据。
2. 不要编造资料中没有的制度、数字或审批条件。
3. 如果资料不足以回答问题，请明确说明。
4. 如果存在适用范围或版本差异，请指出差异。
5. 在答案中注明制度来源。

用户问题：
正式员工休年假需要提前多久申请？需要谁审批？

制度资料：
员工申请年假，应至少提前 3 个工作日提交申请，
经直属主管审批后方可休假。

5.2 生成最终答案

模型可以生成：

正式员工申请年假，应至少提前 3 个工作日提交申请，并经直属主管审批后方可休假。

来源：员工手册，第三章“休假管理”，第 3.2 条“年假申请”。

这比直接让模型根据通用知识回答更容易验证，因为答案中的具体规则可以追溯到原始制度。

但提示词本身并不能保证模型完全忠实于资料。生产环境还应检查引用是否真实存在、引用内容是否支持对应结论，以及模型是否遗漏重要的适用条件。

5.3 如果检索不到答案怎么办？

假设员工询问：

年假最多可以连续休多少天？

但当前知识库只包含年假额度和申请流程，没有连续休假天数的规定。

此时不应让模型根据常识自行补出一个数字。

更合理的回答是：

当前检索到的员工制度资料没有明确说明年假最多可以连续休多少天。建议查阅完整休假制度或向人力资源部门确认。

在企业制度问答中，能够识别知识缺口和明确表达不确定性，同样是系统质量的重要组成部分。

六、如何处理报销和考勤问题？

同一套 RAG 架构可以服务于不同的员工制度主题，但切分策略和检索条件需要根据具体业务调整。

6.1 报销制度示例

用户问题：

出差住酒店报销需要哪些材料？

知识库中有两个相关 Chunk：

Chunk 004：
员工因公出差产生的住宿费用，应符合对应职级的报销标准。

Chunk 005：
员工提交住宿费报销时，应提供合规发票、费用明细
及符合公司要求的出差审批材料。

这里，Chunk 005 可以直接回答材料要求，Chunk 004 则提供报销适用条件。

如果员工进一步询问：

我是 P5 级员工，住宿费每天最多能报销多少？

系统需要检索对应职级的具体标准。如果知识库没有该标准，就不能只根据“对应职级的报销标准”推导出具体金额。

这说明企业 RAG 不只是要找到主题相关的文本，还要判断检索结果是否包含回答所需的全部信息。

6.2 考勤制度示例

用户问题：

忘记打卡怎么办？

知识库可能包含：

Chunk 006：
员工上下班应按照公司要求完成考勤打卡。

Chunk 007：
员工因特殊情况未能正常打卡时，应按照考勤异常处理流程
提交说明及相关证明，并由对应负责人审批。

如果系统只召回 Chunk 006，虽然内容与考勤有关，但没有完整回答忘记打卡后的处理方法。

因此，在设计 Chunk 时，应尽量将操作流程、适用条件和审批要求保留完整；在评估检索质量时，也要测试系统是否能够找齐回答问题所需的多个片段。

七、企业 RAG 的关键工程问题

7.1 制度版本与增量更新

员工制度可能每年更新，部分制度也可能临时调整。

如果新版制度已经生效，但向量数据库中仍然存在旧版 Chunk，系统就可能召回过期规定。

因此，建议为每份文档保存：

• 文档 ID 和版本号。
• 生效日期和失效日期。
• 文档状态。
• 适用对象。
• 来源文件及章节定位。

制度更新时，应识别变更内容，更新对应的 Chunk 和检索索引，并确保失效制度不再作为当前有效答案的依据。

对于重要制度，建议保留变更记录和索引更新时间，以便排查为什么系统在某个时间点返回了特定规则。

7.2 权限与知识隔离

企业知识库不一定对所有员工开放。

例如：

• 普通员工可以查询通用年假和考勤制度。
• 部门负责人可能可以访问部分部门级流程。
• 人力资源人员可能可以访问受限的人事政策。

系统应在检索阶段，根据已经验证的用户身份和授权范围限制候选文档。

不能先将所有敏感资料检索出来，再仅仅依靠提示词要求模型不要泄露。

权限过滤还应覆盖引用来源、缓存、日志和后续工具调用，避免未授权信息通过其他路径泄露。

7.3 结构化数据不一定需要向量检索

不是所有员工问题都适合通过 RAG 解决。

例如：

• “差旅住宿费的报销标准是什么？”适合检索制度文档。
• “我的报销单现在审批到哪一步了？”可能需要调用报销系统 API。
• “我本年度还剩几天年假？”可能需要查询 HR 系统中的个人余额。

可以根据问题类型路由到不同的数据源：

需要注意，个人余额、审批状态等动态业务数据不应仅依靠静态员工手册回答。它们需要来自有权限控制的实时业务系统。

八、如何评估 RAG 是否真正有效？

不能因为系统能够返回一段看似合理的答案，就认为 RAG 已经搭建成功。

建议将评估拆分为检索质量、答案质量、性能与成本几个维度。

8.1 检索指标

Recall@K（前 K 个结果的召回率）

衡量前 K 个检索结果找回了多少真正相关的资料。

假设某个测试问题有 5 个相关 Chunk，系统前 10 个结果找到了其中 4 个：

Recall@K 越高，通常表示系统漏掉的相关资料越少。

Precision@K（前 K 个结果的精确率）

衡量前 K 个结果中，有多少是真正相关的资料。

假设前 10 个结果中有 6 个相关：

Recall 和 Precision 需要结合观察：只返回极少数结果可能很精确，却容易漏掉答案；返回大量结果可能找得更全，却带入许多无关资料。

MRR（Mean Reciprocal Rank）

衡量第一个相关结果出现得有多靠前。相关结果越早出现，MRR 通常越高。

nDCG（Normalized Discounted Cumulative Gain）

衡量排序结果的整体质量，并考虑不同排名位置的价值。越相关的结果排得越靠前，通常越有利。

8.2 答案质量指标

检索正确不代表生成一定正确。

建议测试：

• 答案正确率： 是否正确回答问题。
• 忠实度（Faithfulness）： 答案中的事实是否得到检索资料支持。
• 引用准确率： 引用是否指向真实存在、且能够支持结论的内容。
• 拒答合理性： 知识库缺少答案时，是否能够明确说明信息不足。
• 条件完整性： 是否遗漏审批人、适用对象、生效时间等关键条件。

可以构建一组标准测试问题：

这些测试问题可以持续用于比较不同 Chunk 策略、检索参数和模型版本。

8.3 延迟和成本

RAG 会增加检索、排序和上下文处理的开销。

例如，在线请求可能经过：

flowchart TD
    A[问题处理] --> B[BM25 与向量检索（并行）]
    B --> C[合并去重]
    C --> D[Rerank]
    D --> E[组装上下文]
    E --> F[LLM 生成]

其中，BM25 和向量检索可以并行执行；Query 改写和 Rerank 则不一定适合每个请求。

实际系统应监控：

• 首次输出延迟。
• 完整回答延迟。
• P50、P95 等延迟分位数。
• 输入与输出 Token 数量。
• 单次请求成本。
• 检索失败率和重试次数。

不能只追求 Recall@K，而忽略线上延迟。也不能只追求低成本，而让系统经常漏掉真正的制度条款。

8.4 通过对照实验选择检索方案

建议至少比较以下几种配置：

在同一组测试问题、同一套制度快照和一致的评估条件下，比较各方案的 Recall@K、Precision@K、答案正确率、引用准确率、P95 延迟与请求成本。

如果混合召回的提升很小，而延迟和成本明显增加，就应考虑保留更简单的方案。

如果 Rerank 明显改善了关键制度问题的排序与回答质量，再决定是否将其纳入生产链路。

九、总结：从最小可用 RAG 开始

为企业搭建员工制度知识库，不需要一开始就引入所有复杂组件。

一个合理的实施顺序是：

1. 整理知识源： 收集当前有效的员工手册、报销制度和考勤规范。
2. 设计 Chunk： 优先按照章节、条款和业务语义切分，避免破坏关键条件。
3. 保存元数据： 记录来源、版本、生效时间、适用范围和访问权限。
4. 建立检索索引： 根据查询特点选择关键词检索、向量检索或混合召回。
5. 接入 LLM： 将相关制度片段交给模型生成答案，并要求提供来源。
6. 建立测试集： 用真实员工问题验证召回质量、答案正确性和引用准确率。
7. 持续优化： 根据漏检、误检、过期知识、延迟和成本数据调整系统。

整个过程可以概括为：

文档解析、Chunk 切分、元数据管理、检索召回、按需 Rerank、LLM 生成、引用验证与评测迭代。

其中最重要的不是把每个技术名词都堆进系统，而是理解每个组件解决什么问题，以及它是否真正改善了业务结果。

对于员工制度问答，Chunk 决定知识如何组织，检索决定能否找到正确资料，Rerank 决定候选资料的优先级，LLM 负责根据资料组织答案，而版本管理、权限控制和评测决定系统能否可靠地运行在企业环境中。

Consider a request such as:

Recommend camping gear in the low-to-mid price range and ship it to Sydney.

This is more than a product search. It is a decision workflow that must interpret the request, retrieve products, evaluate candidates, verify prices and inventory, confirm shipping eligibility, and present useful results.

A reliable cross-border AI shopping assistant needs to address four core questions:

1. How can keyword and vector search work together to find products that match the user’s actual intent?
2. When should the system call a tool, delegate to a sub-agent, or run tasks in parallel?
3. How can context be compressed without losing the constraints, evidence, and execution state needed to complete the task?
4. How should the system choose tools, execution strategies, and models based on task complexity, quality requirements, latency, and cost?

This article explores these questions from both a system-design and an implementation perspective.

1. Keyword Search and Vector Search

1.1 Key differences

Keyword search retrieves results based on matches between query terms and terms in product content. Common implementations include inverted indexes and BM25. It works well for brands, model numbers, SKUs, explicit specifications, and exact attributes.

Vector search encodes a query and product content as vectors using an embedding model, then retrieves candidates based on vector distance or similarity. It is useful for synonyms, conversational descriptions, implicit needs, and related concepts expressed with different wording.

1.2 Why can “rugged and drop-resistant” match a product that uses different wording?

Suppose a user searches for “rugged and drop-resistant,” but a product page does not use those exact words. Instead, it says:

• “Impact-resistant ABS housing”
• “Passed a 1.5-meter drop test”
• “Reinforced structural design”
• “Durability optimized for outdoor use”

Vector search may retrieve the product because embedding models learn statistical relationships between words, sentences, and contexts during training. Terms such as “drop-resistant,” “impact-resistant,” and “drop-tested” may be close in vector space.

However, three concepts must remain distinct:

1. Semantic similarity does not mean equivalent attributes. “Waterproof” and “suitable for rainy weather” may be semantically related, but they do not imply the same protection rating.
2. Semantic similarity does not establish a fact. “Military-grade design” does not necessarily mean the product has passed a particular standard or certification test.
3. Retrieval is not performance verification. Vector search can discover candidates; it cannot by itself prove that a product is drop-resistant.

In cross-border commerce, users may describe their needs in Chinese while product titles, specifications, and certifications are in English or another language. Multilingual embeddings can help with cross-language retrieval, but key specifications and supporting evidence still need to be verified.

1.3 Recommended approach: hybrid retrieval and reranking

Use hybrid retrieval rather than choosing between keyword and vector search.

A recommended workflow:

1. Parse the request: extract product categories, budget, destination, hard constraints, and soft preferences.
2. Retrieve candidates in parallel: use keyword and vector search independently.
3. Merge and deduplicate: reconcile product IDs, SKUs, and variants to avoid duplicate candidates.
4. Rerank for relevance: use BM25 scores, vector similarity, a Cross-Encoder, or another reranker to assess query-product relevance.
5. Filter hard constraints: verify price limits, inventory, and destination shipping eligibility.
6. Validate evidence: for attributes such as durability, water resistance, or load capacity, prefer specifications, test reports, or trustworthy product records.
7. Generate recommendations: present the rationale, price, evidence for performance claims, shipping information, and relevant caveats.

An important principle is: validate or filter hard constraints first; use soft preferences mainly for ranking.

For example, a product that cannot be shipped to Sydney should not make the final recommendation list, even if its semantic similarity score is high.

2. Sub-Agent Delegation and Parallel Execution

2.1 Distinguishing tool calls, sub-agents, and parallel execution

• Tool calling performs a specific operation, such as querying a product API, checking inventory, or calculating a total.
• A sub-agent receives a relatively self-contained subgoal and works with its own context, tool permissions, or execution strategy.
• Parallel execution runs multiple tasks at the same time. It does not require a multi-agent architecture; one agent can issue several tool calls in parallel.

Not every tool call should be wrapped in an agent. Querying the price of one product usually requires only a product API call. Searching for several products does not mean that each product needs its own agent.

2.2 When is it worth delegating to a sub-agent?

Evaluate four factors:

1. Decomposability: Can the task be split into relatively independent subtasks, such as researching tents, sleep systems, and lighting?
2. Dependencies: Can a subtask make progress without waiting for the results of another?
3. Specialization benefit: Do different subtasks need different tools, retrieval strategies, prompts, or validation logic?
4. Cost-benefit: Do the latency or quality gains from parallel work outweigh startup, coordination, aggregation, and duplicated-reasoning costs?

For a camping-gear recommendation:

Delegation should depend on task complexity, dependencies, and execution cost—not on the task’s name.

2.3 Why are two agents running in parallel not necessarily faster?

Parallelism reduces waiting only for the portion that can run concurrently. It cannot eliminate dependencies or coordination overhead.

Suppose:

• Agent A searches for tents and takes 4 seconds.
• Agent B searches for sleeping bags and takes 5 seconds.
• The main agent takes 2 seconds to aggregate, deduplicate, and verify results.

If the tasks run sequentially:

If the first two tasks run in parallel:

Under ideal conditions, parallel execution reduces the total time from 11 to 7 seconds, or about 36%.

But if parallel work adds 1.5 seconds of startup and coordination overhead plus 1 second to resolve conflicting data, then:

The benefit is much smaller. These numbers illustrate the calculation; they are not production benchmarks.

Common parallel-execution bottlenecks include:

• Shared-resource contention: multiple agents call the same rate-limited API, causing throttling or queues.
• Dependency blocking: shipping verification requires an SKU that has not yet been selected.
• Duplicate work: agents find the same product and repeat tool calls.
• Coordination cost: the main agent must reconcile prices, currencies, shipping terms, and product identifiers.
• Tail latency: the final response must wait for the slowest required task.
• Conflicting results: agents may disagree, requiring additional verification.

More parallelism does not necessarily mean greater throughput. Shared resources, rate limits, and coordination overhead can offset the gains.

2.4 Use a task dependency graph to plan execution

First parse the request, then plan work according to its dependencies. For example:

flowchart TD
    A[Parse user request] --> B[Identify budget and shipping constraints]
    B --> C[Retrieve candidate products]
    C --> D[Group candidates by category]
    D --> E[Research tents]
    D --> F[Research sleep systems]
    D --> G[Research lighting and cookware]
    E --> H[Merge candidates]
    F --> H
    G --> H
    H --> I[Verify prices and product performance]
    I --> J[Check Sydney shipping and total cost]
    J --> K[Optimize for budget and produce recommendations]

Researching independent product categories is suitable for parallel execution. Budget optimization and final shipping verification depend on aggregated results, so they should not be performed prematurely.

3. Context Compression and Preserving Task Information

3.1 The goal is to reduce cost, not merely shorten text

Context compression should reduce token usage while preserving task completion, factual accuracy, and constraint adherence as much as possible.

A shopping assistant should preserve:

If a user gives an exact budget, preserve the amount and currency rather than summarizing it as “limited budget.” If the user only says “low-to-mid budget,” do not silently turn that into an unconfirmed price cap. The system can state a transparent default assumption or ask the user when necessary.

Likewise, compression must not turn “the seller claims impact resistance” into “passed an impact-resistance test,” or remove the currency from an Australian-dollar price.

3.2 Evaluate compression quality through task performance

A summary that looks semantically similar to the original conversation may still have dropped information needed for execution. A better evaluation is to give the compressed context to the system and test whether it can complete the original task correctly.

A basic metric is task completion rate:

Evaluation should also track hard-constraint violation rate, factual error rate, tool-call accuracy, and final recommendation quality.

Useful test scenarios include:

• After the user specifies a maximum budget, does the system still filter out products that exceed it?
• After the user specifies Sydney as the destination, does the system still verify shipping there?
• When the user requests drop resistance, does the system distinguish seller claims from test evidence?
• After the user rejects a product, does the system avoid recommending it again?
• When a product’s price changes, does the system query it again rather than rely on stale information?

Hard-constraint violations should be tracked independently; correct results elsewhere must not cancel them out.

For example:

If a compression strategy reduces token cost by 40% but noticeably increases shipping errors, it should not be considered successful. The 40% figure is illustrative, not a universal threshold.

3.3 Use structured state and on-demand summaries

Avoid compressing all task state into one paragraph of natural language. A more robust approach is to preserve critical state in structured form and summarize repetitive conversation or low-value logs on demand.

For example:

{
  "intent": "camping_gear_recommendation",
  "destination": {
    "city": "Sydney",
    "country": "Australia"
  },
  "budget": {
    "level": "low_to_mid",
    "currency": "AUD",
    "exact_cap": null
  },
  "preferences": [
    "durable",
    "value_for_money"
  ],
  "constraints": {
    "shipping_to_destination_required": true
  },
  "evidence": {
    "product_specs": [],
    "shipping_checks": [],
    "price_checks": []
  },
  "pending_tasks": [
    "retrieve_products",
    "verify_shipping",
    "compare_total_cost"
  ]
}

This is an example only; define the actual fields to fit the business requirements.

Structured state helps to:

• Reduce the risk of losing critical constraints in a summary.
• Separate user preferences, product facts, and evidence sources.
• Track task progress and outstanding work.
• Identify results that have expired and need to be queried again.
• Give the main agent and sub-agents a shared state definition.

Prices, inventory, and shipping eligibility are dynamic. Even correctly compressed context can contain outdated query results. Information completeness and data freshness must therefore be managed separately.

3.4 Establish layered evaluation

Evaluate a compression strategy at three levels:

1. Constraint-preservation tests: compare hard constraints, soft preferences, currency, destination, rejected items, and unfinished tasks before and after compression. Missing a critical field is a failure.
2. Execution replay: with the same product snapshot, tool responses, and task conditions, compare tool choices, filtering, and final recommendations before and after compression.
3. Online quality monitoring: track budget violations, shipping errors, factual errors, task completion, latency, and token cost; analyze results by task type.

Adaptive compression is also useful: compress repetitive conversation and low-value logs first, preserve hard constraints, key evidence, and execution state, and recover relevant details from the original record when missing information is detected.

4. Automatic Routing: Tool Calls, Sub-Agents, and Model Selection

4.1 Define three types of action

Action A: Call a tool directly

Use this when the input is clear, the operation is deterministic, and the output is structured—for example, looking up an SKU price, checking inventory, or calculating a total.

Action B: Delegate to a sub-agent

Use this for multi-step research that can run independently or has a clear specialist boundary—for example, comparing the construction, durability, and value of several tents.

Action C: Switch models

Use this when the current model cannot meet quality requirements for reasoning, tool planning, multilingual understanding, long-context processing, or structured output. Examples include complex budget optimization, conflicting evidence, and decisions across product bundles.

These actions are not mutually exclusive. A complex task can use a stronger model to plan, delegate independent research to sub-agents, and then call tools to verify prices and inventory.

4.2 Choose a strategy based on cost, latency, and risk

A router should consider:

Routing can be modeled as a quality-constrained cost optimization problem:

where:

• $a$ is a candidate execution strategy;
• $C(a)$ is its expected cost;
• $L(a)$ is its expected latency;
• $R(a)$ is its expected error risk;
• $\lambda$ and $\mu$ are business-defined weights.

The system should also enforce a minimum quality threshold; it must not choose an obviously unreliable strategy just to reduce cost. Weights and thresholds should be calibrated through offline evaluation and online experiments, not fixed by intuition alone.

4.3 Example routing flow

flowchart TD
    A[Receive user task] --> B[Extract constraints and task state]
    B --> C{Is required information complete?}
    C -- No --> D[Ask for clarification or use an explicit default]
    D --> B
    C -- Yes --> E{Is there a deterministic tool operation?}
    E -- Yes --> F[Call the tool directly]
    E -- No --> G{Are there independent complex subtasks?}
    G -- Yes --> H[Build a dependency graph and estimate parallel benefit]
    H --> I{Does parallel benefit exceed its overhead?}
    I -- Yes --> J[Delegate to sub-agents]
    I -- No --> K[Use one agent sequentially]
    G -- No --> K
    F --> L{Can the current model make the remaining decisions reliably?}
    J --> L
    K --> L
    L -- No --> M[Escalate to a stronger or specialized model]
    L -- Yes --> N[Continue execution]
    M --> N
    N --> O[Validate results and hard constraints]
    O --> P{Did validation pass?}
    P -- No --> Q[Retry selectively or recover missing information]
    Q --> O
    P -- Yes --> R[Present the final recommendation]

The guiding principle is: perform deterministic, lower-cost operations before spending resources on more expensive reasoning.

For example, first filter a structured product database for reasonable prices and shipping eligibility; then ask a model to analyze durability, use cases, and bundle value. This division is generally easier to verify and control than relying on a large language model to infer products, prices, and shipping eligibility from scratch.

4.4 When should the system switch models?

Model escalation should be triggered by clear failure signals or capability requirements—not simply because a task is long or appears complex.

Possible triggers include:

• Repeated failure to produce output that matches a schema.
• Repeatedly incorrect tool-call parameters.
• Inability to reliably resolve complex constraint conflicts between candidates.
• A requirement for more effective context than the current model can reliably handle.
• Evaluation results showing that the current model performs significantly worse on similar tasks than a stronger model.

Distinguish model limitations from infrastructure failures. If a product API times out, switching to a more capable language model will not usually fix the network or service. Consider retries, another data source, or a defined fallback instead.

Choose models based on evaluated task performance, not solely on a model’s own assessment of its abilities.

4.5 Improve routing continuously with execution logs

Start with rule-based routing:

• Structured, deterministic tasks: call a tool directly.
• Independent, complex subtasks: evaluate whether agent delegation is worthwhile.
• High uncertainty, complex reasoning, or repeated failures: consider a stronger model.
• Missing critical inputs: ask for clarification or use a documented default.

Then collect execution logs, including task type, routing action, actual latency, token and tool costs, success rate, retries, and hard-constraint violations.

Offline replay, A/B tests, or a calibrated routing model can help learn effective strategies for different task types. Continuously calibrate routing against real outcomes; do not rely only on static rules or a model’s self-assessment.

5. Recommended Production Architecture

Consider dividing the system into these modules:

1. Intent parsing and state management: extract budget, destination, preferences, hard constraints, and task state.
2. Task router: decide whether to call a tool directly, delegate to sub-agents, or switch models.
3. Product retrieval: retrieve candidates with keyword search, vector search, and reranking.
4. Product verification: validate specifications, inventory, price, shipping eligibility, and information freshness.
5. Result aggregation and constraint checks: reconcile currency, price basis, performance evidence, and shipping terms.
6. Recommendation generation and quality monitoring: explain recommendations with evidence and monitor failure modes.

flowchart TD
    A[Intent parsing and state management] --> B[Task router]
    B --> C[Product retrieval: keywords, vectors, and reranking]
    B --> D[Product verification: specifications, price, inventory, and shipping]
    C --> E[Result aggregation and constraint checks]
    D --> E
    E --> F[Recommendation generation]
    F --> G[Quality monitoring and feedback]
    G --> B

Responsibilities should be clear:

• The retrieval layer discovers candidate products.
• The orchestration layer assigns work and manages dependencies.
• Context management preserves the state needed to complete the task.
• The verification layer prevents unsupported or stale information from reaching the final answer.
• The monitoring layer evaluates quality, latency, and cost, and informs future routing improvements.

6. Implementation Roadmap and Conclusion

Proceed in stages:

Stage 1: Establish retrieval and constraint validation

Implement hybrid keyword and vector retrieval, candidate deduplication, relevance reranking, and validation of hard constraints such as price, inventory, and shipping eligibility. Prioritize retrieval quality and factual accuracy.

Stage 2: Establish structured task state and compression evaluation

Define what information must be preserved, distinguishing user preferences, product facts, evidence sources, and dynamic state. Use test sets and execution replay to evaluate performance after compression.

Stage 3: Introduce conditional agent parallelism

Split work using a task dependency graph and prioritize parallel execution for independent subtasks. Use measured latency, failure rates, and coordination costs to determine whether parallelism is beneficial.

Stage 4: Improve automatic routing and model selection

Continuously calibrate tool use, sub-agent delegation, and model escalation based on real task completion, latency, cost, and error risk.

The system should not optimize for the number of agents, model size, or compression ratio. A better goal is to choose the least costly and fastest verifiable path that still meets quality and safety requirements.

A reliable cross-border shopping assistant must do more than retrieve semantically relevant products. It should support important claims with evidence, use current price and shipping information, and ensure the entire workflow respects the user’s budget and destination constraints.

以用户提出的需求为例：

推荐露营装备，预算中低，寄到悉尼。

这不是单一的商品搜索任务，而是一个需要协同完成需求理解、商品检索、候选评估、价格与库存核验、配送资格确认及结果生成的决策流程。

要构建可靠的跨境电商 AI 购物助手，需要解决四个核心问题：

1. 如何结合关键词检索与向量检索，找到符合用户真实意图的商品？
2. 什么时候应调用工具，什么时候应派发子 Agent，以及并行执行是否值得？
3. 如何压缩上下文，同时保留完成任务所需的关键约束、证据和执行状态？
4. 如何根据任务复杂度、质量要求、延迟和成本，自动选择执行策略与模型？

本文从系统设计和工程落地的角度逐一说明。

一、关键词检索与向量检索

1.1 核心区别

关键词检索（Keyword Search） 根据查询词与商品文本中的词项匹配程度进行检索。常见实现包括倒排索引和 BM25。它适合品牌、型号、SKU、明确规格及精确属性等场景。

向量检索（Vector Search） 使用 Embedding 模型将查询与商品文本编码为向量，再依据向量之间的距离或相似度召回候选。它适合处理同义表达、口语描述、隐含需求以及不同措辞表达的相近概念。

1.2 为什么“抗造耐摔”可以匹配到没有这些原词的商品？

假设用户查询“抗造耐摔”，商品页面中没有这两个词，但包含以下描述：

• “采用抗冲击 ABS 外壳”
• “通过 1.5 米跌落测试”
• “强化结构设计”
• “针对户外使用进行了耐久性优化”

向量检索有机会将这些商品召回，因为 Embedding 模型在训练过程中学习了词语、句子和上下文之间的统计语义关系。“耐摔”“抗冲击”和“跌落测试”等表达可能在向量空间中具有较高相似度。

不过，必须区分三个概念：

1. 语义相似不等于属性等价。 “防水”与“适合雨天使用”可能语义接近，但不代表具备相同的防护等级。
2. 语义相似不等于事实成立。 “军规级设计”不一定代表商品通过了某项具体标准的认证或测试。
3. 检索召回不等于性能验证。 向量检索只能帮助发现候选商品，不能单独证明商品确实耐摔。

在跨境电商场景中，用户可能用中文描述需求，而商品标题、规格和认证信息采用英文或其他语言。多语言 Embedding 有助于跨语言召回，但仍需要对关键规格和证据进行核验。

1.3 推荐方案：混合检索与重排

建议采用 Hybrid Retrieval（混合检索），而不是在关键词检索与向量检索之间二选一。

推荐流程：

1. 解析用户需求：提取商品类别、预算、目的地、硬约束和软偏好。
2. 并行召回候选：通过关键词检索与向量检索分别获取候选商品。
3. 合并与去重：统一商品 ID、SKU 和变体信息，避免重复候选。
4. 相关性重排：使用 BM25 分数、向量相似度、Cross-Encoder 或其他重排模型评估查询与商品的相关性。
5. 硬约束过滤：核验价格上限、库存、目的地配送资格等不可违反的条件。
6. 证据验证：对耐用性、防水等级、承重等关键属性，优先使用规格表、测试报告或可信商品资料。
7. 生成推荐：展示推荐理由、价格、性能依据、配送信息和必要的限制说明。

一个重要原则是：硬约束应先过滤或验证，软偏好主要用于排序。

例如，无法配送到悉尼的商品，即使语义相似度很高，也不应进入最终推荐清单。

二、子 Agent 的派发与并行执行

2.1 区分工具调用、子 Agent 与并行执行

• 工具调用（Tool Calling）：执行一个明确的操作，例如查询商品 API、检查库存或计算总价。
• 子 Agent（Sub-Agent）：接收一个相对完整的子目标，并使用独立上下文、工具权限或执行策略完成任务。
• 并行执行（Parallel Execution）：同时启动多个任务。并行执行不要求一定采用多 Agent 架构；单个 Agent 也可以并行发起多个工具调用。

不应将每一次工具调用都包装成一个 Agent。查询单个商品价格通常只需要调用商品 API；查询多个商品，也不意味着每个商品都需要一个独立 Agent。

2.2 什么时候值得派发子 Agent？

可以从四个方面评估：

1. 可分解性：任务能否拆分为相对独立的子任务，例如帐篷、睡眠系统和照明装备的研究。
2. 依赖程度：子任务能否在不等待其他任务结果的情况下先行推进。
3. 专业化收益：不同子任务是否需要不同工具、检索策略、提示词或验证逻辑。
4. 成本收益：并行带来的延迟或质量收益，是否超过启动、协调、汇总和重复推理的开销。

以露营装备推荐为例：

派发决策应由任务复杂度、依赖关系和执行成本决定，而不是由任务名称决定。

2.3 为什么两个 Agent 并行不一定更快？

并行只能减少可并行部分的等待时间，无法消除依赖关系和协调成本。

假设：

• Agent A 检索帐篷，耗时 4 秒；
• Agent B 检索睡袋，耗时 5 秒；
• 主 Agent 汇总、去重和核验，耗时 2 秒。

如果串行执行：

如果前两个任务并行执行：

在理想条件下，并行可将总耗时从 11 秒降至 7 秒，约减少 36%。

但如果并行任务增加了 1.5 秒的启动与协调成本，以及 1 秒的数据冲突处理成本，则：

并行收益就会显著下降。以上数字仅用于说明计算方式，不代表实际系统基准。

常见的并行瓶颈包括：

• 共享资源竞争：多个 Agent 同时访问同一个受限 API，导致限流或排队。
• 依赖阻塞：配送核验需要 SKU，但 SKU 尚未确定。
• 重复工作：多个 Agent 检索到相同商品，重复执行工具调用。
• 协调成本：主 Agent 需要统一价格、币种、配送条件和商品标识。
• 尾部延迟：最终响应必须等待所有必要任务中的最慢者。
• 结果冲突：不同 Agent 可能给出不一致的结论，需要额外验证。

因此，并行度越高，并不意味着吞吐量必然越高。共享资源、限流和协调开销可能抵消并行收益。

2.4 使用任务依赖图设计执行计划

建议先解析需求，再根据依赖关系制定执行计划。例如：

flowchart TD
    A[解析用户需求] --> B[确定预算和配送约束]
    B --> C[检索候选商品]
    C --> D[按类别拆分候选]
    D --> E[帐篷研究]
    D --> F[睡眠装备研究]
    D --> G[照明与炊具研究]
    E --> H[合并候选]
    F --> H
    G --> H
    H --> I[统一价格与性能核验]
    I --> J[核验悉尼配送和总成本]
    J --> K[预算优化与最终推荐]

独立的商品类别研究适合并行；预算优化和最终配送核验则需要使用汇总后的信息，不能无条件提前完成。

三、上下文压缩与任务信息保留

3.1 压缩的目标是降低成本，而不是单纯缩短文本

上下文压缩应在减少 Token 使用量的同时，尽可能保持任务完成率、事实准确性和约束遵循能力。

对于购物助手，需要特别保留以下信息：

如果用户给出了明确预算上限，应保留具体金额和币种，而不是仅保留“预算有限”。如果用户只说“中低预算”，则不应擅自将其压缩成未经确认的精确价格上限；系统可以使用透明的默认假设，或在必要时询问用户。

同样，压缩不能把“商家宣称耐冲击”改写成“已通过耐冲击测试”，也不能把“价格为澳元”简化成不含币种的价格字段。

3.2 通过任务表现评估压缩质量

摘要与原始对话在语义上相似，并不代表保留了所有执行所需的信息。更有效的方式是将压缩后的上下文交给执行系统，测试其能否正确完成原任务。

一个基础指标是任务完成率：

实际评估还应单独跟踪硬约束违规率、事实错误率、工具调用正确率和最终推荐质量。

建议构造以下测试场景：

• 用户指定最高预算后，系统是否仍能过滤超预算商品？
• 用户指定悉尼为目的地后，系统是否仍会核验目的地配送？
• 用户要求耐摔时，系统是否区分商家宣传和测试证据？
• 用户已拒绝某商品后，系统是否避免再次推荐？
• 商品价格发生变化后，系统是否重新查询，而非继续使用过期数据？

硬约束违规应独立统计，不应被其他正确结果抵消。

例如，可以定义：

如果压缩后 Token 成本降低了 40%，但配送误判率明显上升，那么该压缩策略不能被视为成功。这里的 40% 仅为示例，不是通用阈值。

3.3 采用结构化状态与按需摘要

不建议将所有任务状态压缩为单段自然语言。更稳健的方式是将关键状态结构化保存，将重复对话和低价值日志按需摘要。

例如：

{
  "intent": "camping_gear_recommendation",
  "destination": {
    "city": "Sydney",
    "country": "Australia"
  },
  "budget": {
    "level": "low_to_mid",
    "currency": "AUD",
    "exact_cap": null
  },
  "preferences": [
    "durable",
    "value_for_money"
  ],
  "constraints": {
    "shipping_to_destination_required": true
  },
  "evidence": {
    "product_specs": [],
    "shipping_checks": [],
    "price_checks": []
  },
  "pending_tasks": [
    "retrieve_products",
    "verify_shipping",
    "compare_total_cost"
  ]
}

该结构仅为示例，实际字段应根据业务需求定义。

结构化状态有助于：

• 降低关键约束被摘要遗漏的风险；
• 分离用户偏好、商品事实与证据来源；
• 追踪任务进度和未完成事项；
• 判断哪些结果已过期，需要重新查询；
• 让主 Agent 与子 Agent 共享统一的状态定义。

需要注意，价格、库存和配送资格都属于动态信息。即使上下文压缩正确，历史查询结果也可能失效。因此，信息完整性与数据时效性必须分别管理。

3.4 建立分层评估机制

建议从三个层面评估压缩策略：

1. 约束保留测试：对比压缩前后的硬约束、软偏好、币种、目的地、拒绝项和未完成任务。关键字段缺失时，应判定失败。
2. 执行回放测试：在相同商品快照、工具响应和任务条件下，对比压缩前后的工具选择、过滤结果和最终推荐。
3. 线上质量监控：持续跟踪预算违规率、配送误判率、事实错误率、任务完成率、延迟和 Token 成本，并按任务类型分析。

还可以采用自适应压缩：优先压缩重复对话和低价值日志，保留硬约束、关键证据及执行状态；当检测到信息缺失时，从原始记录中恢复相关内容。

四、自动路由：工具调用、子 Agent 与模型选择

4.1 定义三类执行动作

动作 A：直接调用工具

适用于输入明确、操作确定、输出结构化的任务。例如查询 SKU 售价、检查库存、计算总价。

动作 B：派发子 Agent

适用于需要多步骤研究、可以独立执行或具有明确专业边界的子任务。例如比较多款帐篷的结构、耐用性和性价比。

动作 C：更换模型

适用于当前模型在推理、工具规划、多语言理解、长上下文处理或结构化输出方面无法满足质量要求的任务。例如复杂预算优化、冲突证据分析和跨商品组合决策。

三类动作并非互斥。复杂任务可以先由能力更强的模型制定计划，再派发子 Agent 并行研究，最后调用工具核验价格和库存。

4.2 根据成本、延迟和风险选择策略

路由器应考虑以下特征：

可将路由建模为受质量约束的成本优化问题：

其中：

• $a$ 表示候选执行策略；
• $C(a)$ 表示预计执行成本；
• $L(a)$ 表示预计延迟；
• $R(a)$ 表示预计错误风险；
• $\lambda$ 与 $\mu$ 是业务设定的权重。

实际系统还应设置最低质量门槛，不能为了降低成本而采用明显不可靠的策略。权重和阈值需要通过离线评估与线上实验校准，而不应凭经验直接固定。

4.3 参考路由流程

flowchart TD
    A[接收用户任务] --> B[提取约束与任务状态]
    B --> C{关键信息是否完整？}
    C -- 否 --> D[澄清或采用明确的默认值]
    D --> B
    C -- 是 --> E{是否存在确定性工具操作？}
    E -- 是 --> F[直接调用工具]
    E -- 否 --> G{是否存在独立的复杂子任务？}
    G -- 是 --> H[生成依赖图并评估并行收益]
    H --> I{并行收益是否大于开销？}
    I -- 是 --> J[派发子 Agent]
    I -- 否 --> K[单 Agent 顺序执行]
    G -- 否 --> K
    F --> L{当前模型能否可靠完成后续决策？}
    J --> L
    K --> L
    L -- 否 --> M[升级模型或采用专门模型]
    L -- 是 --> N[继续执行]
    M --> N
    N --> O[验证结果与硬约束]
    O --> P{是否通过验证？}
    P -- 否 --> Q[定向重试或恢复缺失信息]
    Q --> O
    P -- 是 --> R[输出最终推荐]

流程的基本原则是：优先执行确定性强、成本较低的操作，再投入更昂贵的推理资源。

例如，可以先从结构化商品数据库中筛选价格合理且符合配送条件的候选，再让模型分析耐用性、用途和组合价值。与完全依赖大模型从零推断商品、价格和配送资格相比，这种分工通常更容易验证，也更便于控制成本。

4.4 什么时候应该更换模型？

模型升级应由明确的失败信号或能力需求触发，而不是单纯因为任务较长或看起来复杂。

可能的触发条件包括：

• 多次无法生成符合 Schema 的输出；
• 工具调用参数反复错误；
• 当前模型无法稳定解决多个候选方案之间的复杂约束冲突；
• 任务需要的有效上下文超出当前模型的可靠处理能力；
• 经评估的同类任务数据显示，当前模型成功率明显低于更强的模型。

同时，要区分模型能力问题与基础设施问题。如果商品 API 超时，换成更强的语言模型通常不能解决网络或服务端故障。此时应优先考虑重试、切换数据源或采用降级策略。

模型选择应以经过评估的任务表现为依据，而不是仅依赖模型对自身能力的判断。

4.5 通过执行日志持续优化路由

初期可以采用规则路由：

• 结构化、确定性任务：直接调用工具；
• 独立且复杂的子任务：评估是否派发 Agent；
• 高不确定性、复杂推理或持续失败：考虑升级模型；
• 关键输入缺失：请求澄清或采用经过定义的默认值。

随后积累执行日志，记录任务类型、路由动作、实际延迟、Token 与工具成本、成功率、重试次数及硬约束违规情况。

可以通过离线回放、A/B 测试或经校准的路由模型，学习不同任务类型下的有效策略。路由策略必须使用实际执行结果持续校准，不能只依赖静态规则或模型自我评估。

五、推荐的生产架构

建议将系统划分为以下模块：

1. 意图解析与状态管理：提取预算、目的地、偏好、硬约束和任务状态。
2. 任务路由器：决定直接调用工具、派发子 Agent 或升级模型。
3. 商品检索层：结合关键词检索、向量检索与重排，召回候选商品。
4. 商品核验层：验证规格、库存、价格、配送资格和信息时效。
5. 结果合并与约束校验层：统一币种、价格口径、性能证据和配送条件。
6. 推荐生成与质量监控层：解释推荐理由，标明依据，并持续监控失败模式。

flowchart TD
    A[意图解析与状态管理] --> B[任务路由器]
    B --> C[商品检索：关键词、向量与重排]
    B --> D[商品核验：规格、价格、库存与配送]
    C --> E[结果合并与约束校验]
    D --> E
    E --> F[推荐生成]
    F --> G[质量监控与反馈]
    G --> B

该架构中，各模块职责应明确：

• 检索层负责发现候选商品；
• 编排层负责分配任务与控制依赖；
• 上下文管理负责保留必要状态；
• 核验层负责阻止未经证实或已过期的信息进入最终答案；
• 监控层负责评估质量、延迟和成本，并为后续路由优化提供数据。

六、实施建议与结论

建议按以下顺序推进：

第一阶段：建立检索与约束校验基础

实现关键词与向量混合检索、候选去重、相关性重排，以及价格、库存和配送资格等硬约束校验。优先保证商品召回质量和事实准确性。

第二阶段：建立结构化任务状态与压缩评估

明确哪些信息必须保留，区分用户偏好、商品事实、证据来源和动态状态。通过测试集与执行回放验证压缩后任务表现。

第三阶段：引入有条件的 Agent 并行

根据任务依赖图拆分工作，优先并行执行相互独立的子任务。通过实测延迟、失败率和协调成本判断并行是否真正有收益。

第四阶段：优化自动路由与模型选择

基于真实任务完成率、延迟、成本和错误风险，持续校准工具调用、子 Agent 派发与模型升级策略。

最终，系统设计不应以 Agent 数量、模型规模或压缩比例作为主要目标。更合理的目标是：在满足质量和安全要求的前提下，选择成本更低、执行更快且结果可验证的任务完成路径。

对于跨境电商 AI 购物助手，可靠的推荐不仅要找到语义相关的商品，还要证明关键属性有据可依、价格与配送信息有效，并确保整个执行流程遵守用户的预算和目的地约束。