知识库挂载写作：让 AI 严格引用单位资料，政策口径一个都不许错

一、问题的本质：为什么“挂载”比“微调”更适合政策写作

单位写作场景有个鲜明特征：知识是封闭且高频变动的。某份管理办法今年三月修订，某条补贴标准七月调整，某个口径在内部会议上被明确。这些变化不会出现在公开语料里，模型预训练时根本没见过。于是出现两种技术路线：一是继续预训练或指令微调，把知识“灌”进参数；二是检索增强生成（RAG），把知识“挂”在推理时。

微调路线的核心问题是知识更新成本高、溯源困难。每次文件修订都要重新构造训练集、重新训练、重新评测，而且模型学到的知识以参数形式弥散分布，你无法指出某句话来自哪份文件的第几页。RAG 路线则把知识外置，更新只需替换索引，生成时可以带上出处。Lewis 等人 2020 年提出的 RAG 框架（arXiv:2005.11401）正是这一思路的奠基性工作，本文评述：该工作的价值不在于某个具体模型结构，而在于确立了“参数记忆 + 非参数记忆”的双通道范式，为后续所有企业级知识问答提供了架构原型。

但 RAG 不是银弹。Gao 等人 2023 年的综述（arXiv:2312.10997）把 RAG 的发展划分为朴素 RAG、进阶 RAG、模块化 RAG 三个阶段，并指出朴素 RAG 在“检索质量差、生成不受约束”时反而会放大幻觉。笔者认为，这正是单位写作场景的痛点所在：检索到半句被截断的条款，模型会“合理补全”，补出来的内容看似通顺，实则与原文口径不符。所以本文主张的不是“上 RAG”，而是“上可追溯的 RAG”。

1.1 政策写作的三类硬约束

把单位写作需求拆开看，至少有三类硬约束，它们决定了技术选型：

• 口径约束：数字、期限、适用范围必须与现行文件逐字一致，不能同义替换。比如“30 个工作日”不能写成“一个月”。
• 时效约束：只能引用现行有效版本，废止文件不能作为依据。这要求检索层具备版本过滤能力。
• 权限约束：不同岗位可引用的文件范围不同，涉密或内部文件不能出现在无权限用户的输出里。

这三类约束都不是“模型能力”问题，而是“系统设计”问题。把它们翻译成工程语言就是：检索要带元数据过滤，生成要带引用约束，输出要带权限校验。这条思路与信息检索领域经典的“过滤式检索”（Filtered Retrieval）一脉相承，只是在 LLM 时代被重新赋予了紧迫性。

1.2 一个反直觉的观察

很多团队的第一反应是“换个更强的模型”。但笔者在实际项目中观察到一个反直觉现象：在检索质量不达标时，模型越强，幻觉越“像真的”。弱模型编造时往往语句生硬、逻辑跳跃，人一眼能看出问题；强模型编造时行文流畅、格式规范，反而更容易被直接采用。这意味着，能力提升如果没有配套的可追溯机制，风险是上升而非下降的。

本文评述：这个观察与 Ji 等人 2023 年发表于 ACM Computing Surveys 的幻觉综述（DOI:10.1145/3571730）中的判断一致——幻觉的危害程度与输出的“可信外观”正相关。因此，可追溯性不是锦上添花的功能，而是风险控制的基础设施。

二、可追溯性主线：四个环节与一条引用链

本文的分析主线是可追溯性。所谓可追溯，指的是从最终输出的任意一句话，能够沿着确定的路径回溯到原始文件的确定位置，并且这条路径在系统层面可验证、可审计、可复现。这条主线贯穿四个环节，构成一条完整的“引用链”：

环节	核心问题	可追溯性要求
来源可定位	这句话来自哪份文件	文档级 ID + 版本号 + 生效日期
片段可对齐	来自文件的哪一段	块级 ID + 字符偏移 + 页码
生成可约束	模型是否只能引用这些片段	引用标记 + 解码约束
输出可审计	事后能否复现引用路径	日志留存 + 引用快照

这条链的每一环都可能断裂。分块时把一句话切成两半，片段对齐就断了；检索时没有版本过滤，来源定位就错了；生成时没有引用约束，模型可以自由发挥；日志只存最终文本不存引用，审计就无从谈起。笔者认为，评估一个知识库写作系统，最直接的方法就是随机抽十句输出，看每一句能否在 30 秒内定位到原文。做不到，说明引用链有断点。

2.1 与“归因生成”研究的关系

