怎么搭建“证据级”AI知识库？50万页材料沉淀出来的6条铁律

查阅一家上市公司的问询记录，与查明某项公司业务适用何种法规条款，是投行或者律师的专业工作中每天都在交织出现的两类硬需求。前者需要寻找具有可比性的历史案例，看监管尺度与中介核查程序；后者需要定位适用于当下事实的法定规则，逐条对照要件与例外情形。

很多人以为，AI 的出现已经可以替代这两类专业需求：把招股书和法规文档接入向量库，套一个通用的 RAG（检索增强生成）就能一键出报告。

在投行和法律工作中，把资料接入 RAG，只完成了从文档到答案的一部分工作。如果切分时没有保留公司、期间和材料角色，检索结果就可能只剩背景断裂的片段；如果相关定义、适用条件或例外没有一并取得，后续分析也可能出现偏差。

有两个公开案例把这个问题写得很具体。

Anthropic 在 2024 年用美国证券披露片段举例：“The company's revenue grew by 3% over the previous quarter.” 单独取到这句话时，公司和季度都已缺失。同年，斯坦福 RegLab 与 HAI 对美国主流法律研究工具的预注册评测记录，Westlaw AI 把案例材料中公司关于知识产权保护的公告，写成了该案文书已经确认的结论。

这类问题不在于模型有没有语言能力，而在于资料是否带着足够的身份、时间、上下文和关联关系进入后续分析。因此，我在建设知识库时，除了关注能否搜到内容，还会检查来源、上下文和引用关系，以及这些材料是否足以支持当前判断。

为了解决自己业务中反复遇到的核查与研究痛点，我独立搭建、并持续维护了两个底层专业知识库：

• 面向审核实务的 IPO 案例库（NERO IPO Atlas），目前登记版本为 2.1.0，累计收录了 784 个申报项目（含 576 个 IPO、128 个创业板再融资、80 个科创板再融资）、2,613 份官方 PDF（约 10.22GB）、495,742 页原始文档、6,532 个问询问题与 109,843 条关键摘录；
• 面向合规底线的 资本市场法律库（NERO Capital Legal），目前登记版本为 1.0.2，覆盖 6 个市场与 5 类常规业务的 30 个核心覆盖单元，纳入 86 部官方全文与效力沿革链条，整理出 14,408 个检索单元与 20,253 个层级节点。

近 50 万页专业材料一步步啃下来，踩过无数隐蔽的工程深坑之后，我逐渐意识到：

决定一个专业 AI 系统能不能真正进入业务一线干活，首先需要打通的是底层知识库建设。一个真正可信的专业知识库，必须具备六道环环相扣的能力。

这六项能力是一张实打实的工程排障清单。系统在实际业务中跑偏了，不用凭感觉去调表层参数，直接顺着链路倒查：是原始资料漏收了？是解析结构粘连了？是词法检索截断了？还是案件事实本身就没给全？每一处改动，都能落到实处。

一、收得到：建立材料原件台账与数据资产化边界

1、从一批有明确范围的项目开始

案例库刚动工时，我先把范围收缩在 2025 年以来的科创板申报、过会、注册与问询。我没有急着把 PDF 扔进解析器，而是先给企业和事件立规矩、建台账。

在审核监管里，申报、过会、注册是性质完全不同的离散事件。市面上经常有人拿某一期的过会数直接除以申报数，算出一个“审核通过率”，这在业务逻辑上是说不通的——过会的可能是大半年前甚至一年前受理的项目，分子分母根本不在同一个统计切片里。拿项目现在的终态，无法直接还原历史流转过程。

因此，台账从一开始就把企业身份与审核事件彻底分立：企业有唯一的全局 ID，申报、首轮问询、多轮答复、上市委审议、注册生效等关键节点。有了这套台账，后续要统计某个窗口期的真实受理规模，或者回溯某批项目的审核周期，直接查表即可，不必重新全量检索。

在工程上，程序通过企业全局 ID，串联起全称、行业、财务指标、申报标准与申报日期，做排重与状态校验，同时死死锚定官方原始文件链接。这些元数据看起来平平无奇，却决定了后续几十万页底稿能不能挂到正确的主体与时点上。

在此基础上，我搭了一个从市场大盘下钻到单家企业的全景看板，把板块、行业、申报月份与公司名录咬合起来。做这个页面的目很实在：我自己要肉眼筛查。某个月的受理量是否突兀偏离，某个行业的归类是否存在歧义，一旦发现疑点，随时顺着链路敲回底层台账和官方披露文件核实。

2、扩大范围时，保留各自的业务口径

