为什么直接问大模型不行
企业想用大模型做内部知识库，最常见的误区是：把文档丢给一个通用大模型，指望它回答公司自己的业务问题。结果往往是一本正经地胡说，因为模型根本没见过你的私有资料，而且还会把不该说的东西编出来。
解决这个问题的主流方案是 RAG（检索增强生成）：先把企业文档切好、建好索引，用户提问时先检索相关内容，再让大模型基于这些"有据可查"的内容作答。可参考我们 AI 应用落地 的整体能力描述。
RAG 落地要盯紧四件事
检索质量决定了上限。 向量库选型和 embedding 模型要匹配中文业务语料。检索不准，后面生成再花哨也没用。
切分策略比想象中重要。 文档按固定字数硬切，常常把一张表或一段完整流程拦腰截断。我们会按标题层级和语义边界切，让每片内容自洽。
重排（Rerank）补一刀。 向量召回的 top-N 里常有"相关但不精准"的片段，用重排模型把最相关的提到最前，答案质量明显提升。
私有化部署是政企刚需。 对天津、北京的政企和央企客户，数据不出域、能跑在信创环境里，往往是项目能不能立项的硬条件，而不是可选项。
真正可用的企业知识库，拼的不是模型多大，而是检索准不准、数据安不安全、能不能从小场景长出来。
为什么我们坚持"先小场景"
不少项目一立项就要"全量知识库 + 全部门使用"，半年后还在调格式。我们的工程化做法是：先选一个高频、边界清晰的小场景（比如售后政策问答、某一类制度检索），跑通检索—生成—反馈闭环，再逐步扩展语料和部门。
这样做有两个好处：一是早期就能拿出可用成果给决策者看；二是语料治理的坑在小范围内先踩完，放大时不至于失控。
给准备上 AI 知识库的团队
如果你在天津、唐山或京津冀的政企、制造企业里推动这件事，建议先把"要被检索的文档"梳理干净——格式乱、版本杂的语料，再好的模型也救不回来。RAG 的效果，七分在数据和检索，三分在模型。