学术界把“让生成内容可归因”称为 Attribution 或 Grounded Generation。Rashkin 等人 2021 年的工作（arXiv:2112.12870）提出用“归因到已识别支持证据”来度量摘要的可信度，其核心指标 AIS（Attributable to Identified Sources）后来被广泛引用。Bohnet 等人 2022 年（arXiv:2205.11482）进一步把归因拆成“归因性”和“引用质量”两个维度。本文评述：这些研究的共同贡献是把“可信”从主观感受变成了可计算指标，但它们的评测对象多是开放域摘要，而单位写作的约束更强——不仅要求“有支持”，还要求“支持来自现行有效文件”。这是本文主线相对学术归因研究的一个工程化延伸。

2.2 引用链的失败模式清单

在动手之前，先把失败模式列清楚，后续设计才有靶子。根据笔者的项目经验与公开文献整理，常见失败模式如下：

1. 跨块拼接幻觉：两个不相邻的片段被模型拼接成一句因果句，原文并无此逻辑。
2. 旧版覆盖新版：检索同时召回新旧两版文件，模型引用了已废止条款。
3. 数字漂移：原文“不低于 80%”，输出写成“约 80%”，语义已经改变。
4. 张冠李戴：把 A 部门的职责写到 B 部门名下，因两份文件格式相似。
5. 引用装饰化：输出末尾附了一堆文件名，但正文内容与这些文件无关，属于“假引用”。

这五类问题分别对应后续章节要解决的技术点：分块策略、版本元数据、约束解码、实体对齐、引用校验。可以说，整篇文章就是围绕这五个失败模式展开的“对症下药”。

三、文档解析与分块：把 PDF 变成可对齐的语义单元

引用链的第一环是来源可定位，而定位的前提是解析准确。单位文件大多是 PDF、Word、扫描件，格式混乱，这是整个链路最脏最累但最不能省的一步。很多团队把精力全投在模型和检索上，解析随便做做，结果后面所有环节都在为解析错误买单。

3.1 解析：版面还原比文字提取更重要

政策文件的价值往往藏在结构里：标题层级、条款编号、表格、脚注、附件说明。如果解析只做纯文本抽取，条款编号会丢失，表格会错行，脚注会混入正文。推荐的做法是使用具备版面分析能力的解析器，例如开源方案中的 PyMuPDF 用于文本与坐标提取，结合 PaddleOCR 或 Surya 处理扫描件，版面结构可用 LayoutParser 一类工具辅助。

解析阶段必须保留的元数据至少包括：文件名、文件哈希、版本号、生效日期、废止日期、密级、页码、字符偏移、条款编号。其中字符偏移是片段对齐的关键，它让“这句话来自第 12 页第 3 条第 2 款第 45 到 78 个字符”成为可验证的事实，而不是模糊描述。

# 解析阶段最小元数据结构（示意）
{
  "doc_id": "policy-2024-017",
  "file_hash": "sha256:9f2c...",
  "version": "2024-07-01",
  "effective_from": "2024-07-01",
  "effective_to": null,
  "security_level": "internal",
  "blocks": [
    {
      "block_id": "policy-2024-017#p12#c45-78",
      "page": 12,
      "char_start": 45,
      "char_end": 78,
      "clause": "第三条第二款",
      "text": "补贴标准不低于项目总投入的百分之八十。"
    }
  ]
}

3.2 分块：语义完整优先于长度均匀

分块（Chunking）是 RAG 系统里被低估的环节。常见做法是按固定字符数切分，比如每 500 字一块，重叠 50 字。这种做法实现简单，但会切断条款。政策文件的一条条款往往就是一个完整语义单元，切断了，检索到的就是残句，模型只能猜。

笔者推荐结构感知分块：优先按条款、段落、列表项切分，把每个块控制在 200 到 800 字之间；当单个条款过长时，再按句子边界二次切分，并保留父块 ID 以支持“小块检索、大块回填”。这种“父子块”设计在 LlamaIndex 的 SentenceWindowNodeParser 和 LangChain 的 ParentDocumentRetriever 中都有实现，思路一致：用小块提高检索精度，用大块保证上下文完整。

分块策略	优点	风险	适用
固定长度	实现简单、块大小均匀	切断条款、语义残缺	非结构化长文
结构感知	语义完整、对齐准确	块大小不均	制度、条款、规范
父子块	精度与上下文兼顾	存储与装配复杂	高精度政策问答
语义分块	主题内聚	依赖嵌入质量、成本高	混合主题文档