科创板跑顺之后，我把底座拓展到创业板与北交所，三板合计归集了 576 个 IPO 案例（科创板 111 个、创业板 140 个、北交所 325 个）。

底层的文件关联逻辑、哈希排重机制和缺失标记可以直接复用，但各个板块的审核准则、财务指标红线与信息披露源必须各自独立。查询端可以给使用者一个统一的搜索框，但在数据底座里，不同市场的审核逻辑绝对不能混成一锅粥。

再往后，案例库引入了上市公司再融资。创业板再融资首批收录了 128 个案例（对应 128 份募集说明书与 313 份问询回复，共 441 份文件），项目总量扩到 704 个；随后又补充了 80 个科创板再融资项目，最终汇聚成 784 个项目的完整基座。

首发上市与上市公司再融资，关注点截然不同。再融资更看重募集资金投向、前次募投进度、同业竞争新变动与摊薄即期回报等，如果不在数据模型上对业务类型做物理切分，检索时就很可能把首发上市的审核尺度盲目套用到再融资案例上。

盘子一大，资产层级必须严整。一个项目下有招股书、募集说明书、问询回复等多份异构文件，一份文件又有历次修订版。项目数、文件数、版本数，必须分级记账。下载了一份文件的重报版，不能当成新增了一个案例；手里拿到了一份材料，也不能想当然以为该项目的审核文件已经齐备。

到本文回顾的案例库 2.1.0 基准版本，系统累计沉淀了 2,613 份官方 PDF、约 10.22GB、495,742 页文档，精细拆解出 6,532 个问询问题与 109,843 条关键摘录。这近 50 万页里不全是问询答复，很大一部分是篇幅极其厚重的招股书和募集说明书。各项数字分明，资产边界清晰。

3、法律库用覆盖表确定收集方向

如果说案例库是看历史实践尺度，法律库则是立规矩、定合规底线。它主要覆盖股改沿革、首发上市、再融资、并购重组、股份转让五大核心业务。

光凭个人办案经验去收法条，一定会留下盲区——人总是倾向于反复整理自己熟悉的规则，忽略低频却致命的交叉领域。为此，我把资本市场的 6 个市场板块与 5 类常规业务拉成一张 30 格的核心覆盖矩阵，逐项对齐法源依据。同时把经营者集中申报、外资准入、国资监管等跨交易共性门禁单独立项。

这张覆盖表本质上是一张“欠账清单”：某个业务场景需要哪些法源、已经入库了哪些、哪些还没拿到，程序可以自动核验。它检查条目是否遗漏、法源是否重复、链接文件是否存在、在目标时点是否现行有效。

法律库扩充到 69 部法源时，有 50 部已经抓取了本地快照并完成校验，还有 19 部仅挂着官方在线链接。在目录里它们各占一行，但在系统可用性上是两码事：挂着在线链接，只代表我知道它在哪，随时能去官网看；存下本地快照并通过哈希校验，才意味着我有了一份不可篡改、能做深度解析与版本比对的权威母本。

因此，我把官方 URL、本地原件哈希指纹、结构化解析状态分开标注。这样系统就能诚实地告诉我：哪些法源完全未采集，哪些原件到了但还没切分。覆盖矩阵存在的意义是给数据治理带路，而不是搞形式主义的“虚荣覆盖率”。

到本文回顾的法律库 1.0.2 版本，库内纳入了 86 部官方全文，梳理出 14,408 个独立检索单元与 20,253 个层级节点，完整绑定效力沿革链。它圈定了业务的核心边界，但没人敢轻言“全市场的法条已经被我穷尽”。

4、原件集中保存，缺口单独留下

随着文件数量快速增加，所有原始 PDF 统一录入不可变的底层证据库，依托 SHA-256 内容哈希全局去重。其他分析模块只记录指针和引用，绝不允许同一份几百兆的文件因为版本迭代而在磁盘上反复复制。

哈希指纹是文件的唯一数字身份证。在资本市场里，文件名极不可靠——同一个文件在不同网站可能有十种名字，而名字不同的两个文件很可能只是改了日期的同一份扫描件。只有比对内容哈希，才能确切证明原件的一致性与防篡改性。

搜不到公开问询回复的项目，必须在台账上赫然标记“材料缺失”。在专业研究里，“我没有找到”和“客观上不存在”，是两种完全不同的答案。

把资料收全、把边界画死、把缺口留明，底座才算打好地基。接下来要面对的硬仗是：怎么把几千页堆叠的文字拆开，并且保住它们的内在骨架。

二、读得对：解耦三方证据角色与层级结构无损解析

1、先用小样本把提取边界校准

