团队里有人提了「把公司文档喂给模型」，你打开一台机器才发现不知道该先买卡还是先搭检索，也不知道哪一步会卡住。这篇按落地顺序拆成几条主线：算力与量化怎么算、部署与推理框架怎么落、RAG 检索链路怎么搭、权限与验收怎么定。每一步都给可执行动作和判断标准，也写清在什么情况下这套做法不适用。
团队里有人提了一句「把公司文档喂给模型」，你打开一台机器才发现，真正卡人的不是模型选哪个，而是不知道该先买卡还是先搭检索，也不知道哪一步会返工。这篇按落地顺序拆开讲：算力与量化怎么算、部署与推理框架怎么落、RAG 检索链路怎么搭、权限与验收怎么定、灰度与回退怎么准备。
前提说清楚：这套流程适合有一定运维能力、文档确实不能出内网的团队。如果只是十几个人偶尔查查公开资料，本地部署的维护成本通常不划算，直接走接口更省事。下面每一步都给可执行动作和判断标准，也写清什么情况下不适用。
先把需求翻译成算力和存储
别一上来就问「买几张卡」。先盘三件事：文档总量与更新频率、同时在线人数、单次回答能容忍多长等待。这三点决定卡数，而不是模型名气。文档多但几乎不更新，和文档少但天天改，索引重建压力完全不一样。
- 盘清三件事文档总量、日活/并发峰值、可接受的首字延迟。用真实业务场景估，别用「理论上很多人会用」估。
- 反推配置拿这三组数字到站内 /compute/sizing 跑一遍，结合 /models/deploy 看当时的模型与卡规格；算力账还要到 /compute/tco 把买卡和租卡对齐看。
- 划边界只有涉及内网数据、监管留痕的部分必须落本地，其余可以走接口。边界不清就先按最保守的一档估，别一开始就按全公司规模铺。
什么情况下不适用：文档总量很小、并发长期只有个位数、且没有合规硬要求时，本地部署的运维投入往往超过收益，这种情况优先考虑接口方案，把精力放在检索质量上。
部署形态与推理框架怎么定
单机试跑和多人并发是两种完全不同的部署。建议分两步：先在一台机器上把「提问—检索—生成」整条链路跑通，确认能出结果；再按并发压力决定是加卡、加副本，还是换推理框架。跳过分步验证，后面出问题很难定位。
| 观察到的现象 | 优先排查方向 | 判断标准 |
|---|---|---|
| 单条提问很慢 | 模型是否过大、量化档位是否过低 | 先看是不是显存不够导致反复换入换出 |
| 人一多就超时 | 并发调度、是否启用连续批处理 | 到 /inference 对照当时的框架支持情况 |
| 回答质量突然变差 | 是不是刚换了量化档位或模型 | 回退到上一档对比同一批问题 |
| 显存总是临界 | 上下文长度、并行副本数设置 | 到 /compute/gpus 核对卡规格与限额 |
- 量化档位不是越低越好：先确认质量下限能接受，再压显存，这个取舍会影响后面全部环节。
- 框架选型看负载形状，长上下文、多并发、需要连续批处理的场景，到 /inference 对照当时的支持情况再定。
- 别照搬别人的默认选项，别人跑通的是他的负载，不是你的。
什么情况下不适用：如果并发长期很低、文档量也小，为了省显存把量化压到很低，反而会让 RAG 生成的答案质量下降到无法验收，这时候宁可少上几个功能，也别硬压。
RAG 检索链路：从切片到重排
RAG 最容易翻车的地方，是把整条链路当一个黑盒调。正确做法是拆成四段分别验证：文档解析与切片、向量化、召回、重排与拼上下文。哪一段不行就单独换那一段，别整体推倒重来。
- 切片
- 按标题层级还是固定长度、是否保留表格和附件，先定死，因为它直接决定答案能不能引用到原文。
- 向量化
- 到 /embeddings 看当时的可用清单，中文语义检索一定要单独测召回质量。
- 向量库
- 到 /stacks/vector-dbs 对照选型，重点看它是否支持在检索时做权限过滤。
- 重排
- 召回的候选多、但真正有用的少时，重排能明显提升上下文质量，但会增加延迟。
判断标准：拿一组你知道答案的真实问题去测，看返回的原文片段里有没有正确答案。如果召回里根本没有，那是切片或向量化的问题；如果召回里有但模型答错，才是生成环节的问题。这个区分能省掉大量无谓的调参。
权限、更新与验收怎么定
权限必须在检索层做，而不是在提示词里写「不要回答别的部门内容」。过滤要发生在召回之前：检索时就按用户身份筛掉无权访问的文档，模型根本看不到，这比事后靠提示词拦截可靠得多。
文档更新要有固定节奏，三点必须写清楚：谁负责上传、多久重建一次索引、旧版本怎么下线。这三条不写，知识库通常在两三个月内就变成没人敢信的垃圾场。
- 准备验收问题集分三类各准备几条：能答对的、该说不知道的、涉及跨部门权限的。
- 逐条记录结果记清是检索没召回、还是模型编了、还是权限漏了，分类归因。
- 约业务方一起看这只是自测口径，最终是否可用要结合业务方实际使用反馈，别自己关起门来打分。
- 能答对的问题：重点看引用是否指向正确原文。
- 该说不知道的问题：模型硬编答案是常见失败模式。
- 跨部门权限问题：验证过滤是否真的发生在召回之前。
什么情况下不适用：如果文档本身就互相矛盾、或者没有统一的版本管理，先解决文档治理再谈 RAG，否则检索层再准也救不了源头混乱。
灰度上线与回退准备
先圈一个部门或一类文档上线，观察提问量和答错类型，再决定扩不扩范围。一上来全公司开放，小问题会被放大很多倍，而且你没法判断是链路的毛病还是使用方式的问题。
回退开关必须在上线前就测过：出问题时能不能切回「只检索不给答案」，或者退回纯人工流程。没测过的回退方案等于没有方案。
成本和用量要盯起来：token 消耗、检索次数、平均响应时间。到 /usage 看当时的真实用量榜做横向参考，别凭感觉判断够不够用；具体数据到站内页面核对当时的数字。
下一步在动手买卡之前，先去站内把算力和成本这两页跑一遍，再顺手看一眼推理框架和中转站的可用性，心里有数了再排期。→常见问题
一定要自己买卡吗，能不能先租着跑？
大部分团队建议先租后买。先用租卡把链路和效果验证完，确认真的有人天天用、并发上得去，再谈采购。租卡的成本口径可以到 /compute/price-index 和 /compute/tco 看当时的数字。如果数据合规要求必须物理隔离、且用量稳定，才值得考虑自建。
RAG 效果不好，先改哪一环？
先看召回，再看生成。把用户问的那几条问题拿出来，检查正确文档有没有被召回进前几名；没召回就是切片或向量模型的问题，召回了但答错才是生成环节。分环节定位能省掉大量无效调参。相关工具可在 /tools/quality-monitor 找到质量监控口径。
知识库内容更新很频繁，怎么处理？
区分两类内容：变动慢的（制度、手册）走定期全量重建；变动快的（价格、项目进展）单独做成小索引或直接走结构化查询，不要混在一起。同时约定一个明确的更新责任人，否则索引会长期停在旧版本。