关于语义分块，Greg Kamradt 在 LangChain 文档中提出的“基于相邻句子嵌入相似度断点”的方法影响较广，其思路是计算相邻句子的余弦相似度，在相似度骤降处切分。本文评述：该方法在主题漂移明显的文档上有效，但政策文件本身主题高度集中，句子间相似度普遍偏高，断点信号弱，因此结构感知分块在政策场景下通常优于纯语义分块。这是一个典型的“方法要匹配数据特性”的判断。

3.3 表格与附件的特殊处理

政策文件里的补贴标准、申报条件、时间节点经常以表格形式出现。表格直接转文本会丢失行列关系，导致“哪个数字对应哪个项目”无法判断。建议的做法是：表格单独抽取为结构化对象，转成 Markdown 或 JSON 后作为独立块入库，并在块元数据中标注“表格”类型和表头信息。检索命中表格块时，生成阶段应优先以表格原文呈现，避免模型转述数字。

附件同理。很多政策正文只写“具体标准见附件”，真正的口径在附件里。解析时要建立正文与附件的关联关系，检索时若命中正文的“见附件”表述，应自动扩展召回对应附件块。这个机制在工程上叫“引用扩展召回”，是保证口径完整的重要手段。

四、检索层：向量、关键词与混合召回工程

检索是引用链的第二环。检索错了，后面全错。政策写作的检索有个特点：既需要语义匹配，也需要精确匹配。用户问“补贴怎么申请”，需要语义检索找到相关条款；用户问“第十七条怎么规定的”，需要精确匹配条款编号。单一检索方式都覆盖不了。

4.1 向量检索：嵌入模型的选择比维度更重要

向量检索的核心是嵌入模型。MTEB 排行榜（Muennighoff 等人，arXiv:2210.07316）是当前最常被引用的嵌入评测基准，涵盖检索、聚类、分类等任务。但笔者认为，排行榜分数只能作为初筛，真正决定效果的是嵌入模型在“本单位语料”上的表现。政策文本有大量专有名词、缩略语、机构名称，通用模型未必能区分“市局”和“区局”的语义差异。

实操建议是：准备 100 到 200 条本单位真实查询，人工标注正确块，然后对比 3 到 5 个候选嵌入模型在 Recall@5 和 MRR@10 上的表现。这个评测集不需要很大，但必须来自真实场景。近两年中文嵌入模型迭代很快，BGE 系列、GTE 系列、Conan 系列都有可用版本，选择时关注是否支持长文本、是否对中文政策语料友好。

4.2 关键词检索：BM25 依然是政策场景的刚需

BM25 是信息检索的经典算法，Robertson 和 Zaragoza 在 2009 年的专著中给出了完整推导。它在政策场景的价值在于精确匹配：条款编号、文件号、专有名词、数字，这些恰恰是向量检索的弱项。一个“第十七条”的查询，向量检索可能召回一堆语义相近但编号不同的条款，BM25 则能精准命中。

中文 BM25 需要先分词。政策文本分词要注意：机构名、政策术语应加入自定义词典，否则会被切碎。例如“城乡居民基本医疗保险”如果被切成“城乡/居民/基本/医疗/保险”，检索效果会明显下降。建议用 jieba 或 HanLP 配合领域词典，词典从本单位历史文件中自动挖掘。

4.3 混合检索与融合排序

把向量检索和关键词检索的结果融合，是当前主流做法。最简单有效的是 RRF（Reciprocal Rank Fusion），Cormack 等人 2009 年提出，公式为对每个文档累加 1/(k+rank)，k 通常取 60。RRF 不需要调权重，鲁棒性好，适合作为基线。

# RRF 融合示意（伪代码）
def rrf_fuse(vector_hits, bm25_hits, k=60):
    scores = {}
    for rank, doc in enumerate(vector_hits, start=1):
        scores[doc.id] = scores.get(doc.id, 0) + 1/(k+rank)
    for rank, doc in enumerate(bm25_hits, start=1):
        scores[doc.id] = scores.get(doc.id, 0) + 1/(k+rank)
    return sorted(scores.items(), key=lambda x: -x[1])

在 RRF 之上，还可以加元数据过滤：只召回 effective_to 为空的现行文件，只召回用户有权限访问的密级，只召回指定业务条线的文件。过滤应尽量在检索阶段完成而非生成阶段，因为把不该看的文件送进上下文，本身就是风险。

4.4 查询改写：把口语问题翻译成检索语言