一份上千页的问询回复，不能只按关键词切段。监管问询、发行人与保荐人和证券服务机构形成的回复、核查程序、专业意见，以及后续补充披露和项目进展，往往穿插在同一套公开材料里。

实践中，问询回复通常由保荐团队统筹，发行人和律师、会计师等证券服务机构共同准备。上交所公开规程明确，发行人及其保荐人、证券服务机构对问询回复的真实、准确、完整承担责任，回复也是发行上市申请文件的组成部分。

能公开披露，说明该轮回复已经进入审核信息体系；某项处理是否足以回应监管关注，还要跟踪后续审核，例如：会不会继续问询、是否需要补充核查、有没有更新披露，以及项目最后能否过会。

因此，案例库要把问题、回复、核查材料、后续问询、披露更新和项目状态连起来，不能在抽出一句“说明”后就结束。只返回某一轮中的一个段落，可能遗漏后续补充与调整，也会让使用者忽略该处理方式成立的事实条件。

我没有一上来就搞全量批处理，而是挑了 6 个标杆案例、40 份文件、4,375 页材料，关起门来打磨解析规则。程序第一版跑出 150 个候选问询单元时，我逐项核查问题的起止边界、回复材料与问题的对应关系，确认核查意见有没有错挂到下一题，排查目录标题有没有被误切进正文。

如果解析规则在小样本上就有瑕疵，放大到几十万页后，成倍泛滥的脏数据会直接搞垮检索层。

我将这些关联信息分为三类：

• 监管问询：交易所提出的审核关注与信息披露要求；
• 本轮回复：发行人与保荐人、证券服务机构围绕问题形成的说明、核查程序和专业意见；
• 后续审核：继续问询、补充核查、披露更新与项目后续进展。

例如，研究第三方回款问题时，检索不能只看某一段中是否出现“第三方回款”“整改合规”等关键词，还要知道它对应哪一道问询、当轮回复采取了哪些核查程序、后续有没有继续追问或更新披露。

在案例库里，我把 6,532 个问询问题按上述关联关系做了实体解耦，各自打上独立字段和引用锚点。模型调阅时，可以看清问题对应哪一轮回复、核查材料和后续更新位于哪里。

问题、回复与后续处理之间的关联必须保留。这个问题挂着哪一轮回复、补充核查了哪些事项、后续是否更新披露、原文在第几页，全部由指针链接。模型拿到线索后，才能回溯到完整的审核过程，而不是停在一个孤立片段上。

2、PDF的排版错误也会带来数据污染

在处理规范性法律文件时，系统必须严密保留章、节、条、款、项的层级树。这就像新房交付时核验户型，要是标牌排版错位，一间独立的房间就很可能被系统识别成走廊尽头的隔断，整套房屋的结构就全乱了。但在实际工程中，极其偶发的排版细节就会让核心法条彻底隐形。

在核验深交所再融资规则时，我就遇到过这样一个怪现象：第三十五条在系统里彻底失踪了。把官方文件调出来逐行比对，才发现问题出在排版上——“第三节”的节标题与“第三十五条”排在了同一行。早期切分程序识别出节标题后，直接把整条内容拼接到了第三十四条末尾。

我重写了标题与条号的行内持续判定逻辑，重新导出了全库 64 部法规。复核通过，第三十五条重获独立实体身份，法源检索单元从 3,576 个修正为 3,577 个。

数字只涨了“1”，但意义非同寻常：这条合规底线在系统里终于有了自己的“门牌号”，能被精准检索、定向引用、与其他规则做交叉印证。

这种结构校验绝不能靠拍脑袋定字数阈值。很多法规里的术语解释或附则，本身就短短二三十个字，强设长度下限会直接把短法条砍掉；而篇幅很长的段落，又常常是几个小条款被错误粘连。条号是否连续递增、结构树是否完整、章节归属是否严密，必须建立确定性的逻辑断言。

3、原件、正文与可查询全文必须分别到位

对于扫描件 PDF，必须先做光学字符识别（OCR）。但只要干过实务就知道，OCR 在金额数字、小数位、百分号以及跨页复杂表格上极易发生字符漂移（把 8 读成 3，把千万读成百万）。所以系统必须强制绑定原始 PDF、哈希校验码与绝对物理页码，任何检索产出都必须能一键拉出原件对照。

Word 同样坑洼密布。文档里肉眼看到的自动编号列表，在 OOXML 底层数据结构里根本不是普通段落字符。如果解析器只机械抓取段落文本，拿到的就会是丢了条款序号的裸句子。再加上网页页脚杂质、PDF 内嵌表格、专业附表，每一类格式都要单独写清洗管道，绝不能拿“提取字符总量”来粉饰太平。

