# 把 1242 条法规做成离线可核查的知识库：一个基层执法场景的落地过程

> 我手上有件真事。2026 年 9 月的一份现场检查记录只有两行字：厂区东侧空地露天堆放表面处理污泥约 3.6 吨（HW17），未采取防扬散、防流失、防渗漏措施；危险废物管理台账 1 月至 8 月缺失。
>
> 就这两行。同一个堆放行为，能落到三条不同的条款上，罚款幅度从几万到几十万。差别不在法条背得熟不熟——法条可以回来查——**在于那天从现场带回来什么**。带回来的东西不够，后面写多少份文书都补不上。
>
> 这篇不谈法律适用（那是另一回事），只谈工程：怎么把一套会修订、会打架、会失效的条文，做成**离线可用、每条可溯源、冲突能报警**的本地知识库。

## 一、为什么不能用通用大模型直接问

先说清楚不要做什么。

直接把问题丢给在线大模型，得到的答案有三个致命问题：

1. **不知道依据的施行日期**。法律文件修订频繁，模型训练语料里的版本可能已经作废，但它说得一样自信。
2. **不知道冲突时以谁为准**。同一事项，法律、行政法规、部门规章、地方性法规、规范性文件可能都有规定，效力层级和适用规则模型不会自动判断。
3. **无法溯源**。它给出的条款，你没法一键回到原文核对。

我在实际使用里遇到过最危险的情况不是"答不上来"，而是**答得很像真的**——措辞规范、条款编号完整、逻辑自洽，但那个编号对应的内容是另一回事。这种错误在执法场景里是要出事的。

所以知识库的设计目标必须是：**每一条结论都能点回原文，并且标明核对日期。**

## 二、数据怎么组织：以"条文"为最小单位

不要把整部法律当一个文档存。检索粒度太粗，引用也不精确。

最小单位应该是**条**，字段这样设计：

```sql
CREATE TABLE article (
  id            INTEGER PRIMARY KEY,
  law_name      TEXT NOT NULL,     -- 所属文件全称
  law_level     TEXT NOT NULL,     -- 效力层级：法律/行政法规/部门规章/地方性法规/规范性文件
  article_no    TEXT NOT NULL,     -- 条号，如 "第三十八条"
  content       TEXT NOT NULL,     -- 条文正文
  effective_from TEXT,             -- 施行日期
  effective_to  TEXT,              -- 失效日期（NULL 表示现行有效）
  source_url    TEXT,              -- 来源链接
  source_name   TEXT,              -- 来源名称（用于双源核对）
  checked_at    TEXT NOT NULL,     -- 最后一次人工核对日期
  version_tag   TEXT               -- 版本标记，如 "2026-08-15施行版"
);
```

几个字段看着普通，但缺了就出问题：

- **`effective_to`**：法规不会主动告诉你它失效了，只会有新文件宣布"某某文件同时废止"。没有这个字段，检索结果会混进废止条款。
- **`checked_at`**：这条最关键。它把"机器里存的"和"人核过的"区分开。检索结果里凡是 `checked_at` 距今超过 N 天的，界面上要打标提示复核。
- **`law_level`**：冲突判断的基础。上位法优于下位法、特别规定优于一般规定、新规定优于旧规定，这些规则要靠层级字段才能自动提示。

## 三、检索：先别上向量库

一个反直觉的建议：**一开始不要用向量检索。**

法规检索的核心诉求是**准确命中条款编号和关键词**，不是语义模糊匹配。模糊匹配在这里是缺点——你可能检索"未采取防护措施"，结果召回一条语义相近但完全不适用的条款，而且它还排在前面。

先用 SQLite 的 FTS5 做全文索引就够了：

```sql
CREATE VIRTUAL TABLE article_fts USING fts5(
  law_name, article_no, content,
  content='article', content_rowid='id'
);
```

查询时按"精确条号 > 关键词 > 语义"三级降级：

```python
def search(query):
    # 1) 精确条号：如 "固体废物污染环境防治法 第三十八条"
    rows = exact_article(query)
    if rows:
        return rows, 'exact'

    # 2) 关键词命中（FTS5，带 BM25 排序）
    rows = fts_search(query, limit=10)
    if rows:
        return rows, 'keyword'

    # 3) 实在没有才做语义召回，且必须标注"语义匹配，需人工核对"
    rows = semantic_search(query, limit=5)
    return rows, 'semantic'
```

语义召回的结果**必须打标**，不能和精确命中混在一起展示。这是防止"像真的"错误的第一道闸。

## 四、双源核对：一条条文至少查两个来源

这是整个库里最费人工、也最不能省的一步。

规则很简单：**同一条条文，必须从两个独立来源核对一致后才能入库**。来源可以是官方发布平台、正式出版的汇编、上级机关下发的文本。两个来源不一致时，不入库，标记冲突，人工介入。