用户提问往往是口语化的：“出差报销怎么弄”“这个补贴还能领吗”。这类查询直接检索效果差。查询改写（Query Rewriting）可以把口语问题转成检索友好的表述，并抽取关键实体。Ma 等人 2023 年的 Query Rewriting for Retrieval-Augmented LLMs（arXiv:2305.14283）讨论了用 LLM 做查询改写的方法，核心是让模型生成多个改写版本并融合检索结果。

笔者认为，查询改写要克制。改写过度会引入原查询没有的假设，导致检索偏移。稳妥的做法是：保留原查询，额外生成 2 到 3 个改写版本，分别检索后融合，让原查询始终占一票。同时，改写结果应记录在日志里，便于事后分析检索失败原因。

五、重排与上下文装配：把“对的片段”放到“对的位置”

召回之后是重排（Rerank）。召回阶段追求高召回率，可能返回几十上百个候选；重排阶段用更精细的模型打分，挑出最相关的几个。这一步对政策写作尤其重要，因为上下文窗口有限，放进去的每个片段都要“值回票价”。

5.1 交叉编码器重排

交叉编码器（Cross-Encoder）把查询和文档拼在一起送入模型，输出相关性分数。它比双塔嵌入更准，但更慢，所以只用于重排小候选集。Nogueira 和 Cho 2019 年的 Passage Re-ranking with BERT（arXiv:1901.04085）是这一路线的经典工作。工程上常用 bge-reranker、Cohere Rerank 等现成服务，也可以自己微调。

重排的评估指标是 NDCG@k。建议在自建评测集上对比“不重排”和“重排”的 NDCG@5 差异，如果提升不明显，说明召回质量已经很好，或者重排模型不适配本领域语料。本文评述：重排不是必选项，但在政策场景下，由于条款之间措辞高度相似，重排带来的区分度提升通常比较明显，值得投入。

5.2 上下文装配的三个原则

重排选出 Top-N 片段后，怎么放进提示词也有讲究。笔者总结三个原则：

1. 带标识：每个片段前加编号和来源，如“[1] 来源：XX管理办法（2024-07-01）第三条”。编号是后续引用锚定的基础。
2. 去冗余：相邻或重叠片段要合并，避免同一内容重复占用窗口，也避免模型误以为是两条独立依据。
3. 控顺序：把最相关的放最前和最后。Liu 等人 2023 年的 Lost in the Middle（arXiv:2307.03172）发现模型对上下文中部信息利用最弱，这个“中间遗忘”现象在长上下文场景普遍存在。

本文评述：Lost in the Middle 的结论提醒我们，堆上下文不等于用好上下文。政策写作应优先保证片段少而精，宁可选 5 个高相关片段，也不要塞 20 个凑数。上下文越长，模型对每个片段的注意力越稀释，引用准确性反而下降。

5.3 版本冲突的处理

政策场景特有的问题是版本冲突：同一事项可能有新旧两份文件，检索时都召回了。处理策略有两种：一是检索阶段硬过滤，只保留现行版本；二是检索阶段都保留，但在装配时标注版本，并在提示词中明确“以生效日期最新者为准”。

笔者倾向于第二种，理由是：有些旧文件的部分条款可能仍然有效（部分废止），硬过滤会误伤。正确做法是维护一份“条款级有效性”元数据，精确到条款而非文件。这增加了维护成本，但对口径准确性是必要的。如果做不到条款级，至少要做到文件级，并在装配时把版本信息显式写进片段标识，让模型和用户都能看到。

六、生成层：约束解码与引用锚定

到了生成环节，引用链进入最关键的阶段。前面所有工作都是为了给模型提供“可信材料”，但模型是否会忠实使用这些材料，取决于生成约束的设计。

6.1 提示词结构：把规则写死

政策写作的提示词不能太“客气”。必须明确几条硬规则：只能使用提供的材料；每句涉及事实的表述必须标注来源编号；材料中没有的内容必须写“材料未提及”；数字、期限、机构名称必须与原文逐字一致。这些规则要放在系统提示或提示词开头，并用明确的格式约束。

【写作规则】
1. 仅可依据下方【材料】作答，禁止引入材料外知识。
2. 每处事实性表述后必须标注来源编号，格式：[n]。
3. 数字、日期、比例、机构名称须与材料逐字一致，不得改写。
4. 材料未覆盖的内容，写“现有材料未提及”。
5. 若材料之间存在冲突，指出冲突并说明各自来源。