案例库的全文建设是分波次硬啃下来的：1.1 版本完成了 576 份招股书与 158 个案例的 442 份问询回复全文；到 1.2 版本，回复全文扩充到 353 个案例、807 份文件。

到了 2.0 版本，又集中攻坚了 441 份文件的深度解析，把 56,454 页文档打成了结构化全文。注意，这里的 441 份指的是这一个批次完成全文深度解析的文件总数，跟前文创业板再融资首批引入的 441 份文件是两码事，不能混为一谈。

在资产账本上，“项目已登记”、“原件已归档”、“全文已索引”是三种完全不同的工程状态。把这三者撕开记录，系统才能随时暴露真实缺口：哪些企业空有名字还没拿到原件？哪些原件静静躺在磁盘上却还没变成可检索的全文？

4、切成小段之后，还要知道它来自哪里

做专业知识库，绕不开把长文档切碎做 RAG。但这就像把一张处方签剪成碎纸条，单抽出一张上面孤零零写着“每日三次、每次两粒”——字字都对，提取也准确，但到底吃的是感冒冲剂还是剧毒药物，上面全没写。切得越碎，语境丢失得往往越严重。

一段财报文字单独抽出来看：“报告期内，公司研发费用占比为 8.7%。”字面完全正确，但剥离了所属企业名称、报告年度与会计口径，送进大模型那就是纯粹的误导源。法规也是同理：某一特定豁免条款，其适用前提往往藏在三条之前的总则定义里。

前文提到的公司和季度丢失，正是 Anthropic 在 2024 年 Contextual Retrieval 研究中展示的财务检索问题。在其实验里，通过在切片前补齐文档上下文并结合 BM25 检索，top-20 检索失败率从 5.7% 降至 2.9%。

法律大模型评测基准 LegalBench-RAG，则把靶子立得更狠：它不看系统能不能找到一份大文件，而是考察能不能在海量法条中，精准命中真正支撑答案的那个具体细分片段。如果给模型塞了一大堆冗余章节，长上下文不仅推高调用延迟与成本，还会让模型产生“大海捞针”式的注意力涣散与幻觉。

我的工程解法是给每个切片打上刚性的“血缘标签”：哪怕切成只有几十个字的项条款，它的层级树（某部法规/某章/某节/某条）、关联原件指纹、物理页码必须寸步不离。检索时像绣花针一样精准命中，理解时又瞬间把整条枝干还原回它扎根的语境中。

三、找得准：跨越自然语言鸿沟与多通道排名截断治理

1、先确定要找的是哪一种结果

“查涉及收入确认的项目”与“查监管关于收入确认的问询要点”，关键词一模一样，但业务想要的结果完全是两个物种。前者要的是一份申报企业名单，后者要的是具体的提问原文；如果继续追问某家企业是如何过关的，系统则必须下钻到详细答复与底稿页码。

所以，底层查询必须严格区分实体类型：项目主体、问询条目、法规原文、条款单元、物理单页。调用时必须带上市场板块、业务类型和证据属性。如果把目标实体搞混，哪怕搜出了一堆文字吻合的段落，对业务研判也是答非所问。

在案例库里，分析监管审核尺度时，系统会锁死“监管问询”角色字段；而在法律库里，查发文字号用目录检索，查条号用精准索引，只有面对开放式的疑难提问时，才启动正文语义检索。不同入口分司其职，指望一个大一统的搜索框包打天下，在严谨场景下根本行不通。

2、多种检索方式一起用

明确了要找什么之后，接下来就是怎么在茫茫法海里捞出这根针。

很多人以为如今大模型的语义向量检索（Embedding）是万能的，但在法律和监管实务中，单纯依赖向量相似度很容易被华丽的套话带偏。法规讲究字字千钧，发文字号、条款项款、特定的法律概念，差一个字就是两种定性。像“增持”与“减持”、“重大资产重组”与“重组上市”，如果只靠语义向量模糊匹配，召回结果极易漂移。

因此，底层必须让基于精确关键词的传统词法检索与多通道综合排序协同发力。在具体实现中，法律库基于 SQLite 落地，用 FTS5 全文索引快速匹配词法，结合 BM25 算法根据词频和文档长度做相关性打分。这些工具是效率极高的“翻书员”，它们负责把值得精读的条款快速翻出来，并不负责判断法律适用的深层逻辑。

