企业专属GPT落地指南：RAG检索增强、语料治理与权限设计

做企业专属GPT这件事，我这一年里被问过太多次，问的人从技术负责人到业务部门主管都有。多数人的第一反应是“是不是要拿我们的数据去训一个大模型”，这个理解其实偏得挺远。企业专属GPT的本质，不是从零训一个模型，而是在通用大模型的能力底座之上，叠加三层东西：企业自己的知识、企业自己的表达规范、企业自己的权限边界。它解决的是通用模型在企业内水土不服的问题——不知道内部术语叫什么、不知道流程走到哪一步、不知道某份文件去年已经改过版本、更不知道问问题的人有没有资格看这份文件。适合看这篇内容的人，我大致分三类：手上有数据、有服务器、想自己搭一套内部问答系统的技术同学；想搞清楚这件事到底要花多少钱、多少人力才能落地的产品和管理岗；以及已经被“通用模型答得头头是道但就是不对”折磨过的业务方。下面这些是我从几个实际项目里攒下来的东西，路线选择、参数怎么算、坑在哪，尽量说透。

1. 先想清楚：企业专属GPT到底“专属”在哪

1.1 “专属”的三层含义，别混为一谈

很多人把“专属”理解成单一维度，其实拆开看至少有三层，每层对应的技术手段完全不同。第一层是知识专属，指的是通用模型训练语料里没有的东西：内部的产品型号、项目代号、审批流程、历史工单、技术规范。这一层靠检索增强就能解决绝大部分，把文档切片存进向量库，提问时先检索再让模型基于材料回答。第二层是表达专属，指的是回答的口吻、结构、术语习惯。比如内部把“客户”统称“甲方”，把某个流程节点叫“过会”，对外话术有固定模板，输出要严格是某个 JSON 结构。这一层光靠提示词也能凑合，但当格式要求苛刻、调用量大、提示词长到几百字的时候，微调会更划算。第三层是权限专属，指的是同一个问题，不同岗位的人问出来的答案范围应该不一样。这一层最容易被忽略，也最容易出事——它不是模型能力问题，是系统架构问题，必须在检索环节做过滤，而不是指望模型自己“懂事”。

把这三层想明白，后面的技术选型就不会走偏。我见过一个项目，业务方一开始坚持要微调，聊下来发现他们的痛点其实是“模型不知道去年新发布的制度”，这是纯粹的知识时效性问题，微调反而是最差的选择：训练一次几周，制度一改又得重来。后来改成检索方案，两周上线，文档一更新第二天就能生效。

1.2 哪些场景值得做，哪些场景别浪费钱

不是所有需求都配得上“专属”两个字。立项前拿一张表过一遍，能省掉大量无效投入。

这张表的价值在于帮你砍需求。真实项目里最常见的翻车不是技术不行，是范围失控——一开始说做制度问答，两周后需求变成“顺便把报销、招聘、法务全接进来”，数据质量参差不齐，最后什么都做不好。我的做法是第一个版本只锁定一个部门、一个高频场景、不超过 500 份文档，跑通闭环再横向复制。

1.3 立项前的三个硬问题

第一个问题：数据在哪，有多少，质量怎么样。这个问题听起来废话，但真正去盘的时候会发现，文档散在七八个地方：共享盘、邮件附件、老 OA 系统、某个同事的本地电脑。有的 PDF 是扫描件，有的 Word 里有一半是图片，有的 Excel 表格跨了三个 sheet 才说清一件事。盘完你会对工作量有全新认识，我一般建议先做一轮抽样，随机抽 30 份文档转成纯文本，看能还原多少信息，这个比例基本决定了项目上限。

第二个问题：谁来判定答对了。企业内部问答没有标准答案库，业务专家才是最贵的资源。上线前必须有一个能持续出题、能判分的人或小组，通常 2 到 3 个人，每周投入几个小时。没有这个角色，系统上线后你连“效果变好了还是变差了”都说不清。

