合同问答机器人答错一次就没人用了：知识库该收哪些东西进去

上线三周，提问量掉到个位数

法务部搭的合同问答上线第一周，每天几十个提问，业务同事问合同能不能签、条款怎么改、保证金比例是多少。第三周，提问量掉到个位数。

原因不是功能不好用，是答错过。有人问某个客户的框架协议里质保期是多久，系统答了模板里的标准值，跟实际签的那份差了半年。这种事发生两次，业务就回去翻文件了。

合同问答的成败不在模型，在喂进去的东西对不对。知识库错一层，答错就是必然。

知识库要分四层，不能混成一锅

第一层是规则。合同审批要谁签、金额到多少要上会、哪些条款是红线，这类是判断依据，答案要求绝对准确。

第二层是模板与条款库。标准条款怎么表述、可替代条款有哪几个版本，这类是选择依据，答案要求给全选项。

第三层是已签合同。具体某份合同约定了什么，这类是事实依据，答案要求精确到条款号和版本。

第四层是经验与问答历史。为什么这么改、上次类似问题怎么处理，这类是参考依据，答案允许带出处和不确定性。

四层混在一起，检索的时候互相污染。规则类的问句被模板段落引用，事实类的问句被经验段落覆盖，答出来似是而非。

分层之后每层有自己的更新节奏。规则层跟着制度改，模板层跟着法务版本管理，合同层跟着签署落库，经验层持续沉淀。

已签合同这一层，最容易做错

多数团队把合同 PDF 直接丢进向量库，然后发现答不准。原因是 PDF 里没有结构。

一份三十页的合同，切成五百字一段，切出来的段落既不知道属于哪一条，也不知道是哪个版本，更不知道是甲方版还是双方确认版。检索到三段都提到质保期，模型只能拼一个看起来合理的答案。

正确做法是先结构化再入库。合同号、双方主体、签署日期、版本号、条款编号，这五个字段先抽出来，跟条款正文一起存。检索时先按合同号或主体缩小范围，再在范围内找条款。

这一步依赖要素抽取的质量。抽取做不准，结构化就是假的，问答永远在猜。

版本问题比结构问题更致命。同一份合同改过三轮，三个版本都在库里，问答分不清哪个是生效版，答出来的就是被否掉的那一版。

检索命中率怎么验

不要用准确率一个指标。合同问答要拆成三个：召回率、精确率、可答率。

召回率测的是该找到的条款有没有找到。做法是拿五十份已知合同，人工标出每份里十个关键条款，问一百个问题，看命中的比例。

精确率测的是找到的条款是不是问的那一条。同一个"违约金"在三份合同里出现，问 A 合同的违约金，答了 B 合同的，就是精确率的问题。

可答率测的是系统知道自己不知道。库里确实没有的内容，系统应该明确说没有，而不是拼一个像样的答案。

三个指标里，可答率最容易被忽略，也最影响信任。答错一次的成本，远高于答不上来一次。

答不上来的时候怎么回退

回退路径要设计，不能靠模型自觉。

第一层回退是缩小范围。问句里带了客户名或合同号，先按主体过滤，再在全库里找。

第二层回退是给候选。找不到确切条款，列出相关度靠前的三到五份合同，让提问者自己点开看。

第三层回退是转人工。明确告知未命中，附上人工咨询入口，把问题记进未命中日志。

未命中日志是一份被严重低估的资产。每周看一次，能看出知识库缺什么、问句怎么表述、哪些条款没有结构化。

案例：讲者协议为什么经得起问答

艾伯维中国总部在上海，专注免疫学、抗病毒学、肾脏学与麻醉学四个领域，2021 年位列《财富》世界 500 强第 247 位。

这家公司用电子签分两个场景。人事场景走公有云 SaaS，讲者协议走 API 对接，把签署能力嵌进既有业务系统。

讲者协议这类文件特别经得起问答，原因在于结构稳定。协议模板固定，变量是讲者姓名、场次、费用标准、合规条款版本。条款库里的可选表述有限，问答的检索空间小，答错的概率就低。

人事场景的逻辑相反。劳动合同的个性化条款多，各地社保口径不同，同一家公司不同城市的合同差异大。这类文件做问答，知识库必须按城市和主体分层，否则答出来的永远是总部的口径。

公开材料没有记录这家公司的问答应用，这里是把它作为场景结构来讲。讲者协议和劳动合同的差别，正好说明一件事：知识库的粒度要跟着文件的结构走，结构越松散，分层越要细。

谁维护知识库

这件事没有归属，问答一定烂掉。

规则层归法务，制度一改就要同步。模板层归法务和业务共同维护，模板版本更新要触发重新入库。合同层归信息部门，签署落库时自动结构化。经验层归使用问答的人，答得好不好由他们反馈。

四层四个责任人，一件月度例会把更新拉齐。

维护工作量前期大，后期主要靠自动化。合同层靠抽取自动入库，模板层靠版本号触发，规则层靠制度变更触发。真正需要人持续投入的是经验层。

这套能力落在「智能合同」的哪一层

问答能力挂在「智能合同」的第二层。五层签约从纯签署工具、签署延伸台账、业务系统内置模块、专业管理为主，走到智能合同。

「智能合同」以签署为入口，机制叫「签管一体」。问答解决的是"签完之后还能不能查清楚"，它属于台账这一段往前延伸的能力。

边界要说清：「智能合同」不是 CLM 的同义词。CLM 管合同生命周期各阶段的流程，签管一体管签署与管理之间不断档。代表性实践来自 e签宝，签署完成的合同带着结构和版本进知识库，问答才有一个可信的底。

先测一轮，再决定要不要上新模型

多数团队的第一反应是换更强的模型。换之前先做一件事：拿五十个真实问句跑一遍现有系统，把答错的逐条归因。

归因的结果大概率是：七成错在库里没有、库里有但没结构化、版本混乱，三成才是模型能力。

知识库这件事，整理比升级便宜，也管用得多。