实务中的业务提问五花八门，很多口语化词汇跟法规的法言法语存在天然鸿沟。碰上“减持”这类只有两个字的超高频短词，分词器如果切分不利极易漏检。我在早期版本里引入了正文通配符作为兜底，专门对付容易被分词漏掉的高频短词。

在底层，系统将法规目录、条款编号、正文 BM25 全文和业务登记别称四路召回的候选统一归集，进行去重和加权排名。这里采用的是倒数排名融合（Reciprocal Rank Fusion, RRF）机制：它不直接对比各路算法绝对分值的高低，而是依据各候选在不同通道里的相对位次做加权折算，让多路都能排进前列的条款脱颖而出。

这套逻辑也是踩坑踩出来的。早前我曾设过一个粗暴限制：“每部法规最多预留前 8 条”。结果发现这种局部提前截断非常危险——某部核心法规排在第 9 位的关键条款，其重要性可能远超另一部边角法规的第 1 位，却被硬生生挡在门外。后来改成先全局汇聚融合、统一排序，再在最后关口执行总容量截断，候选池的公允度才真正提了上来。

3、提示词不同，查询结果也会不同

在实务落地中，我很快撞上了另一堵墙：业务人员习惯用自然大白话提问，而法规数据库里全是冷峻规范的法言法语。比如业务人员问“大股东股票质押爆仓了怎么披露”，法规正文里写的则是“控股股东股票质押违约处置与信息披露义务”。如果直接用大白话去撞库，检索结果必然大面积漏检。

为了看清这种“表述鸿沟”对检索造成的实质杀伤力，在法律库 0.7.2 的基线测试里，我做了一组严格的对照实验：一组直接喂原始业务提问，另一组先由前端把业务提问提炼改写成两组结构化检索式，再执行合并查询。底层数据库和测试题集完全一样。

实验结果对比很说明问题：

- 法规层面的前十项命中率（Hit@10），从原始提问的 27.85% 提升到改写后的 98.73%；

- 必要法源的完整召回率（Recall@10），从 25.00% 跃升至 90.74%；

- 但是，关键具体条款的前十项命中率（Key Provision Hit@10），仅仅从 7.97% 提升到了 50.20%。

这组实测数据说明了双重规律：把业务白话改写成规范的专业检索词，确实能让系统轻而易举锁定“这是哪部法”；但这绝不意味着“解决问题所需的那几条具体法条已经被你找齐了”。

上述指标基于当时固定的 79 道具有明确法源映射的基准题集测得。不能把它当成开放问题的万能答复率，更不能把提问改写带来的工程红利吹成“底层模型检索能力突飞猛进”。这组数据明确了后续路径：前端要强化意图解析与改写，后端则必须留出顺藤摸瓜逐层精读法条的通道。

4、全局稳定性，比单词查询完整性更重要

法律库 1.0.1 版本的专项筛查中，有 9 道宽泛业务查询未能找全预期条款，累计出现 54 处缺失。逐项排查下来，原因非常典型：28 处是排名截断，26 处是词面未命中。

排名截断，意味着条款顺利进入了召回池，但最终得分排在单次返回上限（比如 Top 20）之外；词面未命中，说明提炼出的词法特征根本没能把目标条款从浩瀚的文本中勾出来。这是两类性质截然不同的系统故障，必须分别施策，绝不能笼统用一句“检索不够准”含糊带过。

最生动的案例是一项关于国有资产转让的核心条款：在一次宽泛查询中，它的综合评分微跌，刚好从第 20 位滑到了第 21 位。

这就像是一个限额 20 人入围的商务招投标，第 21 名哪怕只差 0.01 分，在打印出来的公示大榜上也彻底没了踪影。单次接口默认只吐出前 20 条，于是它被无情截断。法条在库里安然无恙，物理关系也完好无损，但对调用端来说它就是“消失”了。

当时我一度想通过调大某些特征权重，强行把它顶回前 20。但在回归测试中，这个改动立刻引发了连锁反应，导致其他几十道标准测试题的排序严重退化。我最终放弃了这次权重调整。

工程上的教训是深刻的：永远不要为了修好一个眼前刺眼的用例，去牺牲全局基线的稳定性。检索给出的永远只是一份带截断线的线索清单，它负责把研究引导到正确的靶区，后续的证据闭环，必须交给真正的阅读机制去完成。

四、查得全：攻克游标深度分页与法源上下文顺读机制

1、第一页正确，后面几页却可能被直接截断

在投行业务里做案例归纳，如果只是随手挑两三个同类参考，搜出来的第一页大概率够用。但如果承接的是严肃的课题——比如“北交所所有涉及研发费用归集问询的企业分布”——那就必须完整覆盖整个目标样本池。只读搜索首页，极易以偏概全，把排序靠前的局部样本误判为行业全貌。