第三个问题：延迟和成本的底线在哪。内部知识库问答，用户能接受的等待大概是 3 到 8 秒首字；如果是客服场景实时对话，要求会更严。延迟直接决定你用多大的模型、要不要做量化、要不要上缓存。成本方面，很多人只算推理费用，忘了算人力和运维，实际项目里人力往往是大头。

还有一个土办法特别管用：两周人工可行性验证。挑 100 个真实问题，直接丢给通用模型，人工统计正确率和错误类型。如果正确率已经在 70% 以上，说明知识比较通用，重点应该放在格式规范和引用上；如果只有 30%，而且错的地方集中在内部术语和具体数字，那检索增强的收益会非常明显。这一步花不了多少时间，但能避免后面几个月方向性错误。

2. 数据地基：语料治理决定系统天花板

2.1 语料盘点要带“五个字段”

盘数据不能只数文件个数，要建一张清单，每条记录至少五个字段：来源系统、文件格式、数量级、更新频率、敏感级别。敏感级别我一般分三档：公开（可以给所有人看）、内部（正式员工可见）、受限（特定岗位或项目组可见）。这个字段不是走形式，它会直接变成后面检索过滤的条件，也是权限设计的基础。

盘点时会发现一些典型现象：同一个制度存在 2019、2021、2023 三个版本，而且都放在共享盘里；某个流程文档在 OA 里已经作废，但共享盘那份还在；技术规范有中英文两版，内容不完全一致。这些问题不解决，模型给出的答案会比“不知道”更糟糕——它会自信地引用作废条款。

我一般会加一个生效日期字段，并在入库时做一次版本收敛：同名文档只保留最新版本，历史版本单独存档但不进入检索库。同时保留一个“文档状态”标记，遇到跨版本对比类问题（“新旧制度有什么区别”）才去查历史库。

2.2 清洗这一步，脏得超出预期

PDF 转文本是第一个大坑。双栏排版的文档，很多转换工具会按文本流顺序输出，结果是左右栏内容交错，读起来像天书。表格更麻烦，直接转文本会把行列关系打散，一个三列的表格可能变成一堆孤立的数字。扫描件就更别提，必须走 OCR，而 OCR 对中文标点、表格线、手写批注的还原率很不稳定。

我的处理策略是分类型走不同通道。纯文本类和电子版 PDF 走常规提取，提取后做规则清洗：去掉页眉页脚（通常每页重复出现，用频次统计就能识别）、去掉目录页、合并被硬换行打断的句子、统一全角半角标点。表格单独处理，优先转成键值对或者 Markdown 表格，并保留表头——表头信息在检索时特别关键，一个孤零零的“35%”没有意义，但“某项目验收通过率：35%”就有意义。扫描件先过 OCR，然后必须人工抽检，我通常抽 50 份看准确率，低于 90% 就换工具或者调参数。

举个实际例子，某公司的技术规范文档里有一段：“接口超时时间设置为 3 秒，重试次数不超过 2 次”。转换过程中如果被硬换行切成两段，切分时很可能前半段进了一个块、后半段进了另一个块，检索到前半段时模型只看到“超时 3 秒”，回答就不完整。清洗阶段把这类被切断的句子合并回去，比后面调多少参数都管用。

2.3 切分策略：按语义切，别按字数硬切

切分是很多人随便设个 500 字就完事的地方，但它对效果影响极大。固定字数的硬切会把一个完整段落拦腰截断，导致语义残缺。更合理的做法是按文档结构切：先识别标题层级，在二级、三级标题处断开，保证一个块内部讲的是同一件事；如果某个小节太长，再按段落边界细分；只有在连段落边界都找不到的情况下（比如超长表格）才按字数兜底。

具体参数上，我通常把块大小控制在 300 到 600 字之间，重叠 10% 到 15%。重叠的作用是防止答案刚好落在切口上。这个范围是权衡出来的：块太小，语义不完整，模型拿到碎片答不好；块太大，检索精度下降，因为一个块里混了好几个主题，向量表示被稀释，同时塞进上下文的无关内容也变多，成本和干扰都上升。

