企业 RAG 最容易被低估的工作，发生在第一次演示成功之后。今天把一批文件导进去，问几个问题，回答流畅、引用齐全，看起来已经很像产品了。可企业里的资料会更新… · @UPing123zzz · TwKit

@UPing123zzz

企业 RAG 最容易被低估的工作，发生在第一次演示成功之后。今天把一批文件导进去，问几个问题，回答流畅、引用齐全，看起来已经很像产品了。可企业里的资料会更新、过期、撤回，员工也会换岗。知识库如果只处理文件怎么进来的问题，后面就会不断积累那些本来不该继续生效的信息。 举个例子当差旅制度刚调整，新旧两版都在库里，员工问住宿上限。系统找到了去年那份文件，数字抄得很准，引用也能点开，但答案对今天这次报销已经不适用。再比如表格被切块后，金额还在，适用职级和地区没有跟着保留。这类错误未必靠换一个更强的生成模型就能解决，因为进入回答环节的依据已经缺了条件。 因此，来源、所属文档、适用对象、生效时间和版本状态，都应该根据业务需求一起设计。用户是在问现在的规定，还是追溯去年某个决定，需要区分清楚。旧版本有时应该保留用于追溯，有时应该退出当前检索范围；如果资料确实冲突，又不能确定谁有效，就把冲突交代出来，别为了输出一个干净利落的答案，替业务部门悄悄作决定。 权限也有同样的问题。源系统里撤回了访问权，不代表检索索引已经同步更新；原文件删除了，也得确认对应的检索条目和切块如何清理。具体机制取决于数据源、索引方案和同步方式，所以交付时需要讲清楚更新延迟、失败处理和核查办法。仅仅在界面上加一个登录入口，离不同用户只能查到自己有权读取的材料还有不少工作。 我更看重的企业知识库，是它能长期回答几个朴素的问题：这份资料从哪里来，现在是否有效，谁能读取，改动后什么时候生效，删掉后还有没有残留。检索和重排当然要优化，但资料的生命周期也得有人负责。否则演示时表现很好的系统，可能随着业务变化，越来越自信地回答已经过时的问题。

曝光 83 · 评论 1 · 点赞 0 · 书签 0