大模型的上下文窗口和 API 接口吞吐都有物理极限，深度分页与游标（Cursor）机制是绕不过去的底座。分页不能只是机械地翻页，核心是接口必须诚实透传元数据：总命中条数、当前游标位次，以及后续是否仍有未读数据。多页拉取合并后，必须做到绝对的零重复、零遗漏。

案例库 1.6.1 版本在 4 个查询入口、12 道业务问题、累计 48 次调用检查中，针对此前大结果集偶发截断、调用端吃不全的问题做了底层治理，实现了 48/48 的全量通过，固定测试集的完整消费率从 95.83% 提高到 100%。

在 1.6.2 版本的专项压力测试中，针对“第三方回款”拉出的 218 条复杂结果集，系统通过连续 25 次游标无缝翻页，把全部数据完整取回，重复率与遗漏率均为零。把 218 条、25 次翻页、零重零漏白纸黑字记下来，大家才知道这个“100%”到底扛住了什么考验。

2、从搜索结果继续读到全文

法律研究对“查得全”的定义更为苛刻。初筛往往只能命中一条法条，甚至只是法源的标题。但在法律推导中，这一条款极大概率依赖总则里的术语界定、上级章节确立的原则，或是文中明确援引的“第某条除外”。

如果只靠断章取义的零散搜索，模型极容易给出看似严谨实则犯了“除外情形”的荒谬意见。我专门在底层保留了法源的顺序阅读通道：模型靠关键词定位到关键法条后，可以沿着法源结构树，顺畅拉取该章、该节乃至关联条款的完整原文。

针对前面提到的那 9 道初筛漏掉关键法条的宽泛查询，我跑了一轮“线索初筛 ＋ 全文顺读”的协同测试。实测证明，原先因为排名截断掉出视野的法条，在顺藤摸瓜的连续阅读中全部被完整召回；在全部 88 道适用性测试题中，共有 87 道取得了形成判定所需的完备证据链，上下文获取率达到 98.86%。

必须看到，这里依然留下了 1 处未覆盖的缺口；98.86% 衡量的也仅仅是“上下文到底拿全了没有”，绝不能偷换概念成“模型对法律问题的回答准确率达到了 98.86%”。把检索、读取和业务判断的指标死死拆开，系统迭代才有清晰的抓手。

专业知识库绝不是在用户提问时，机械地把上百页法条或整个招股书一股脑塞进上下文窗口。合理的信息供给一定是阶段性的：先找线索，再查关联，顺着逻辑推导动态请求增量材料。

3、打薄控制层，给AI更多的判断自由

在案例库 1.7 到 1.8 版本，为了防止大模型在长链条调用中四处乱窜、耗尽 Token（大模型处理文字时的基本计量单位），我在底层查询工具里设了几条硬编码限制：

1. 强制收敛到预设的 6 个标准业务主题；
2. 强制提取唯一的规范专业短语；
3. 一次研究任务，底层工具最多只能被调用 3 次。

这套“保姆式”机制在当时由 24 道封闭式题目构成的测试集上，取得了 24/24 的满分。但这种虚假的确定性，一进真实深水区就碰得粉碎。

这就好比派员工去全城巡查连锁商超的铺货情况，却死板规定只给报销 3 站路的公交车票。

真实的案子从来不按剧本走：比如要研究“北交所消费品企业的研发费用问询情况”，第一步要遍历库内全部北交所 IPO 企业名单。全集整整有 325 家，光把这批企业名单完整拉取完就需要翻页 9 次——这还没开始按主营业务筛选消费品，更没开始逐案深挖多轮问询答复。刚坐到第三站，系统就强制宣布“调查结束”，连大门都还没迈进去。真实研究充满动态调整：一个词搜不到要换行业黑话，一轮问询答复不充分要追溯下一轮，核查有疑问要调阅底稿说明。

所以在 2.1 版本中，我最终取消了这套限制：不再强制业务主题与规范短语，也去掉了单次任务最多调用 3 次的上限。

这次调整的实质，是把控制层从“替模型做判断”转为“为模型守住边界”。早期，我把需求理解、主题分类、检索词选择、任务拆解、调用次数和研究路径写进工具，希望用厚控制层补足模型的不足。

随着外部 Agent 在真实任务中已经能够根据已有材料拆解问题、改写检索表达、规划多轮调用，继续把这些判断锁在工具层，反而会限制研究。