【材料】
[1] 来源：XX管理办法（2024-07-01）第三条
补贴标准不低于项目总投入的百分之八十。
[2] 来源：XX实施细则（2024-09-15）第五条
申报材料须于每年三月三十一日前提交。

6.2 引用锚定：让引用可验证

光让模型标 [n] 还不够，因为模型可能标错。引用锚定要做的是：生成后自动校验每个 [n] 是否真的支持其所在句子。校验方法可以是规则匹配（数字、专有名词是否出现在对应片段），也可以是模型校验（用一个小模型判断“句子是否被片段支持”）。

这一步在学术上对应“归因评估”。Rashkin 等人提出的 AIS 指标需要人工或强模型判断，工程上可以简化：对数字和专有名词做精确匹配，对一般性表述做语义蕴含判断。校验不通过的句子要么重新生成，要么降级为“待人工确认”，绝不能直接输出。

6.3 约束解码：从源头减少幻觉

约束解码（Constrained Decoding）是在 token 生成阶段施加限制，让输出符合特定格式或词汇表。在政策写作中，一个实用做法是：把关键数字、机构名、政策术语构建成受控词表，生成时对相关位置做偏置或限制。例如当模型要生成数字时，优先从材料中出现的数字里选。

这类方法在学术上有对应研究，如 Lu 等人 2021 年的 NeuroLogic Decoding（arXiv:2010.12829）通过逻辑约束控制生成，以及后续一系列关于受控文本生成的工作。本文评述：约束解码在政策写作中的价值被低估。它不追求生成多样性，恰恰相反，它追求的是“在关键位置不出错”。这与创作类写作的技术目标正好相反，是政策场景的特殊性所在。

6.4 拒答机制：不知道就说不知道

一个成熟的知识库写作系统必须会拒答。当检索结果相关性低于阈值，或校验发现材料不足以支撑问题时，系统应明确回复“现有材料未涵盖该问题”，而不是硬编一个答案。拒答阈值需要根据业务容忍度调，但原则是：宁可少答，不可错答。在政策场景，一个错误答案的代价远高于一个“不知道”。

七、评测与回归：口径零偏差怎么量化

“政策口径一个都不许错”是目标，但目标要能被度量才有意义。评测体系是引用链的最后一环，也是持续迭代的基础。

7.1 分层评测指标

建议把评测拆成检索、生成、引用三层，每层有独立指标，便于定位问题。

层级	指标	含义	目标参考
检索	Recall@5	正确块是否在前 5	≥ 0.90
检索	MRR@10	正确块排名倒数均值	≥ 0.80
生成	事实一致率	数字/名称与原文一致比例	= 1.00
引用	引用支持率	标注来源确实支持该句	≥ 0.98
引用	无依据句占比	无来源支撑的句子比例	≤ 0.02

表中目标参考值为笔者基于项目经验给出的建议区间，属于工程经验值而非文献结论，实际应根据业务风险等级调整。高风险场景（如对外发文）应把事实一致率要求设为 100%，任何不一致都需人工复核。

7.2 评测集构建

评测集是评测体系的核心资产。建议构建三类样本：

• 常规问答：覆盖高频业务问题，检验基本可用性。
• 边界问题：涉及新旧版本、跨部门、模糊表述，检验鲁棒性。
• 陷阱问题：故意问材料中不存在的内容，检验拒答能力。

每类建议 50 到 100 条，由业务人员标注标准答案和依据条款。这个评测集要版本化管理，每次知识库更新后重新跑一遍，观察指标是否回退。这就是“回归测试”的思路，在软件工程里是老生常谈，但在 RAG 系统里经常被忽略。

7.3 人工抽检与自动化结合

自动化指标能覆盖大部分问题，但有些问题只有人能发现，比如“表述虽然与原文一致，但语气不当”“引用条款正确，但适用场景不对”。建议建立人工抽检机制，每周随机抽取一定量输出，由业务人员复核，问题记录进缺陷库，定期分析根因。

自动化与人工的分工可以这样理解：自动化负责“一致性”和“可追溯性”，人工负责“适当性”和“专业性”。两者互补，缺一不可。

八、工程落地：一套可复用的系统骨架

把前面各章串起来，可以得到一套完整的系统骨架。本节给出模块划分、数据流和关键配置，供落地参考。

8.1 模块划分

┌─────────────┐   ┌─────────────┐   ┌─────────────┐
│  文档接入层  │ → │  解析分块层  │ → │  索引存储层  │
│ 上传/版本/密级│   │ 版面/条款/表格│   │ 向量+倒排+元数据│
└─────────────┘   └─────────────┘   └─────────────┘
                                            ↓
