1242 条。这是《生态环境法典》的条文总数，也是我这个月重做知识库的直接原因。之前那套法律问答系统，在上一轮环境法文本体系调整——十几部单行法退场、新法典整体登场——之后不到一周就暴露出严重的"记忆错乱"：问它违法排污怎么罚，它引的是旧法条号；问它生态破坏修复责任，它能把新旧规定混在一起拼出个答案。更麻烦的是，通用大模型的训练语料根本没来得及收录新文本，你就算把法条 PDF 传进知识库，只要分块和检索链路没设计好，它照样会给你编一个不存在的条文号。
这周我把整套流程重搭了一遍，重点是让 AI 在引用《生态环境法典》时做到两点：要么给出准确的编、章、条、款信息，要么明确告诉你"没查到"，绝不靠猜。下面把这套方案完整拆开讲：1242 条文本如何清洗分块、如何建新旧对照表、如何用 Ollama 本地验证再迁到 Dify 跑通知识库流水线，以及我们怎么设计防幻觉校验机制。如果你手里也握着规章制度、行业标准、操作规范这类"一字都不能错"的文本要转成知识库，这篇很值得看完。
1. 法律文本入知识库，难点不在"切文本"，而在"让AI分清新旧"
1.1 通用分块策略为什么会在法条上翻车
很多 RAG 教程第一步就是按固定字数切块：每 500 字一块，留一点 overlap。这种方案跑小说、跑新闻没问题，但跑到法条上几乎是灾难。原因很简单——法律文本的最小语义单元是"条"，而不是"500 字"。
举个我实际遇到的例子。按 500 字硬切，有一条关于处罚的规定从"违反本法规定，未依法取得排污许可证排放污染物的"开始，切到"由生态环境主管部门责令改正或者责令限制生产、停产整治"就断掉了，下一个分块从"并处十万元以上一百万元以下的罚款"开始。用户问"无证排污怎么罚"，检索系统召回了后半个分块，模型看到的是"并处十万元以上一百万元以下的罚款"，它压根不知道这是针对无证排污的罚则，于是开始自由发挥：有的模型把"责令改正"删掉，有的把处罚对象换成了别的违法行为。这就是"切块切碎了条文，生成阶段只能靠脑补"的典型翻车过程。
法条自带严格的层级结构：编、章、节、条、款、项。"条"是引用单位，律师和执法人员在沟通时说的都是"第几条"，判决书里引用的也是"第几条第几款"。如果你把一条连着上下文切开，等于把法律文的"地址信息"抹掉了，后面的模型和人都没法溯源。所以第一步认知必须扭转：法律知识库的分块单元不是固定字数，而是条文本身。
1.2 "记错"的三种典型表现
我把自己在旧系统上看到的错误归类成下面这张表，排查的时候就对着这张表逐条对照：
| 故障形态 | 具体表现 | 根因 |
|---|---|---|
| 旧条号复活 | 回答引用退场单行法的条文号，比如一本正经说出"根据《大气污染防治法》第XX条" | 模型底座训练语料和公开网络数据中还大量存在旧法内容 |
| 新旧条文拼凑 | 把新法典的原则条款和旧法的罚则条款拼在一起 | 检索结果里混入了旧文本片段，且没有做一致性校验 |
| 条文张冠李戴 | 引用了相邻章节里看似相关、实则针对别的事项的条文 | 分块破坏了条文边界，向量检索只能按语义模糊匹配 |
"记错"最隐蔽的是第二种——它不是一眼看得出的离谱错误，而是看起来挺专业、条号也存在，但仔细核对发现引用的条款讲的是另一件事。这种错误在纯人工审查时都容易漏掉，更别说直接暴露给终端用户。
1.3 新法典给检索系统带来的特殊麻烦
这轮调整的特殊性在于：不是一部法律改几个条款，而是一个领域内原本分散的单行环境法律被统合进一部法典，条文编号、章节归属、规范表述全都变了。原有的法条在互联网上、在模型参数里、在用户脑子里都是"旧地址"。
对检索系统来说这就是典型的"检索污染"：用户输入"大气污染防治""水污染处罚"这些关键词，embedding 模型匹配到的可能还是语料中大量存在的旧条文表述。向量检索不讲道理，它只管语义相近，不管该条文现在还生不生效。所以单靠"把新 PDF 传进知识库"完全不够，必须在检索层就把旧法内容隔离掉，在生成层强制 AI 只能依据检索结果作答。这两件事不做，AI 一定会记错。
2. 预处理：把 1242 条变成"带身份证"的独立卡片
2.1 源文件清洗：从官方文本到干净语料
我在处理这类文本时坚持一个原则：尽量用官方发布的电子文本，不用扫描件直接跑 OCR。官方 PDF 通常可以直接用 pdfplumber 或 PyMuPDF 提取，保留的排版相对规整。如果只有扫描件，才退回 OCR 方案，而且必须做条文数量校验。
提取出来的原始文本一般带着页眉页脚、目录、"编者按"等杂质。我会先用一个正则表达式把所有的"条"标题找出来：
import re article_pattern = re.compile(r'^第[一二三四五六七八九十百零]+条\s') # 按行扫描，命中即为一条的起点找到所有条文起点后，立刻做一个硬校验：统计出来的条文总数必须等于 1242。如果少了，说明有 OCR 识别错误或者 PDF 漏页，不要急着往下走，先补全数据。我用这个方法抓到过好几处把"第"识别成"芻"的情况，不校验的话后面的分块工作全白做。
2.2 分块策略：以"条"为最小检索单元，同时保留"款"的边界
清洗干净后，我开始把整部法典拆成独立卡片。每一条法条是一张卡片，卡片里除了条文正文，还必须带上完整的上下文信息，我称之为"身份证字段"：
| 字段 | 示例 |
|---|---|
| code_name | 生态环境法典 |
| part（编） | 第二编 污染防治 |
| chapter（章） | 第二章 大气污染防治 |
| article_no（条号） | 第245条 |
| clause_label（款） | 第2款 |
| status | 现行有效 |
| version | 2026-01-01 施行文本 |
对于长度相对正常的条文（500 个 token 以内），直接整条作为一个 chunk。对于特别长的条文，比如一个条文下面有七八款、还带项目和举例的，我会按"款"切成子块，但每个子块都必须保留完整的条号前缀和款号，比如"第120条第3款"，另外加一个 parent_article 字段指向原始整条。这样做的好处是：检索命中某一个款的子块时，生成阶段依然能准确引用到"第几条"，不会把款项混掉。
文本里有表格和附件的部分要特殊处理。法典里的排放标准表、污染物名录，如果直接按段落切，表格结构会碎成一地。我会把表格转成"键值对"或"编号条目"形式的自然语言描述，再作为独立卡片放进去。这一步很花时间，但检索效果提升是立竿见影的。
2.3 建一张"新旧对照表"，并当成知识库的一部分存进去
处理完新条文，我额外做了一张对照表：把已退场单行法里的条文号和新法典的条文号对应起来。这张表的核心价值在于：用户很可能还按旧法习惯提问。比如用户直接问"《大气污染防治法》第28条现在对应哪条"，如果知识库里只有新法典文本，检索系统大概率找不到，模型就会开始编。
对照表我做成 CSV/JSON 结构，每条记录至少包含三个字段：旧法名称、旧条文号、新法典对应条文号及状态（已吸收/已调整/不再单设）。这张表作为一份独立文档上传到知识库，并设置它在检索时拥有更高的权重。实测中这一招挽回了大量"用户用旧话术提问"的场景。
3. 检索流水线的选型与搭建：本地验证跑通，再迁到 Dify
3.1 为什么先拿 Ollama 做本地最小闭环
正式搭 Dify 流水线之前，我习惯先在本地把"嵌入—入库—检索"这条最小链路跑通。原因有三：第一，迭代快，改分块策略不用走完整 UI 流程；第二，方便看 embedding 模型的真实效果，判断是模型问题还是数据问题；第三，法律文本可能涉及敏感内容，本地跑一版更安心。
我是这么跑的：用 Ollama 拉一个 BGE 系列的 embedding 模型（BAAI/bge-large-zh-v1.5 或 bge-m3 都可以），把法条卡片向量化后存入内存版 Qdrant，然后写几行查询代码验证命中效果：
from sentence_transformers import SentenceTransformer from qdrant_client import QdrantClient model = SentenceTransformer("BAAI/bge-large-zh-v1.5") # docs 为预处理后的法条卡片文本 vectors = model.encode(docs, normalize_embeddings=True) client = QdrantClient(":memory:") # 建 collection、写入向量后，用用户问题做检索 hits = client.query_points( collection_name="eco_code", query=model.encode("未取得排污许可证排放污染物怎么罚", normalize_embeddings=True), limit=5 )这一步能很直观地暴露问题：检索出来的前五条里是否包含正确的条文、有没有混入旧法相关内容、条号和问题是否对应得上。我在这个阶段就发现过嵌入模型对"按日计罚"这类专业表述命中率偏低的问题——因为模型训练语料里这类专业短语出现频率不高，于是我在分块文本里额外拼接了同义词和领域别名，比如在卡片里补上"按日连续处罚"等检索同义词。对法律文本来说，给卡片做"别名增强"比单纯依赖向量语义靠谱得多。
3.2 Dify 知识库流水线的落地配置
本地验证通过后，我把它迁到 Dify 里做成一条可复用的知识库流水线。所谓"流水线"，在我这里的理解是：数据清洗 → 分块 → 向量化 → 入库 → 检索 → 生成 → 评测，每一步都是独立组件，可以单独替换和重跑，而不是一次性手工处理。
Dify 里的关键配置我记录如下：
- 创建知识库后选择"自定义分段"模式，分段标识符设为"第……条"的文本结构，也就是按条文边界切分，而不是按长度切分。
- 索引方式选"高质量"，embedding 模型在 Dify 设置里统一选 BGE-M3。如果你们公司用的是云厂商 API，也可以用 text-embedding-3 系列，但对比下来本地 BGE-M3 在法律文本上的效果并不输。
- 检索模式打开混合检索（向量 + 全文），并开启 Rerank。Rerank 模型我用的是 bge-reranker-v2-m3，这一步把条文命中的准确率拉高了非常明显。
参数实测值供参考：
| 参数 | 我用的值 | 说明 |
|---|---|---|
| 分块大小 | 按条文边界 | 固定字数会切断条文引用 |
| overlap | 0（子块带完整条头） | 法条场景不需要靠 overlap 补上下文 |
| Top K | 5 | 太少漏召回，太多引入噪声 |
| Score Threshold | 0.55 ~ 0.65 | 法条问答阈值宜偏高，防止无关条文混入 |
| Rerank | 开启 | 显著提升条文级命中率 |
有朋友问"RAG 知识库能存储图片吗"，纯法条场景里我们基本不存图片，因为表格和图示都会转成结构化文本。但如果你要把原始 PDF 页面作为溯源附件存进去，Dify 本身是支持关联原始文档的，可以在回答下方附一个"查看原文"的链接，这个对法律场景很有价值，建议打开。
3.3 生成阶段的提示词约束
在 Dify 的应用编排里，我为知识库问答专门写了一版提示词，核心思路是"只允许引用检索结果，禁止调用模型自身对法律条文的记忆"：
你是一名环境法律事务助手。回答时只能使用知识库检索到的条文内容， 引用格式统一为：《生态环境法典》第X条，必要时写明款次。 禁止补充未在检索结果中出现的条文号。 若检索结果中没有相关条文，请直接回答： “未检索到相关条文，请核实法律名称、条文号或问题范围。”这条提示词的意义在于把模型逼到"查不到就说查不到"的位置。法律场景下，一个诚实的"不知道"远比一个编造的"第X条规定"有价值。我把"拒绝回答"本身当成一种有效输出，后面做评测时专门为它设置了指标。
4. "不会记错"的验证机制：三层约束 + 一套测试集
4.1 第一层约束在检索端，第二层在生成端
前面提的新旧对照表、别名增强、混合检索和 Rerank，都是在检索端把候选范围缩小。生成端的提示词约束则负责把范围锁死。三层约束缺一不可：检索层不管，模型会从自己的记忆里抽旧条文；生成层不管，模型会对检索结果做过度发挥，比如把两种相近违法行为混在一段话里；评测层不管，你永远不知道系统什么时候开始退化。
4.2 构建问答测试集：30 道常规题 + 10 道陷阱题
为了让"不会记错"可度量，我建立了一套问答测试集，分两大类：
常规题覆盖典型执法场景：无证排污的处罚、按日计罚的适用条件、生态赔偿的流程、信息公开的范围等。陷阱题的设计更有意思，我列几个典型的：
| 陷阱类型 | 测试问题示例 | 期望行为 |
|---|---|---|
| 旧法条号提问 | 《大气污染防治法》第28条现在对应哪条？ | 调用新旧对照表后给出新条号，否则拒绝回答 |
| 无中生有 | 环境损害赔偿的最高限额是多少？ | 知识库无此直接规定，应回答未检索到 |
| 相近术语误导 | "限期治理"和"停产整治"是什么关系？ | 只引用检索到的条文，不做超出语料的发挥 |
| 跨章跨编综合 | 工业园区入驻企业要办哪些环保手续？ | 逐条引用相关条文，不合并编造 |
评测时我重点关注三个指标：条文号命中率（回答引用的条文号是否真实对应问题）、拒答率（陷阱题里正确给出"未检索到"的比例）、召回率（Top 5 结果是否包含正确条文）。加了新旧对照表和 Rerank 之后，条文号命中率从 68% 提到了 91%，拒答率从不到五成提到九成以上。
4.3 自动化评测手段
手工验 40 道题太慢，我后来把测试集接到了评测流程里：每次改完分块策略或提示词，自动跑一遍测试集，输出指标变化。Dify 自带日志，但做对比实验我还是习惯把问答结果导出后单独写脚本算分。
算分我有一个简单粗暴但有效的办法：对每道题的参考答案，提取"应当引用的条文号集合"，再用一个小的解析规则从模型回答里提取"实际引用的条文号集合"，最后算交集。引用号和参考答案完全一致才算命中，不是"意思差不多就行"。法律场景必须用这种严格口径。
有一点要提醒：LLM-as-Judge 在法条场景不能全信。我用大模型辅助初筛，但涉及关键词"是否构成污染""处罚是否过重"这类判断时，最后都会人工复核一遍。毕竟我们做的是一个"一字都不能错"的知识库，机器评测是筛子，人眼是底线。
5. 实测踩坑记录与后续迭代方向
5.1 坑一：OCR 把"第"识别成杂字，导致条数对不上
第一次处理扫描版资料时，正则匹配到的条文数只有 1238，比 1242 少了 4 条。排查后发现是 OCR 把某几处的"第"识别成了生僻字形。后来我加了双重校验：一是条文总数必须等于 1242；二是每个编号"第X条"必须是连续递增序列。这两个校验一过，数据基本就不会有大的偏差。任何文本入库前都要做数量和连续性校验，这是法律知识库的最低保障。
5.2 坑二：用户按旧法提问，系统找不到就编
旧对照表上线前的真实翻车现场：用户问"原《环境影响评价法》第31条的内容现在在哪里"，知识库里没有这部法，模型检索不到，就编了一个"根据现行法律规定，违规环评将处以……"的回答。因为模型在训练语料里见过旧法内容，它以为自己知道。后来加入新旧对照表和强制拒答提示词之后，这类问题才被拦下来。凡是旧法名称出现在用户的提问里，检索系统都必须能处理，否则直接让它拒绝回答，而不是让它靠内存作答。
5.3 坑三：长条文切"款"之后，款次信息丢失
长条文按款切块时，最初我只在子块里写了"第120条"，没写"第2款"。结果用户问"第120条第2款的处罚标准是什么"，系统召回的是整条第120条的多个子块，模型分不清哪款对应哪款，引用经常张冠李戴。修复方案是把款次写进每个子块的标题里："第120条第2款（处罚标准）"，同时在元数据里保留 parent_article 字段。现在引用精度明显好了。
5.4 下一步：Agent 化与持续更新
目前这套系统已经能稳定跑日常问答，但我觉得下一步的想象力在 Agent 化。计划给系统加一个前置工具：用户提问时先识别是否包含旧法名称，如果包含，就先调用新旧对照表做条文映射，再把映射后的新条文号作为检索条件进入知识库。这已经不只是简单的 RAG，而是一个具备"条文路由"能力的 Agent 工作流。
另外，法律文本是会持续更新的——以后就算新法典本身也有修正案、司法解释，不能每次手动重跑全流程。我正在把预处理和分块脚本固化成一条可重复执行的流水线：拿到新版本文本，运行一遍，对比旧版差异，自动更新卡片和向量库。整条链路的版本管理做好之后，再改法也不用推倒重来了。
整理这套流程时我最大的体会是：知识库的"准确性"从来不靠某一个特别强的大模型，而是靠分块、检索、生成约束和评测四层一起兜底。模型可以变、嵌入模型可以换，但"以条文为单元 + 新旧隔离 + 强制引用 + 严格评测"这套方法论是通用的。下次再拿到一摞规章、标准或合同条款，我只需要把语料替换掉，整条流水线就能直接复用。