还有一个很实用的技巧叫父子块：入库和检索用小块（保证匹配精度），检索命中后把该块所属的大块（比如整节内容）喂给模型生成（保证上下文完整）。这样一份文档要建两套索引，存储翻倍，但效果提升明显，尤其是在“这个流程一共几步”这类需要完整上下文的问题上。

每个块还要带上元数据，这是后面做过滤、溯源、权限的基础：

chunk = { "chunk_id": "doc_1024_sec3_02", "doc_id": "doc_1024", "source": "某流程管理办法.docx", "section": "第三章 审批流程", "effective_date": "2024-03-01", "sensitivity": "internal", # public / internal / restricted "owner_dept": "某业务部门", "content": "……正文……", "prev_chunk_id": "doc_1024_sec3_01", "next_chunk_id": "doc_1024_sec3_03", }

sensitivity和owner_dept这两个字段，是后面权限过滤的抓手，现在不加，以后补就得全量重跑一遍向量化，代价很大。

2.4 向量化与索引构建的关键参数

选 embedding 模型主要看三点：中文效果、支持的输入长度、向量维度。维度不是越高越好，768 维和 1024 维在实际检索效果上差距有限，但存储和计算成本差一截。输入长度要覆盖你的最大块，如果块是 600 字，模型最大长度只有 512 token，超出的部分会被截断，等于白写。

索引方面，大规模场景基本都上 HNSW 这类近似最近邻算法。有三个参数值得记住：M控制每个节点的连接数，越大召回越好但内存占用越高，常用 16 到 32；efConstruction是建索引时的搜索深度，越大索引质量越好但建库越慢，常用 100 到 200；efSearch是查询时的搜索深度，这是运行时可调的旋钮，增大它能在延迟和召回之间做交换，常用 64 到 128。前两个参数建库时定死，第三个可以线上调，所以调优的时候先动efSearch。

单靠向量检索有个通病：对专有名词、编号、型号这类精确匹配不敏感。比如查“XT-2024 型设备”，向量检索可能召回一堆语义相近但型号不同的文档。解决办法是混合检索：向量检索和关键词检索（BM25 之类）各跑一遍，然后用倒数排名融合（RRF）合并结果。RRF 的公式很简单，每个文档得分等于它在各路结果中排名的倒数之和，好处是不用关心两路分数量纲不一致的问题。实测下来，混合检索在内部术语密集的场景里，召回率比纯向量能提高十几个百分点。

增量更新也得提前设计。文档有增删改，不能每次都全量重建。做法是用doc_id做标记，文档更新时先按doc_id把旧块全部删除，再插入新块。这个逻辑看着简单，但如果没在数据模型里留doc_id字段，后面就只能靠文件名匹配，一旦有人改了个文件名，旧块就永远删不掉，检索时新旧内容同时出现，模型就会开始自相矛盾。

3. 技术选型：三条路线怎么选，为什么

3.1 三条路线的成本与效果对照

企业专属GPT的实现路径，说到底就三条：提示工程、检索增强、微调。它们不是互斥的，但主次必须分清。

结论很明确：绝大多数企业场景应该以检索增强为主干。原因是企业知识是动态的，制度会改、产品会迭代、项目会结项，微调把知识固化进参数里，等于给自己挖了一个持续维护的坑。检索增强把知识和模型解耦，文档改了就改一行数据，第二天生效，这个特性在企业环境里价值极大。

3.2 什么时候真的需要微调

微调不是没用，是用错了地方才显得没用。它真正擅长的场景有三类。

第一类是严格格式输出。比如要求模型把一段合同条款输出成固定字段的 JSON，字段名、嵌套层级、枚举值都有硬性要求。提示词也能做，但你得写几百字的格式说明，每次调用都烧这些 token，而且长提示词下模型偶尔会漏字段。把几百条“输入-标准输出”样本拿去微调，模型会把格式内化成习惯，提示词可以缩到一句话，稳定性和成本都改善。

第二类是领域语言风格。有些企业的对外回复有固定腔调，比如必须以“您好，关于您反馈的问题”开头，必须避免某些表述。这类风格迁移微调效果比提示词稳。

第三类是任务型小模型替代。比如工单自动分类、意图识别、实体抽取，这类任务用一个大模型跑成本高、延迟大，用一个 1B 到 3B 的小模型微调，效果接近甚至更好，推理成本能降一个数量级。这是我认为微调性价比最高的用法。

反过来，千万别指望微调让模型“记住”大量事实性知识。参数里能装下的东西有限，而且装进去之后你没法更新、没法溯源、没法做权限隔离。我见过一个团队花了两个月把几千份文档微调进去，结果问“某制度第五条怎么规定的”，模型答得似是而非，还编了个条号。这不是模型不行，是路线选错了。

3.3 显存怎么算，别拍脑袋买卡

选型绕不开算力估算，这里给两个能直接用的算法。

推理显存大致等于模型权重加上 KV 缓存。权重部分是参数量乘以每个参数的字节数：FP16 每参数 2 字节，INT8 是 1 字节，INT4 是 0.5 字节，实际还要乘 1.1 到 1.2 的额外开销。一个 7B 模型 FP16 大约 14GB，乘 1.2 是 17GB 左右；量化到 INT4 大约 4GB 出头。KV 缓存跟上下文长度成正比，公式是 2 乘以层数乘以隐藏维度乘以序列长度乘以并发数乘以字节数。7B 模型隐藏维度按 4096、层数按 32 估，序列长度 4096、并发 4 的情况下，KV 缓存大概是 2×32×4096×4096×4×2 字节，约 8.6GB，这个数字不小，很多人估显存时漏掉它，结果是单机能跑通但一并发就 OOM。

LoRA 微调显存比全量微调省得多，因为优化器状态只针对低秩矩阵。经验值是 7B 模型用 LoRA、序列长度 1024 到 2048、batch 设为 1 加梯度累积，单张 24GB 的卡能跑起来；13B 建议 40GB 以上；再大的模型就得考虑参数高效方案组合或者多卡。这里说的只是“能跑”，实际训练时间还要看数据量和轮数。

我把这套估算整理成一句口诀：先按 FP16 算权重，再加 KV 缓存，再乘 1.2 的安全系数，最后看卡够不够。算完如果紧张，优先考虑量化或者换成更小的模型，而不是硬上。

4. 实操落地：把整条链路搭起来

4.1 目录结构和依赖分工

一个最小可用的项目，我习惯分成五块：data/放原始文档和清洗后的中间产物，index/放向量库和关键词索引的持久化文件，pipeline/放清洗、切分、入库的脚本，serving/放检索和生成的在线服务，eval/放评测集和跑分脚本。这样分的好处是离线任务和在线服务互不干扰，清洗脚本可以随便重跑，不影响线上。

配置文件单独抽出来，把模型路径、向量库地址、检索 top_k、温度、最大输出长度这些集中管理。我用过的项目里，参数散落在代码各处的，后期调优基本靠猜。

4.2 检索链路的完整实现

下面这段是检索和组装提示词的核心骨架，去掉业务细节后可以直接参考：

def answer(question, user): # 1. 查询改写：把口语化问题补全成适合检索的形式 queries = rewrite_query(question) # 返回 1~3 条改写结果 # 2. 混合检索：向量 + 关键词，各路取 top_k vec_hits = vector_search(queries, top_k=20, filter=build_filter(user)) kw_hits = keyword_search(queries, top_k=20, filter=build_filter(user)) # 3. RRF 融合 fused = rrf_merge([vec_hits, kw_hits], k=60) # 4. 重排：用较小的交叉编码模型精排，取前 5 top_chunks = rerank(question, fused[:30], top_n=5) # 5. 组装提示词，强制带编号引用 context = "\n\n".join( f"[{i+1}] 来源：{c['source']} / {c['section']}\n{c['content']}" for i, c in enumerate(top_chunks) ) prompt = build_prompt(question, context) # 6. 生成 + 后处理（引用校验、敏感词兜底） raw = llm_generate(prompt, stream=True) return post_process(raw, top_chunks) def build_filter(user): # 权限在这里落地，不交给模型判断 return { "sensitivity": {"$in": allowed_levels(user.role)}, "owner_dept": {"$in": user.dept_scope}, }

几个细节值得单独说。查询改写这一步经常被省掉，但在实际使用中收益很大。用户问“报销多久到账”，字面上跟文档里的“费用报销审批时限及付款周期”对不上，向量检索可能召回不准。改写的方式是让模型把口语问题转成两三条更接近书面表达的检索式，多路召回后再融合。成本是多一次小模型调用，延迟增加几百毫秒，换来的是召回率明显提升。

重排这一步是把粗排的 20 到 30 条结果用更精细的模型重新打分。粗排追求速度，重排追求精度，两者配合是检索系统的标准做法。重排模型的输入长度有限，所以重排时通常只用块的摘要或者前几百字。

提示词里强制编号引用，是为了让答案可溯源。我的写法是明确要求“每个结论后面必须标注来源编号，没有依据的内容直接回答‘资料中未提及’”。这句话看着简单，但它是抑制幻觉最有效的一招。配套的post_process要做引用校验：模型给出的编号如果不在本次提供的上下文里，或者引用的编号对应的内容压根没提这件事，就要标红或者降级为“待确认”。

4.3 LoRA 微调的关键参数怎么定

真要做微调，参数不用一次调到位，先跑通再优化。我常用的起点是这样：

数据量方面，格式规范类任务 500 到 1500 条样本就能看到明显效果，风格类建议 2000 条以上。样本质量远比数量重要，一条标注错误的样本能被模型学得牢牢的。我一般会让业务方先标 200 条，跑一轮看效果，再决定要不要继续扩。

有个参数容易被忽略：验证集。一定要留 10% 到 20% 的样本不参与训练，用来观察是否过拟合。只看训练损失下降是很危险的，训练损失一路走低但验证损失抬头，说明模型在背答案，实际用起来会变得迟钝甚至输出格式崩坏。

还有一个必须提醒的点：微调会让模型在其他任务上的表现下降，这属于预期内。如果这个模型还要兼顾通用问答，就要在训练数据里掺入一定比例的通用指令数据，比例大概 10% 到 20%，用来缓解能力漂移。

4.4 服务化阶段容易被低估的三件事

第一件是流式输出。同样是 5 秒，等 5 秒一次性出结果和 0.5 秒开始逐字输出，用户感受完全不同。流式实现要注意引用校验的位置，如果校验放在流式结束后，用户可能已经看完了一段后来被判定为“无依据”的内容。我的做法是先出一个“正在检索”的状态提示，拿到检索结果后先做一次轻量的相关性判断，通过再开始流式生成。

第二件是缓存。内部问答的重复率比想象中高，尤其是制度类问题，前 50 个高频问题可能覆盖 40% 的请求量。做两级缓存：完全相同的规范化问题命中答案缓存，语义相近的问题命中检索结果缓存。规范化包括去空格、去标点、统一大小写。缓存要带失效机制，文档更新时按doc_id清掉相关条目，不然用户会拿到过时答案。

第三件是日志留痕。每次请求记录：原始问题、改写后的问题、召回的块 id 列表、最终答案、耗时、用户标识。这份日志是后面所有优化的基础。没有它，用户反馈“答得不对”的时候，你连是检索错了还是生成错了都判断不了。日志里涉及内容的部分要注意脱敏，这个后面权限那节会展开。

5. 评测与调优：怎么证明系统真的能用

5.1 评测集不用多，但要真

评测集的质量比数量重要得多。我的标准是 100 到 300 条，全部来自真实用户提问，覆盖三类难度：60% 是能直接在文档里找到答案的（考检索）、30% 是需要跨文档综合的（考理解和拼装）、10% 是文档里根本没有的（考拒答）。每条标注三样东西：标准答案要点、正确来源、是否可以拒答。

指标上我盯四个数：检索命中率（正确答案所在的块有没有进 top5）、答案正确率（人工判定，按要点打分）、引用准确率（给出的来源是否真的支持结论）、拒答准确率（该拒答的时候有没有硬编）。这四个数里，检索命中率是先行指标，它不行，后面三个一定不行。很多团队跳过这一步直接看端到端效果，结果发现问题却定位不到原因。

延迟也要单独统计，一般看 p50 和 p95，别看平均值，平均值会被大量快请求掩盖。

5.2 调优有顺序，别乱动模型

调优的顺序应该是：先修检索，再修提示词，最后才考虑动模型。这个顺序不是随便排的，因为越往后改动成本越高、收益越不确定。

如果检索命中率低于 80%，改提示词基本没用，因为模型压根没拿到正确材料。这时候先看召回的东西长什么样：是切分把答案切碎了，还是 embedding 模型对这类术语不敏感，还是这块文档根本没入库。三种原因的处理方式完全不同。我遇到过一个问题，问某个流程的时限，怎么问都答不对，把 top5 打出来一看，正确的那段话被切在了两个块的交界处，前半句在一个块末尾，后半句在一个块开头。调整切分策略按段落边界切之后，问题当场解决。

检索命中率上去了，再看答案正确率。如果检索对了但答案错了，多半是提示词的问题：上下文太长模型抓不住重点、没明确要求“只根据材料回答”、或者材料里有互相矛盾的内容没有优先级规则。这时候要改提示词，加约束、加结构化输出格式、加“如有冲突以发布日期最新为准”这类规则。

只有当格式始终不稳、或者某类固定任务想要小模型替代的时候，才轮到微调上场。

5.3 常见问题速查表

这张表里，我个人认为最值得警惕的是倒数第二行。权限问题一旦出现就是事故，而且很难通过事后审查发现。正确做法是从架构上保证：过滤发生在检索阶段，用户没有权限的块压根不会进入上下文。不要指望在提示词里写“如果用户没有权限就不要回答”，模型的判断是不稳定的，而且它已经看到了内容，一段话从它嘴里漏出来太容易了。

5.4 成本控制的三板斧

第一是路由。不是所有问题都需要大模型。先用一个轻量分类器或者小模型判断问题类型，简单的事实查询走小模型加检索，复杂的综合分析才走大模型。实际运行中，简单问题占比能到六成以上，这一步能省下可观的推理开销。

第二是缓存，前面提过，命中率做好了收益立竿见影。缓存要注意粒度，同一个问题在不同权限用户下答案可能不同，所以缓存键里要带上权限范围标识，不能一刀切。

第三是精简上下文。检索 top_k 从 10 降到 5，上下文长度可能直接砍半，成本跟着降，效果往往还更好，因为干扰少了。重排这一步要舍得花，它能让更少的块达到更好的效果。

6. 权限、安全与踩坑记录

6.1 权限设计要在检索层完成

企业环境的特殊性就在这里，同一套系统，不同的人能看到的范围不一样。设计上我一般分三步走：文档入库时打上密级和归属部门两个标签；用户登录后从身份系统拿到角色和部门范围，映射成可访问的标签集合；每次检索时把标签集合作为过滤条件传给向量库。这三步里，最关键的是第二步的映射关系要集中维护，不要散在各个服务里。

有人会问，能不能让模型自己判断“这个用户该不该看”。不建议这么做。模型对权限的理解是不可靠的，它不知道组织架构，也不知道某个项目组的人员变动。更麻烦的是，一旦内容进了上下文，你就失去了控制权，模型可能在任何一句解释里把敏感信息带出来。架构上唯一的正确做法是让敏感内容根本进不来。

审计日志也要配套。记录谁在什么时候问了什么、检索到哪些块、返回了什么。日志本身的存储要按密级管理，访问日志本身也需要权限。这个要求在项目初期提，往往会被认为小题大做，但真出了事情，没有日志就没法定位范围。

6.2 踩过的坑，一个比一个实在

坑一：旧版本文档没清干净。前面提过，但值得再强调。某次测试里问“报销审批需要几级”，系统回答三级，业务方说早改成两级了。查下来是共享盘里同时存在两个版本，清洗脚本按文件名去重，结果两个文件名只差一个“（修订）”后缀，都被当成独立文档入库了。后来加了生效日期字段和同名收敛逻辑，并且把“文档状态”作为过滤条件，默认只检索有效文档。

坑二：表格切碎后数字对不上。一个报价对比表被按行切开，模型拿到的是几行孤立的数字，答出来的总价是错的。后来改成表格整体建块，超过长度限制的表格按列拆并保留表头，同时在块里加一句“本块为表格数据，请勿跨块推断合计”。这句提示词看着有点笨，但确实减少了一大类错误。

坑三：相似问法召回不稳定。用户问法千奇百怪，同一个意思十种说法，检索引擎很难全接住。除了查询改写，我还加过一版“同义表达库”，把业务方提供的常见说法和标准表述做映射，检索时扩展成多路查询。这个办法土但有效，维护成本也不高，业务方自己就能更新。

坑四：微调之后通用能力下降。有个项目为了让输出格式更稳，做了微调，效果确实好，但接着发现模型开始不会回答“寒暄类”和“超出范围”的问题，被问到不相关内容时也硬套格式。原因就是训练样本太单一。后来在训练集里掺了 15% 的通用指令数据，并且在推理侧加了一个前置的路由判断，超出范围的问题不进微调模型，问题解决。

坑五：只做了语义检索，专有名词翻车。前面提过混合检索，这里说个具体数字。某项目加关键词检索之前，型号类问题的召回率只有六成多，加了 BM25 加 RRF 融合之后提到八成以上，改动量其实很小，就多写了一路检索和几十行融合代码。

6.3 迭代节奏怎么排

我的建议是不要追求一次做完美，按这个节奏走：第一周完成 500 份核心文档的清洗入库，搭一个能跑通的检索加生成链路，先给自己用；第二周找 5 到 10 个真实用户试用，收集 100 条真实问题做评测集；第三到四周，根据评测结果修检索和提示词，把检索命中率拉到 85% 以上；第五周开始做权限、日志、缓存这些工程化的事；第六周再考虑要不要微调。

这个节奏里，最容易失控的是第四周——修检索的时候会发现数据质量问题一大堆，忍不住想全部重做。我的经验是只修影响最大的前三个问题，剩下的记录下来下一轮做。文档治理是个无底洞，一开始就陷进去，项目永远上不了线。

另外，每轮改动都要跑一遍固定的评测集，哪怕是改一句提示词。不然你会陷入“感觉变好了”和“好像又变差了”的循环里，没有任何客观依据。跑分脚本写得糙一点没关系，能复现、能对比就行。

我个人在几个项目里最深的一点体会是：企业专属GPT做的不是模型的工作，是把企业里散落的知识整理成机器能读懂的结构。模型能力这几年一直在涨，换个更好的底座通常就是改个配置的事；但数据清洗、切分策略、权限模型这些东西，换任何模型都得重来一遍，而且只有你自己能做。所以我现在的习惯是把七成精力放在数据和检索上，模型这块保持可替换，留好接口就行。还有一个挺实用的小技巧：上线初期在回答里默认附带来源链接和原文片段，让用户自己判断，比追求一个“完美答案”更能建立信任——用户发现能点回去核对，对系统的容忍度会高很多。