┌─────────────┐   ┌─────────────┐   ┌─────────────┐
│  输出审计层  │ ← │  生成约束层  │ ← │  检索重排层  │
│ 日志/引用快照│   │ 提示/锚定/校验│   │ 混合召回/重排 │
└─────────────┘   └─────────────┘   └─────────────┘

8.2 关键配置建议

环节	配置项	建议值
分块	块大小 / 重叠	200–800 字 / 按结构不重叠
检索	召回数量	向量 30 + BM25 30
融合	RRF k 值	60
重排	保留数量	Top 5–8
生成	温度	0–0.2
校验	拒答阈值	按业务调，宁严勿松

8.3 日志与审计

每次生成都要记录：查询原文、改写版本、召回列表、重排分数、装配片段、模型输出、引用校验结果、最终输出。这些日志是事后审计和问题复现的基础。日志要脱敏存储，访问受控。建议保留至少 6 个月，高风险场景建议保留 1 年以上。

8.4 拓展学习资源

以下资源适合动手实践时参考：

• LangChain 官方文档的 RAG 教程：python.langchain.com/docs/tutorials/rag
• LlamaIndex 的检索与重排指南：docs.llamaindex.ai
• MTEB 排行榜：huggingface.co/spaces/mteb/leaderboard
• RAG 综述论文（arXiv:2312.10997）：arxiv.org/abs/2312.10997
• DeepLearning.AI 的 RAG 短课程：deeplearning.ai/short-courses

九、前沿预判与风险边界

技术演进很快，本节讨论几个可能影响知识库挂载写作的前沿方向，以及需要警惕的风险边界。

9.1 长上下文与 RAG 的关系

随着上下文窗口从 4K 扩展到 128K 甚至更长，有人提出“长上下文会取代 RAG”。本文评述：这个判断在政策场景下不成立。原因有三：一是成本，把整个知识库塞进上下文不现实；二是精度，Lost in the Middle 现象说明长上下文不等于高利用；三是可追溯性，长上下文无法提供块级引用锚点。更可能的趋势是两者结合：用 RAG 定位，用长上下文承载更多相关材料。

9.2 智能体化检索

Agentic RAG 是近两年的热点，让模型自主决定检索什么、检索几次、是否需要追问。这在复杂政策咨询中可能有价值，比如用户问题模糊时主动澄清。但笔者认为，在“口径零偏差”的硬约束下，智能体的自主性要受限：它可以决定检索策略，但不能决定引用哪些条款，引用必须由确定性逻辑控制。

9.3 风险边界

最后必须强调几条边界：

• 知识库写作系统是辅助工具，不能替代人工审核，尤其是对外发文、法律文书、财务报告等高风险场景。
• 系统输出必须可追溯，不可追溯的输出不应被采用。
• 知识库的版本管理是持续工作，文件更新后必须同步更新索引，否则系统会用旧知识误导用户。
• 权限控制必须严格，检索层和输出层都要做权限校验，防止越权访问。

十、结论与操作清单

回到文章开头的问题：怎么让 AI 严格引用单位资料，政策口径一个都不许错？本文给出的答案是：以可追溯性为主线，把引用链的四个环节都做扎实。模型能力是变量，引用链是常量；把常量做对，变量才有意义。

最后给出一份可执行的操作清单，供落地时对照：

1. 解析阶段保留页码、字符偏移、条款编号，建立文档级和块级元数据。
2. 分块采用结构感知策略，条款优先，父子块支持精度与上下文兼顾。
3. 检索采用向量 + BM25 混合，RRF 融合，元数据过滤前置。
4. 重排用交叉编码器，保留 Top 5–8，注意 Lost in the Middle。
5. 提示词写死引用规则，每句事实标注来源编号。
6. 生成后做引用校验，数字和专有名词精确匹配，不通过则降级。
7. 建立分层评测集，覆盖常规、边界、陷阱三类问题，版本化管理。
8. 全链路日志留存，支持事后审计和问题复现。
9. 设置拒答机制，材料不足时明确说“未提及”。
10. 知识库更新后跑回归测试，观察指标是否回退。

这十条看起来朴素，但每一条都对应着引用链上的一个断点。把它们做到位，政策口径的准确性就有了工程保障。技术会继续演进，但“可追溯”这个要求不会变——因为单位写作的底线，从来不是写得多漂亮，而是写得对不对。