
先把结论甩前面知识库文档要想不坑人核心就一句话——给每篇文档打上生效时间和失效时间两个时间戳再让检索层按时间过滤过期的自动降权或下架。别指望人去手动维护三个月后没人记得哪篇该删。我是去年踩明白这事的。当时公司内部 wiki 攒了快两千篇文档新人搜报销流程,搜出来的第一条是 2021 年那版,早作废了,他照着填,被财务打回来三次。我当时挺无语的,文档系统本身没错,错在没人管时间这个维度。后来我自己折腾了套时间标签的方案,顺手还拿一个零代码搭智能体的平台做了个问答小助手挂在前面,踩的坑记下来,给你避一避。坑 1只有 updated_at没有 expires_at最常见的。大多数文档系统默认带个最后修改时间,然后大家就以为有这个就够了。不够。updated_at只告诉你这篇啥时候动过,不告诉你这篇啥时候作废。一篇 2023 年写的政策文档,你 2024 年改了个错别字,updated_at就刷新成 2024 了,看着特新,内容照样是旧政策。解法:单独加一个expires_at字段,跟修改时间彻底分开。写文档的人必须填,或者按文档类型给默认有效期。我当时的配法大概长这样:文档类型默认有效期到期动作政策/制度365 天下架 通知作者技术方案180 天降权临时通知30 天直接下架长期手册永久仅提醒复核到期不一定删,先降权或者挂个待复核的牌子,给人留个反应时间。坑 2到期就硬删,把还有用的也删了我第一版干过这蠢事——写了个定时任务,expires_at now()的全部物理删除。结果删掉一篇还在被引用的接口文档,第二天三个同事来找我要。过期 ≠ 没用。很多文档过了建议有效期但内容还对,只是没人续期而已。解法:分三档,别一刀切。降权:过期后在检索里把排序权重往下压,搜得到但排后面;软下架:从默认搜索结果里隐藏,但保留直链能访问;归档:挪到 archive 区,需要时还能捞回来。物理删除只留给临时通知那种明确一次性的。判断逻辑也简单:def doc_status(doc, now): if doc.expires_at is None: return active days_over (now - doc.expires_at).days if days_over 0: return active elif days_over 30: return deprecated # 降权,带过期提示 else: return archived # 软下架留个 30 天缓冲,这段时间作者收到通知还能续期。坑 3检索/RAG 把过期文档当真理喂给模型这条是做问答智能体才暴露的。我把文档库接进一个零代码就能配 RAG 的工具,搭了个内部问答小助手,本来挺顺——直到有人问现在的差旅标准是多少,那玩意儿一本正经引用了 2022 年作废的标准答出来,还附了出处,看着特可信。RAG 不管文档新旧,谁向量相似度高就召回谁。过期文档在向量库里跟现行文档长得一样近,模型分不清。解法:把时间过滤做到召回这一层,别等生成完再补救。入库时就把expires_at写进 metadata;检索时先按时间过滤,status archived的直接不进候选;deprecated的可以召回,但在喂给模型前拼一句注意:此文档已过建议有效期;召回结果带上日期,让模型自己在回答里标注时效。我那个小助手改完之后,再问差旅标准,它会说根据 2024 年 X 月更新的文档……,老实多了。配这套过滤其实没写多少代码,拖拽连一下节点、在知识库设置里勾个时间字段过滤就成,我大概花了一下午,大半时间还耗在清洗历史文档那两千篇的expires_at上——这活儿是真枯燥,没有捷径。坑 4到期没人知道,通知石沉大海光有自动下架不够。文档默默降权了,作者根本不知道,等用户来骂才发现。解法:到期前 7 天触发一次通知,推到作者的飞书/钉钉,带上一键续期的链接。关键是别群发——只 文档的 owner,别搞成全员骚扰,不然大家会把通知静音,等于没有。我还顺手让那个问答小助手干了件事:每周一早上自己扫一遍下周要到期的文档清单,生成个列表丢到群里。这种脏活累活交给智能体挺合适,它不嫌烦。一点收尾的实话时间标签这套,价值不在技术多高级,在于把文档会过期这件事变成系统默认行为,而不是靠某个热心同事记着去删。我维护那两千篇的历史负担到现在也没完全清完,大概还剩三百篇expires_at是空的,慢慢补吧。要说缺点也有:刚上线那阵子默认有效期设太短,一堆还有用的手册被降权,被人投诉了一波,后来才把阈值调宽。所以别照搬我的天数表,按自己团队的文档更新节奏调。那个搭问答小助手的零代码工具只是顺手用上的,真正解决问题的还是expires_at这个字段本身。你们的知识库现在怎么管过期文档的?评论区聊聊,我挺好奇有没有更省事的招。模型这块我直接调的 讯飞星辰 MaaS,现成大模型 API,没自己部署算力,省了不少事。