企业知识库 RAG 落地，我看到最多的坑不是技术新不新，而是基础工作没做好。 第一个坑：资料没人整理。过期制度、重复文档、不同版本混在一起，模型检索到什么都可能错。 第二个坑：权限没想清楚。不是所有员工都该看到所有文档，RAG 如果忽略权限，会很危险。 第三个坑：只看回答，不看引用。没有引用来源，用户很难信任答案，也很难纠错。 第四个坑：没有评测集。上线前不准备一批真实问题，就不知道系统到底能不能用。 第五个坑：没人维护。知识库不是一次性工程，文档更新、索引重建、错误反馈都要有人管。 我的建议是先选一个窄场景，比如客服内部知识库、HR 制度问答、产品 FAQ。场景越窄，越容易把质量做出来。 RAG 真正的难点是把知识管理、权限、评测和运营串起来。只搭一个技术 demo，离可用还差一截。

向量库怎么选，先别急着追最强。问自己三个问题就够了： 数据量多大？查询量多大？团队会不会运维？ 如果只是小项目、内部工具、数据量不大，pgvector 很香。它和 PostgreSQL 在一起，部署简单，团队也容易理解。 如果数据量更大、检索性能要求高、后面要做更复杂的向量检索，Milvus 这类专门向量库更合适，但运维成本也会上来。 如果团队人少，不想自己管服务，可以先用托管方案。贵一点，但省时间，尤其适合验证产品。 我不建议一开始就把架构做得很重。很多 RAG 项目真正卡住的不是向量库性能，而是文档质量、切分策略、embedding 选择和评测方法。 先用最简单的方案跑通，再根据瓶颈升级。不要为了一个还没验证的知识库，上来就背一套复杂运维。

文档切分没有一个永远正确的大小。chunk 太大，检索回来一堆噪声；chunk 太小，上下文又断掉。 我一般先看文档类型： FAQ：可以按问答对切 产品文档：按小节切 合同/制度：按条款切 技术文档：按标题层级切 代码说明：按模块或函数关系切 不要一上来就拍脑袋设 500 字或 1000 字。更好的办法是拿真实问题测试：用户问一个问题，检索出来的前三个片段里有没有答案？如果没有，先调切分和检索，而不是急着换模型。 还有个细节很重要：保留标题路径。比如“产品手册 > 计费 > 退款规则”。模型看到这条路径，会比只看到正文更容易理解片段位置。 我的经验是，RAG 项目里很多效果问题都不是生成问题，而是切分和检索问题。别把锅都丢给大模型。

RAG 这个词听起来复杂，其实可以先理解成一句话：让模型回答前，先从你的资料里找相关内容，再带着这些内容回答。 一个最小 RAG 流程大概是： 上传文档 → 切分成小块 → 做向量化 → 用户提问 → 检索相关片段 → 交给模型生成答案 它解决的不是“让模型变聪明”，而是让模型有机会基于你的私有资料回答。比如公司制度、产品文档、客服知识库、项目手册，都适合尝试。 但 RAG 也不是万能。文档质量差、切分乱、检索不准、权限没管好，都会让结果变差。 我建议新手先做一个很小的版本：只放 20 篇文档，只支持问答，不做复杂权限，不做多轮记忆。先看检索出来的片段对不对。检索不对，后面生成再漂亮也没用。 RAG 的第一优先级不是模型，而是资料整理和检索质量。这个顺序别反。