```python
def cross_check(law_name, article_no):
    a = fetch_source('official', law_name, article_no)
    b = fetch_source('compiled', law_name, article_no)
    if not a or not b:
        return {'status': 'MISSING', 'detail': '至少一个来源缺失'}
    if normalize(a) != normalize(b):
        return {'status': 'CONFLICT', 'a': a[:200], 'b': b[:200]}
    return {'status': 'OK', 'content': a}
```

`normalize` 要做的事：去掉全半角差异、统一空格、统一引号、去掉页码和版式符号。不做归一化，两个来源会因为排版差异永远不一致。

我在实际整理中，第一轮核对的冲突率不低——主要是修订版和旧版混在一起。**这些冲突本身就是最有价值的产出**：它告诉你哪些条文最近动过。

## 五、冲突检测：让库自己报警

入库之后要有一个定时任务扫全库，找出"同一事项、不同条文、结论不同"的情况：

```python
def find_conflicts():
    """找出可能适用同一行为、但规定不一致的条文组"""
    groups = group_by_keyword(load_all())   # 按行为关键词聚类
    out = []
    for g in groups:
        levels = {r['law_level'] for r in g}
        if len(levels) > 1:
            # 存在不同效力层级 → 提示按层级适用
            out.append({'group': g[0]['keyword'], 'items': g})
    return out
```

输出不是"答案"，是**需要人工确认的清单**。系统会提示：这一组里存在上位法和下位法，适用时优先看哪一条，但**不替你做决定**。

这个边界很重要。执法判断的责任主体是人，工具只能保证"你看到的是全的、是最新的、是可溯源的"。

## 六、离线：为什么不能依赖网络

两个现实原因：

1. **现场没网**，或者信号很差。检查现场在厂区、在山区，这是常态。
2. **联网查询不可复现**。今天查到的结果，明天网页改了就变了。办案卷宗里引用一个网页链接，半年后链接失效，这份卷宗的证明力就有瑕疵。

所以整个库是本地 SQLite 文件，检索、比对、导出全在本地完成。导出引用时写的是**文件全称 + 条号 + 版本标记 + 核对日期**，不写网址。

```python
def citation(row):
    return f"《{row['law_name']}》{row['article_no']}（{row['version_tag']}，核对日期 {row['checked_at']}）"
```

## 七、复盘：最有价值的不是检索，是"带回来什么"

回到开头那个只有两行字的检查记录。

知识库能解决的问题是：这两行字对应的行为，可能适用哪些条款、条款现行是否有效、条款之间效力如何排序。

知识库**不能**解决的问题是：那天现场有没有拍照、有没有测量、有没有固定证据。这些没做，后面写多少份文书都补不回来。

所以这套东西真正的用法，是在**去现场之前**先看一遍：这个类型的违法行为，通常需要固定哪几类证据、对应哪些要件、常见争议点在哪。把这张清单打印出来带在身上，比回来再查有用得多。

工具的价值不在"事后能查到"，在"事前知道该带什么回来"。

## 八、一句话总结

- 最小单位存到**条**，不是存到**部**
- 每条必须有 `effective_to` 和 `checked_at`
- 检索先精确后语义，语义结果必须打标
- 入库要**双源核对**，冲突不自动合并
- 冲突只报警、不裁决
- 全程离线，引用写版本和日期、不写网址

这些规则看着繁琐，但每一条都对应一次真实的翻车。


我手上有件真事。2026 年 9 月的一份现场检查记录只有两行字：厂区东侧空地露天堆放表面处理污泥约 3.6 吨（HW17），未采取防扬散、防流失、防渗漏措施；危险废物管理台账 1 月至 8 月缺失。

把 1242 条法规做成离线可核查的知识库：一个基层执法场景的落地过程

先说清楚不要做什么。 直接把问题丢给在线大模型，得到的答案有三个致命问题： 1. 不知道依据的施行日期。法律文件修订频繁，模型训练语料里的版本可能已经作废，但它说得一样自信。 2. 不知道冲突时以谁为准。同一事项，法律、行政法规、

数据库

后端

架构设计

把1242条法规做成离线可核查知识库，最小单位存条文，含效力层级、施行日期、失效日期及人工核对标记。检索按精确条号、关键词、语义三级降级，语义结果必须打标。双源核对防版本错误，冲突自动报警不裁决。全程离线可用，引用写明版本与核对日期，确保每项结论可溯源。

代码解释

SQLite

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

把 1242 条法规做成离线可核查的知识库：一个基层执法场景的落地过程-腾讯云开发者社区-腾讯云

把 1242 条法规做成离线可核查的知识库：一个基层执法场景的落地过程

把 1242 条法规做成离线可核查的知识库：一个基层执法场景的落地过程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