RAG

企业文档接入大模型前，应先处理重复、过期、权限、格式和敏感信息。清洗不是一次性的格式转换，而是建立文档身份、有效性和责任人。

企业知识库的核心不是向量化，而是决定哪些文档有效、谁能看到、何时更新、错误如何反馈。技术栈只能承载治理结果，不能替组织完成治理。

RAG 引用的作用不是让页面更专业，而是让用户核对原文、版本、权限和更新时间，并在错误发生时找到可修订的知识来源。

RAG 切片没有一个通用字数。应先按文档类型、标题结构和业务语义确定完整单元，再用重叠、元数据和评估问题修正。

没有答上的问题能暴露知识缺口、检索失败、权限问题和范围误判。把它们结构化记录，才可能形成知识库的迭代队列和回归评估集。

很多企业知识库 Demo 看起来很惊艳，但一到真实使用就没人愿意用。问题通常不在模型，而在需求边界、文档治理、评测指标和运营机制。

一份尚待真实交付验证的 RAG 需求诊断 v0.1 公开草案：先问清业务、文档、权限、评估和运营，再决定是否进入技术选型。

RAG 评估集不应该凭空编题。更可靠的做法是从客服、销售、内部问答和搜索日志里抽取真实问题，再标注来源、标准答案和风险等级。

知识库上线后需要明确文档负责人、审核、更新、反馈和失效处理，否则检索质量会随着业务变化持续下降。