因此，我现在让 Agent 负责理解用户问题、拆解任务、组织任务级上下文，并决定下一次查什么；工具层只保留不能由模型自由决定的部分：资料角色、检索入口、版本与页码定位、单次容量、错误与截断状态，以及输出结构和研究协议。

五、用得合理：依托双轨分工与研究协议驱动事实要件闭环

1、案例和法规，分析逻辑并不相同

实务中我们总希望输入一个问题，案例和法条同时蹦出来。但在系统底层的数据架构上，我选择把两者彻底分立。

案例库看的是“实践类比”：比较事实特征的异同、关注审核尺度的高低、看同行踩过的坑与中介的补救动作；

法律库看的是“要件适用”：逐条核验主体资质、前置程序、法定要件、除外条款与法律后果。

如果强行混在一个库里，异构资产的维护和检索逻辑就会陷入混乱。物理分立、业务结合：两个库各自保持最纯粹的数据形态，在面对具体复杂课题时，再由上层推导链路进行跨库调度与交叉验证。

法律库在早期也曾试探性收录过 6 张本地案例卡，后来被我全部剔除，连同相关接口一并拔掉。所有的判例检索老老实实交由专业的 IPO 案例库承担，法律库守住自己作为规范性依据的纯粹性。

2、把一个业务问题接到具体证据上

上一章用“北交所消费品企业的研发费用问询”说明了怎样把 325 家企业的全集名单与多轮问询完整拉取下来。但把这几十万字底稿搬到桌面上，并不等于研究就完成了。

真正的专业考验才刚刚开始：面对这些繁杂的底稿，AI 到底该如何像一个资深保代或专业律师那样，把案件事实、审核实践与法定规则严密咬合起来？

以这个课题为例，展示一套合乎专业逻辑的推导闭环是怎样运转的：

1. 样本圈定。先拉出北交所企业全集，按业务实质筛选消费品企业，把筛选标准记录在案，绝不拿搜索结果前几名来凑数。
2. 问询下钻。逐家定向检索研发费用相关问询，严格按角色拆分：交易所关注什么（是研发人员认定、工时归集，还是研发费用资本化？）、发行人怎么自陈、保代与会计师履行了哪些走访和抽凭程序，追踪到第二轮、第三轮是否有反复交锋。
3. 横向比对。同行的处理经验绝不能直接套用——两家企业可能都写“工时系统自动打卡归集”，但一家有软硬件绑定的真实系统记录，另一家可能只是补签的纸质台账。案例研究的精髓，恰恰在于找出这些决定合规生死的“事实差异”。
4. 法规映射。一旦涉及研发费用加计扣除、高新技术企业认定或上市标准衡量，立刻切入法律库，调取现行有效法规与对应时点的具体条款，逐项核对除外情形。
5. 证据闭环。输出一份逻辑自洽的分析备忘录：梳理同类企业共性关切、提炼具备参考价值的实践路径、明确指出本项目不可照搬的实质差异，并开列出本项目尚待补充核查的事实清单。每一个结论旁边，必须打上问询编号、原文页码与法条项款。任何第三方拿到底稿，都能沿着这条线索原路复核。

知识库的价值，就体现在这条穿透到底的证据链条上。搜出一段话只是起点，让事实与规范在推导中严密咬合，才算真正进入了专业判断。

3、为什么我撤掉了预先整理的规则卡

在法律库早期，除了官方原文，我还提炼了一套“规则卡”（从 18 部法源 14 张卡，一路增加到 69 部法源 36 张卡）。规则卡用大白话提炼常见问题结论，试图让模型一查就秒懂。

但这很快成了系统的负担。

法规一修订，规则卡就成了可能失效的隐患，带来沉重的双重维护负担；更关键的是“人工摘要带来的语义裁剪”——提炼者在写卡片时，为了追求语言凝练，往往会顺手抹掉适用前提、豁免例外或附表里的严苛指标。

面对真实交易，少看一个“除外情形”，合规结论就会彻底南辕北辙。2026 年 8 月 25 日，我下定决心，废除了全部预加工规则卡及其生成工具链，把 30 个覆盖单元重新直连官方现行全文，精简接口。经 31 项回归测试，系统直接在法规原文中定位条款。

这一刀切掉了所有二手总结。做专业级知识库，宁可让模型直接面对严肃晦涩的官方条文，去老老实实逐条核对法定要件，也绝不给它喂经过人为脱水、可能缺斤少两的二手料。

4、把分析步骤随材料一起提供

拿到法条只是拿到了砖瓦。为了防止模型拿到法条后凭空臆想，我在法律库的 MCP 接口（Model Context Protocol，连接模型与外部工具的标准协议）下发数据时，动态捆绑了一套标准的《六步法律研究协议》。

