去年年中我接到一个任务把公司散落在各个Wiki、语雀、Confluence、甚至本地 Word 和 PDF 里的产品文档、技术方案、运维手册统一管起来做一个能“问答”的知识库。老板的要求很明确——数据不能出内网、不能用 SaaS 服务、要能跟现有的 OA 审批流和钉钉机器人对接。当时我脑子里第一时间浮现的就是 RAG检索增强生成技术加上本地部署的开源大模型花了整整两周时间从零搭起了一套私有化 RAG 知识库系统。这套系统上线后我们技术部 40 多个人日常查资料、写方案、做 Code Review 前的背景调查基本都靠它。今天把完整的架构设计、技术选型、实现细节和踩过的坑整理出来希望能帮到正在做同样事情的朋友。先聊聊我理解的“私有化企业知识库”到底是个什么东西。它本质上是一个对内提供服务的问答系统用户输入问题系统先从知识库里检索相关内容再把检索到的内容交给大模型组织答案最后返回给用户。因为数据和模型都在企业内网所以叫“私有化”因为有“检索”这一步所以叫 RAG因为答案是“生成”的所以用户体验比传统的全文搜索好很多。适合它的场景非常典型新人入职后快速了解公司技术规范、跨团队查找历史方案、运维排查问题时的知识提取、管理层需要快速拿到某个项目的关键结论。不适合它的场景也有高频写入型的业务系统、强事务要求的 ERP 类功能、需要严格因果推理的代码生成——这些你不要强行用 RAG 做。整个项目从需求梳理到上线运行一共花了 14 天。第一周主要在做技术选型、环境准备、架构设计第二周集中在文档数据清洗、切分策略调优、索引构建、问答链路联调和 UI 对接。中间踩了不少坑比如 PDF 解析乱码、表格内容被切碎导致检索命中率低、Embedding 维度太高导致召回速度慢、大模型上下文窗口有限导致长文档回答不完整等等。下面我把每一块都展开讲一遍这个过程中会牵扯到不少具体的参数、配置和代码片段都是我实际测下来能用、可复现的东西。1. 整体架构设计与技术选型1.1 核心思路为什么必须用 RAG 而不是纯微调做企业知识库有一条老路把所有文档整理成 QA 对用大模型做监督微调得到一个“懂公司业务”的模型。这种方案我首先就排除了。原因有三点第一企业文档更新频率很高微调一次要准备数据集、训练、评估、上线的完整流程文档一变就失效根本跟不上节奏第二微调的成本不光是 GPU 算力还有数据标注的人力几十万字的文档整理成高质量 SFT 数据没有两周干不完第三微调之后的模型“只知道自己知道的”对于没见过的内容会一本正经地胡说八道出了问题很难定位是模型的问题还是数据的问题。RAG 的思路是“检索为先”。用户问题进来先在向量库和关键词索引里找到最相关的文档片段然后把这些片段作为上下文拼到 Prompt 里让大模型基于这些片段生成答案。整个流程里大模型只是一个“信息组织器”知识本身存在可以随时增删改查的向量库里。文档更新只需要重跑对应文档的解析和向量化流程不用动模型。这对知识库这种高频变化的场景是决定性的优势。另外一个考量是安全性。用微调方案模型权重里会残留一些训练数据的信息理论上存在被提示注入的风险RAG 方案里模型本身不存任何企业资料所有数据都呆在向量库里权限控制可以做得更细。我们对安全的要求是“数据不出内网”所以本地部署是硬性条件这也决定了模型选型的方向。1.2 模型选型本地大模型与 Embedding 模型的选择逻辑大模型我最终选了 Qwen2.5-14B-Instruct量化成 AWQ 格式之后部署在两张 A10 上。选它的原因有几个。首先是参数规模14B 的模型在 4bit 量化后显存占用约 9GB推理时的显存开销大概占 12GB两张 A10 共 48GB 显存完全放得下而且在 Batch Size 为 8 的情况下生成速度稳定在每秒 25~30 个 token体感很快。其次是中文能力Qwen 系列在中文理解上一直做得不错especially 对技术文档中那种“半文言文半代码”的表述理解得比 Llama 系好很多。第三是生态成熟度HuggingFace 上直接下预量化权重vLLM 一键部署不需要额外写推理代码。Embedding 模型选了 BAAI/bge-large-zh-v1.5。它输出 1024 维向量在中文语义相似度任务上的表现属于第一梯队。之所以不用 OpenAI 的 text-embedding-ada-002 或者智谱的 embedding-2完全是因为私有化要求——模型必须跑在内网服务器上。bge 系列有个很好的特性它针对中文语料做过优化对技术术语、产品名词、缩写词比如“RAG”“CRUD”“LSM Tree”的语义捕捉能力比其他通用模型好得多。后面测试的时候也印证了这一点同样一段“订单超时未支付如何处理”bge 检索出来的片段比开源的多语言模型 embedding 模型要准确得多。1.3 技术栈全景从文档解析到问答界面用到的全部组件整个系统的技术栈我用一张表格列出来后面每一块展开讲模块技术选型说明文档解析PyMuPDF、python-docx、html2text、TikaPDF、Word、HTML、Markdown 全覆盖文档切分LangChain RecursiveCharacterTextSplitter 自定义规则按段落和标题层级切分保留结构信息向量化BAAI/bge-large-zh-v1.51024 维单批 64 条耗时可控向量数据库Milvus 2.4分布式部署支持标量过滤和混合检索关键词检索Elasticsearch 8.11在向量召回基础上做 BM25 召回融合大模型推理vLLM Qwen2.5-14B-Instruct-AWQ支持并发兼容 OpenAI 接口问答编排LangChain 自研 Router判断问题类型路由到不同检索策略后端服务FastAPI统一 API 入口对接 UI 和钉钉机器人前端界面基于 React 的简易页面 Streamlit 原型支持对话、溯源、收藏、反馈权限与审计基于部门标签 接口层拦截不同部门只能检索授权范围内的文档这套技术栈的好处是每个组件都是模块化的换掉任意一个都不会影响整体。比如后续如果觉得 bge 不够好可以换成智源的 embedding 模型只需要重跑一次向量化任务问答编排不用动。反过来如果觉得 Qwen 生成质量不够改成 Baichuan 或者 Yi 也只改 vLLM 那边的模型配置。我比较推荐方案选型时留这种“可替换性”因为大模型技术迭代太快一年前的最佳选择放到现在可能已经不行了。2. 文档处理与知识库构建的细节2.1 文档格式摸底与统一接入方案整个项目最耗时、最容易翻车的环节其实是“文档接入”这一步而不是模型和向量库。我第一天上班就做了一件事把公司内部所有的知识文档汇总统计格式分布结果非常不乐观——PDF 占 40%其中一半是扫描件、Word 占 30%、Markdown 和语雀导出的 HTML 占 20%、剩下 10% 是 Confluence 直接爬出来的页面。最麻烦的是 PDF 里大量是产品白皮书、合同模板、老系统的设计文档排版混乱、有页眉页脚、有多级列表纯文本抽取后满屏乱码和错位。针对这种情况我定了一个原则能转成 Markdown 的不直接处理原格式不能转的用专用解析器逐个击破实在不行的用 OCR 兜底。具体做法是PyMuPDF 负责 PDF 的文本层抽取python-docx 负责 docx 文档的结构化转换html2text 把 HTML 转成 MarkdownTika 作为兜底处理特殊格式和损坏文件。虽然 LangChain 自带了很多 Loader但实际上企业场景里文档格式太杂官方 Loader 面对真实文件时经常会崩不如直接用底层库自己写解析脚本稳定性更高。对了还有一个细节要注意扫描版 PDF 一开始我用 Tesseract OCR效果很差中英文混排几乎识别得七零八落。后来换成了 PaddleOCR效果好了很多中文识别准确率能到 95% 左右。但是 OCR 非常耗资源一个 50 页的扫描件要跑 40 分钟所以能识别文本层的 PDF 坚决不 OCR。最终我把公司文档分成了两个 pipeline一个快速通道处理有文本层的干净 PDF 和 Word另一个慢速通道处理扫描件和历史旧档。这个分层设计帮我省了至少一天的清洗时间。2.2 文档清洗与切分策略保留结构比堆字数更重要文档切分是整个 RAG 系统里最容易被低估的环节。切得太碎语义片段不完整检索出来驴唇不对马嘴切得太长向量化之后语义被稀释而且容易超出大模型上下文窗口。我测试了多种切分粒度最终形成了两级切分方案第一级按文档的标题层级H1/H2/H3做结构切分每个二级标题下的内容作为一个大块第二级在这个大块内部按 RecursiveCharacterTextSplitter 的字符数上限和重叠窗口再切成小块。大块主要用来做摘要和关键词提取小块用来做向量化召回。切分时把标题信息拼在每个片段的前缀里这样模型在回答时能知道这个片段是来自哪一章哪一节回答的准确度会高很多。具体参数上小块我选了 512 个字符大概 300 个中文字符重叠 64 个字符。为什么是这个数字因为 bge-large-zh 对长文本的语义表征能力会随长度衰减512 字符以内语义相对稳定重叠 64 字符可以保证句子不会被从中间硬切开导致语义破碎。还有一个关键点切分后我针对技术文档做了后处理凡是遇到“表 1xxx”“图 3xxx”这类引用就把对应标题和上下文一起拼进片段凡是遇到代码块就单独保留代码的语言标记。这样检索回来的内容对模型来说更容易理解。2.3 向量化与索引构建Milvus 部署与入库性能优化向量化是最简单的一个环节但依然有坑。我刚开始用了默认的 batch_size 去跑全量 10 万多个切片结果发现 bge 模型在 GPU 上推理时batch_size 太小会导致利用率极低速度慢到想哭。后来我把 batch_size 调到 64用 FP16 精度推理10 万条数据大概 2 小时跑完。如果你们文档量更大可以考虑用 vLLM 或者 TensorRT 把 embedding 模型做成服务并行处理速度能再快 3~5 倍。向量数据库我选了 Milvus 2.4理由是它支持标量字段过滤和混合检索这对我后面的权限控制和关键词召回很关键。建集合时我对向量字段设置了 IVF_SQ8 索引类型nlist 设为 1024metric type 为 IP内积。刚开始我用的是余弦相似度COSINE后来发现 bge 官方推荐在检索时也用点积内积因为 bge 模型的向量已经做了归一化内积和余弦结果是等价的但内积的检索速度更快。索引构建完成后单条查询在 500 万向量规模下耗时 8~15ms完全够用。另外我强烈建议在生产环境里把 Milvus 和 etcd、MinIO 分开部署不要图省事装在一台机器上。我一开始图省事把三个服务都部署在同一个 4C16G 的节点上结果索引构建时内存直接被打爆Milvus 容器被 OOM Kill 了好几次。后来拆成三台机器一台 Milvus、一台 etcdMinIO、一台 API 服务跑了一周再没出过问题。3. 检索增强与问答链路的核心实现3.1 混合检索设计向量召回与关键词召回的融合策略纯靠向量检索做企业知识库会遇到一个很典型的问题专有名词、缩写词、代码变量名这类“精确匹配”需求向量召回效果很差。比如用户问“RAG 里的 chunk_size 怎么设置”向量检索很容易把它召回成“RAG 的上下文怎么组织”之类的泛化内容很难精确命中代码文档里具体的参数。所以我做了混合检索向量召回 Elasticsearch 关键词召回然后融合排序。具体实现上我用 LangChain 的 EnsembleRetriever把向量检索器和 BM25 检索器组合起来权重各占 0.5。这个库内部会把两种检索结果按 RRFReciprocal Rank Fusion做融合逻辑很简单每个文档在两个检索结果里的排名倒数相加排名越高分数越高最后按融合分数排序返回 Top-K。这个方案在传统 IR 领域已经很成熟了我在这里只是把它搬到了 RAG 链路里。实测下来混合检索的 Recall10 比纯向量检索提升了约 18%尤其是产品型号、接口名、错误码这类精确匹配场景提升非常明显。融合之后还有一个重排环节。我试了两种方案一种是 bge-reranker-base 做交叉编码重排效果最好但速度慢Top50 重排要 1 秒左右另一种是用规则重排对包含问题关键词的片段加权速度快但效果一般。最后我选了 bge-reranker先混合检索拿回 Top 50再用 reranker 重排取 Top 5虽然多点延迟但回答质量提升很大。RAG 系统里召回是上限生成是下限重排是花小钱办大事的环节值得投入。3.2 大模型服务部署vLLM 启动参数和并发调优大模型服务部署是整个系统里出问题最多的地方。vLLM 是个好东西它把 PagedAttention、continuous batching、量化推理都做进了框架里但用不好照样翻车。我的启动命令长这样简化后vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 32 \ --quantization awq \ --trust-remote-code几个参数解释一下。max-model-len设成 8192因为我们 RAG 上下文通常会给 5 个片段每个片段 512 字符左右加起来大概 2000~3000 token再算上系统提示词和问题本身8192 完全够用。设得再大有意义吗有但代价是显存占用呈二次方增长14B 模型在 8192 上下文长度下已经需要约 20GB kv cache再往上就得牺牲并发了。max-num-seqs是单批最大请求数我设 32实测 20 并发时首字延迟不到 1 秒生成速度稳定在每秒 22 token 左右。gpu-memory-utilization一定要预留 15% 左右的显存给 CUDA 上下文和临时张量设太满会直接 OOM。还有一个 header 必须说一下vLLM 默认不校验 API Key生产环境要做好网关层的 token 校验否则内网被穿透了就是裸奔。我在 FastAPI 层做了简单的 JWT 校验每个用户拿自己的账号密码换 token请求时带在 Authorization header 里。3.3 问答编排与上下文管理如何拼好 Prompt 并控制幻觉问答编排这一层是 RAG 系统能不能答得好的“临门一脚”。最基本的 Prompt 模板长这样你是公司知识库助手请根据以下资料回答用户问题。 资料内容来自公司内部文档仅供内部参考。 如果资料中没有提到答案请直接回答“资料中未找到相关内容”不要编造。 资料 {context} 问题{question}这里面“不要编造”四个字是我刻意加的。LLM 生成时有个坏毛病检索到的内容不够时它会脑补一旦脑补就可能把错误信息当成正确答案输出。加上这句可以显著降低幻觉率。我实际测了一下不加这句话时20 个测试问里有 3 个出现了明显编造加了之后20 个里只有 1 个边界 case效果好很多。上下文管理还牵扯到一个 token 预算的问题。我计算了一下Qwen2.5-14B 的 8192 上下文窗口假设给系统提示词留 300 token用户问题留 200 token剩下 7600 token 全给资料片段。每个切片平均向量化后约 200 token把标点压缩后估算5 个片段就是 1000 token。剩下 6000 多 token 可以放一些额外的“文档标题路径”的溯源信息让模型在回答末尾能自动输出“参考文档xxx”。关于多轮对话我用了 LangChain 的 ConversationBufferWindowMemory保留最近 4 轮问答。但这个方案有个坑历史记录也会占上下文窗口。如果你用户连续问很多轮历史消息把窗口占满了新检索出来的内容反而放不进去回答质量会断崖式下降。我最后做了一个取舍只保留历史问题的简短重写版本用 LLM 把当前问题改写为包含历史上下文的问题而不是保留完整对话记录。这样既保留了多轮语义又控制了 token 开销。3.4 权限控制与审计私有化部署必须解决的数据隔离问题私有化 RAG 和公有云 RAG 最大的差异就是权限控制。老板要求不同部门只能看自己部门相关的文档但大模型本身并不知道你的权限体系所以必须在检索阶段就做数据隔离。我的做法是在文档入库时给每个切片打上部门标签如“tech”“hr”“finance”Milvus 集合里加一个department标量字段查询时通过expr: department in [tech, product]做标量过滤。这个方案有个隐患如果用户用跨部门的问题比如“新员工的入职流程”可能技术部门文档里提到了 HR 部门的内容但按权限过滤后就检索不到回答就会不完整。我为了解决这个问题把部分跨部门常用文档打上了“public”标签允许全员检索。这类文档比例大概控制在 5% 以内既不影响权限隔离又保证了基础问答体验。审计方面我在 FastAPI 层做了操作日志每次请求记录用户 ID、问题、检索到的文档 ID 列表、生成的回答、耗时。这些日志通过 Elasticsearch 存储方便事后追查“既然你回答了这个内容为什么你有权限”这一类问题。对于金融、医疗等行业这一步基本是合规刚需建议一开始就做好。4. 从开发到上线的完整实操记录4.1 分阶段推进的时间线两周做了哪些事整个工期 14 天我大致是这样排的第 1~2 天梳理需求文档明确范围先做技术文档库再做产品文档库确认软硬件资源两台 A10 GPU 服务器、一台 16C64G 的 Milvus 节点、一台 8C16G 的 API 节点。第 3~4 天搭建基础环境部署 Milvus、Elasticsearch、vLLM、FastAPI 框架。第 5~6 天写文档解析脚本清洗第一批 500 份技术文档做切分和向量化。第 7 天跑通最小闭环——用户输入问题经过混合检索得到 Top 5 片段送给 Qwen 生成答案并返回。第 8~9 天调优检索效果引入 reranker对比纯向量、混合、混合重排三组召回效果。第 10 天做多部门权限过滤和审计日志。第 11 天开发和测试 React 对话界面。第 12 天对接钉钉机器人员工可以在钉钉群里直接知识库提问。第 13 天内部测试让 5 名同事试用收集反馈。第 14 天修 bug、文档更新流程跑通正式上线。这个节奏整体是前慢后快的。前几天的慢是为了把基础环境弄稳后面速度提上来是因为有了好的地基改代码、加功能都很快。有朋友问我为什么不用 Dify 或者 FastGPT 这些开源平台直接拖拽配置就行。我的回答是平台型工具确实能快速搭出 demo但企业内部对接 OA、钉钉、权限体系的时候平台反而成了约束——改逻辑要改平台源码升级要等发版。对于这次这种定制化需求较多的项目自研的成本并不比平台高收益却大得多。4.2 知识库更新与文档增量入库的自动化流程知识库搭建完只是开始文档更新才是持续运营的生命线。我们的文档源分散在各个系统的导出目录里我写了一个定时任务每天凌晨 2 点扫描文档源目录计算 MD5 哈希如果发现新增或内容变化的文档自动走“解析 → 切分 → 向量化 → 入库”的全流程。删除的文档在源目录标记为 deleted定时任务会同步把向量库中对应 doc_id 的切片删掉。这里有个容易忽略的细节更新文档时旧切片不能立刻删要等新切片向量化成功写入后再删。否则中间时间段用户来问会召回不到内容回答质量大打折扣。实现上很简单向量化新切片 → 写入 Milvus新 doc_id 加前缀 _v2→ 删除旧切片 → 更新 Elasticsearch 索引。整个过程可以在一个事务脚本里完成虽然不算严格的分布式事务但对这个场景来说足够了。4.3 性能测试与评估命中率、召回率、延迟怎么量化我建了一个 60 条左右的人工测试集每条包含一对“问题 期望命中的文档标题 期望回答要点”。测试集的设计原则是覆盖常见问题类型事实类“密码重置流程是什么”、对比类“A 系统和 B 系统有什么区别”、步骤类“怎么上线一个微服务”、异常类“订单超时怎么处理”。然后我用这个测试集去评估三个指标Recall10检索结果前 10 条里有没有正确答案、Answer Relevance生成的回答和问题的相关程度、Answer Faithfulness回答内容是否完全基于检索到的资料。实测数据是这样纯向量检索 Recall10 是 0.82混合检索提升到 0.93加上 reranker 后基本稳定在 0.95 左右。回答的 Faithfulness 我人工抽了 30 条发现 29 条内容都有据可查只有 1 条模型在衔接句子时稍微脑补了一句整体效果还算满意。延迟方面端到端问答平均耗时 2.1 秒其中检索 300ms、重排 500ms、生成 1.2 秒在钉钉上体感很快用户普遍觉得“像在和一个熟悉业务的同事对话”。5. 两周踩坑总结与避坑清单5.1 文档解析阶段的坑PDF 表格、页眉页脚、扫描件处理的教训我踩过的第一个坑是 PDF 表格解析。用 PyMuPDF 直接抽取 PDF 文本时表格内容会按照阅读顺序被拆散比如“指标名称”和“数值”会被分到不同行检索时非常容易失真。为解决这个问题我试了 pdfplumber 的表格提取功能它能输出结构化行列数据但对复杂合并单元格支持也很有限。最终我的方案是表格类文档优先用源文件Word转换实在只有 PDF 的表格就整表转换为图片配合 PaddleOCR 识别成文本并强制按行拼接。这个方案虽然粗放但实测准确率可以接受。页眉页脚也是个大坑。很多 PDF 每页都有“XX 科技有限公司内部资料”这类页眉切分后每条片段都会带上一段无关文字既浪费向量空间又干扰语义。我的处理方法是在 PyMuPDF 抽取时记录每个文本块的坐标过滤掉页面上方 15% 和下方 10% 区域内的文字。准确性不敢说 100%但对绝大多数排版规整的文档有效。如果你的 PDF 排版特别复杂还是建议转成 Markdown 后再手动清洗一遍。扫描件的问题前面讲到了我再多嘴一句OCR 之后一定要做文本校正比如把全角括号转半角、去掉表意不明的空格和换行。否则向量化会把一个词拆成两段检索效果会肉眼可见地变差。我写了一个规则脚本统一做这些清洗过程不复杂但收益非常大。5.2 检索与生成环节的坑命中率低、上下文溢出、幻觉问题检索命中率低是 RAG 项目最让人头大的问题。我挨个排查了一圈最后发现一半以上问题出在切片质量上。最开始我用固定 500 字长度无脑切导致大量片段是从段落中间切开的语义被拦腰斩断。比如一份“备份方案”文档切出来的片段可能在讲“备份策略”但句子刚写到“数据库恢复时需要注意”就断了检索和生成都受影响。后来改成按 Markdown 标题层级切分后情况立刻好转。上下文溢出问题在人均 8K 窗口的模型上还不严重但我最开始测试过 4K 窗口的 7B 模型几乎每次长文档问答都报“超出最大长度”。我的建议是不要为了省钱选太小的上下文窗口RAG 场景下 8K 起步是底线。另外代码片段仍然是上下文清理的大户如果你的文档库里有大量代码记得在切分后对代码块做行数压缩保留函数签名和关键逻辑删掉注释否则 5 个片段可能直接吃掉 5000 token。幻觉问题我前面提过加了“不要编造”提示但还不够。如果检索片段本身互相矛盾模型照样会挑一个更顺眼的生成答案。我的应对方案是在 Prompt 里加一句“如果资料之间存在矛盾请选择与问题最相关且上下文一致的资料并在回答中标注资料冲突”。这个在回答跨版本文档时特别管用模型会告诉你“文档 A 说 X文档 B 说 Y建议确认最新版本”比以前直接编造一个答案要好得多。5.3 部署运维层面的坑端口冲突、容器 OOM、显存泄漏排查运维层面我踩的坑比较杂但每个都有代表性。端口冲突是最低级的错误Elasticsearch 默认占 9200FastAPI 我用 8000vLLM 又是 8000刚好冲突了。Linux 上改端口很快但容易忽略的是容器里应用即使改了配置健康检查还是可能打到旧端口导致明明服务起来了却永远报“无法连接”。我的排错思路是任何一次端口变更都要同步检查 Docker 映射、Nginx 反向代理、健康检查探针三处配置。容器 OOM 问题出现在 Milvus 和 vLLM 同时部署在一台 64G 内存的机器上。Milvus 的 Knowhere 索引构建时内存峰值是数据量的 2~3 倍vLLM 又会在启动时加载全部模型权重到内存。我最后把 Milvus 和 vLLM 拆到两台机器上并在 docker-compose 里给每个容器加了 mem_limit 和 swap_limit环境安静了很多。这里我建议你不管部署什么都别把多个吃内存的大户放在一个实例里除非你想在半夜三点收到容器重启的告警。显存泄漏问题是最难查的一个。现象是系统跑了两三天后vLLM 的显存占用缓慢上升最终 OOM。排查过程用了 nvidia-smi、py-spy、vLLM 自带的日志统计最后定位到是 vLLM 和我们的 FastAPI 服务之间存在 keepalive 长连接泄漏几十个连接堆在一起导致 vLLM 的路由层爆掉。解决方法是把 vLLM 和 FastAPI 之间的会话改成短连接并设置合理的超时时间我用 120 秒。这个坑如果你在 vLLM 里也遇到过可以去看看官方 GitHub issue类似情况不少。5.4 给即将做私有化知识库的团队最后几条掏心窝子的建议走到这一步你已经把两周的经历全看完了。我最后想说的几条建议每条都是真金白银换来的教训。第一做项目前先统计你的文档格式分布PDF 扫描件超过 30% 的项目工期要按三周排第二先跑通最小闭环再推进优化不要前面一上来就搞权限系统、多轮对话这些锦上添花的功能核心问答都还没通后面全是空中楼阁第三切片质量和清洗脚本值得你花最多的时间去打磨它决定了你检索的上限模型再聪明也救不回脏数据第四评估测试集一定要在项目第一天就建立不然后面改了一个参数你根本不知道是变好了还是变差了。我个人的体会是RAG 项目的前 80% 时间都花在数据准备和处理上模型和向量库反而是最好搞定的部分。虽然过程比较折磨人但看到同事真的在钉钉群里用上了知识库、不再反复私聊问“这个文档在哪里”的时候还是很有成就感的。希望我的这份总结能让你少走点弯路如果有任意一个细节帮到你那这两周就没白熬。