AI 问答库
一句话回答
最低要求是三件事:找得到、读得出、说得清归属。找得到指文档有统一存放位置和检索入口;读得出指不是扫描图片或加密文件,能稳定提取成文本;说得清归属指每份文档有版本、生效日期和可见范围。这三条做不到,换任何模型都答不准。但不需要先建数据中台 —— 把第一个场景涉及的那部分语料治理干净,就足够启动。
下表按企业里常见的几类数据拆开,给出「达到什么状态算可用」的判定标准和责任归属。判定标准写得尽量具体,是为了让它能直接当作立项前的检查清单 —— 每一行都能用一次抽样验证:随机抽 20 份,看有多少条满足。责任归属那一列同样重要:数据治理的活儿绝大部分落在业务方而不是技术方,技术团队既没有权限也没有判断力去决定哪一版制度是现行有效的。这一点如果在立项时不说清楚,项目会在中期卡住。
| 数据类型 | 常见问题 | 达到什么状态算可用 | 谁来做 |
|---|---|---|---|
| 制度、流程、规章文档 | 同一制度多个版本并存、没标生效日期、废止的还在流传 | 每份有唯一现行版本 + 生效日期 + 废止标记,旧版归档不进检索 | 制度归口部门,技术方无权判定哪版有效 |
| 产品资料、技术手册 | 大量扫描件与图片版 PDF、表格结构复杂、型号参数散落在图里 | 能稳定提取成文本,表格结构保留,关键参数可检索 | 技术方做 OCR 与解析,业务方抽检结果对不对 |
| 历史工单、客服会话 | 含大量个人信息、答案质量参差、有错误处置也被记进去 | 完成脱敏,且只保留经人工确认为正确处置的样本 | 业务方筛选正确样本,法务确认脱敏口径 |
| 业务系统结构化数据 | 没有可调用接口、字段含义无人说得清、数据不实时 | 有稳定接口或视图 + 字段说明文档 + 明确的时效口径 | 系统负责人提供接口,业务方出字段口径说明 |
| 内部术语与缩写 | 同物异名、同名异物、缩写在不同部门含义不同 | 有一份术语表,含同义词映射与歧义词的消歧规则 | 业务方牵头整理,随使用反馈持续补充 |
| 权限与可见范围 | 文档没有可见范围标注,全员共享盘里什么都有 | 每份文档标注可见部门/角色,且与检索层过滤条件对齐 | 业务方定边界,技术方在检索层落实 |
在立项评审时逐条过一遍,任何一条答不上来都是风险信号。一、第一个场景涉及哪些文档?能不能列出一个具体清单,而不是「共享盘里那些」。二、随机抽 20 份,有几份能直接提取出文本?低于 15 份就要先安排 OCR 与格式治理。三、这批文档里有没有同一主题的多个版本?如果有,谁能拍板哪一版现行有效。四、有没有个人信息或敏感数据?脱敏口径由谁确认。五、业务同事能不能写出 50–100 条真实问过的问题和标准答案?写不出来通常说明场景还没想清楚。六、这些问题的答案,是不是都能在第一条列出的文档里找到?找不到的部分要么补文档,要么把这类问题移出一期范围。七、每份文档谁可以看?八、这批数据多久更新一次,更新之后系统怎么知道。八条走完,技术方案的大部分不确定性就消掉了。
第一,「必须先建数据中台」是个昂贵的误解。数据中台解决的是全公司数据的统一供给问题,周期长、投入大,而一个 AI 场景通常只需要其中很小的一块。正确顺序是先跑通一个场景、用真实使用暴露出数据缺口、再按需扩展治理范围 —— 反过来做,很可能中台建了两年而 AI 一个场景都没上线。第二,「数据越多越好」同样不成立。把所有历史文件一股脑倒进知识库,只会让检索被大量草稿、旧版本和无关材料淹没,准确率反而下降。更有效的做法是宁少勿滥:只放经过确认的现行有效文档,用得上再加。这两点在项目早期最容易被推翻,因为「先把基础打好」听起来永远比「先跑通一个小场景」更稳妥,但实践中前者的失败率更高。
适用边界
同义问法