这套规程时刻提醒外部模型：

1. 别急着给结论，先讲清楚拟判断的法律关系是什么；
2. 拆解事实三要素：主体资质、具体行为、时序节点；
3. 核查现行有效规则与援引定义；
4. 调阅历史案例比对实践尺度；
5. 必须强制排查相反依据与反例；
6. 最终输出合规路径的成立要件与未决风险清单。

协议是方法，法源是材料。方法随数据下发，约束模型的思考路径，但方法本身决不上位污染法规库。遇到事实不清，主动向用户追问；遇到证据冲突，老老实实展开论证。这才是专业工作的本相。

六、更新后仍可信：健全时点效力穿梭与六层量化评测体系

1、每次更新都要说清楚改变了什么

在软件工程里，大家很习惯轻巧地宣称“我们昨晚更新了一个大版本，性能优化了”。但在金融和法律等严肃业务中，这种模糊的“升级”往往是灾难的开始——业务人员一用，发现前天还能查到的法条今天找不到了，或者原本稳定的上市标准突然跳了分类，团队对系统的信任度会瞬间瓦解。

专业系统一旦上线，必然经历资料追加、解析重写、检索调优与方法升级。出了状况，第一要务是能把改动精确切片，说清楚这次更新到底动了哪一层。

案例库 2.1 版本沿用了 2.0 的底层数据库，核心动刀的是查询层的 Agent 交互逻辑；法律库 1.0.2 与 1.0.1 数据库物理文件一模一样，升级的是研究协议的动态封装。

原始凭证归原始凭证，运行时包归运行时包，维护台账归维护台账。日常对外只开只读接口，任何版本变动必须在沙盒候选区完成全量验证，再做原子化热切换。上线后，必须强制核对客户端当前调用的真实版本指纹，绝不能把“代码推上去了”等同于“生产环境已经生效”。

有了这套严谨的工程审计账本，知识库才不会变成谁也看不懂、改不动的黑盒子。

2、有些更新，是再次回到原始材料复核

2026 年 8 月，我抓了一次历史存量治理，对已入库的 576 个 IPO 案例的上市标准归类做全量重审。

• 451 个案例凭已有结构化字段即可直接确认；
• 125 个案例存在歧义，需要调出招股书原文逐字复核；
• 其中的 20 个案例，更是要调出三年一期的财务明细重新拉表重算；
• 最终，对 4 个历史分类做出了精准修正。

这是一次极其笨拙的苦工：先写脚本做一致性碰撞，筛出存疑项目，然后人工介入调原文、重新计算指标、修正台账。修完这 4 处，我不会对外宣称“案例库全面更新至最新一天”——局部修复就是局部修复，它没有向前刷新全库的数据时点。把修复动作和时间线分清楚，是对专业最起码的敬畏。

历史法规更是一本时序账。核查多年前的一起历史增资合规性，必须严格适用该交易发生时的现行法规，而不是拿着今天的新规去套当年的行为。法律库因此完整保留了发布、生效、失效与废止替代链条，支持时点穿梭查询。代码可以追求最新版，但法律资产必须为历史留底。

3、结构修正以后，旧引用也要跟着检查

法律库在 1.0.1 修复了 Word 自动编号并把条款粒度细化后，测试账本上同时出现了旧基线的 56/100 和新断言的 51/100。

外人一看以为分数退步了，实际上是因为评测的标尺收紧了：以前只需召回包含多项规则的宽泛大段就算得分；切成独立法条后，断言要求必须精准命中支持结论的每一条细分项款。条件严苛了，分数自然变动。

但绝不能借此掩饰系统本身的缺陷。前述 9 道宽泛查询里的 54 处缺失，依然作为真实缺陷钉在账本里：28 处排名截断、26 处词面未命中，清清楚楚。同时，在顺读补充测试里，也诚实保留了那 1 处尚未覆盖的缺口。

不把指标打扮得光鲜亮丽，不抹平真实瑕疵，下一次重构才知道往哪使劲。

4、分数要对应正在检查的能力

评估一个专业知识库的成熟度，我会把评测口径拆成六个层次，它们对应前面六项能力里可以被量化的那部分：

前面五层技术指标哪怕全部打满分，也推导不出“大模型写出的法律或财务备忘录必然正确”。业务判断需要综合事实完备度、商业常识与规范解释，是独立的最后一个层次。

把这六层分拆开，当终端报告出现纰漏时，排查就有序得多：是原件漏了，还是解析粘了？是检索截断了，还是模型自己产生了幻觉？笼统谈一个“98% 准确率”，在实战排障中毫无意义。