how to create a rag model

很多人搜 how to create a rag model，找到的多半是原理图，真动手时卡在三个地方：文档切多大切多小、向量入库后召不回来、整条链路跑起来不知道哪一步慢。这篇不给概念复述，只给一条能照着做的落地顺序：先把资料切片，再选嵌入模型和向量库把片入库，最后用一条检索链路验证效果。每一步都附上判断标准和排查顺序，跑不通时知道先看哪。

很多人搜 how to create a rag model，翻到的多半是原理图。真动手时卡住的其实是三个工程问题：文档切多大切多小、向量入库之后召不回来、整条链路跑起来不知道哪一步慢。这篇不讲概念复述，只给一条能照着做的落地顺序——先把资料切片，再选嵌入模型和向量库把片入库，最后用一条检索链路验证效果。

每一步都带上判断标准和排查顺序，跑不通时知道先看哪。适合已经会调生成模型接口、但没做过检索增强的开发者；如果你只是想了解 RAG 的原理，这篇的颗粒度会偏细。另外涉及具体模型型号、推荐阈值这类会变的数据，文中都会指到站内对应页面去核对当时的数字。

第一步：把资料切成能召回的片段

切分是整条链路里最容易被低估的一步。它会直接决定后面召回的命中率，而且出了问题很难在检索层补救。建议先按标题层级切大块，再在大块内部按语义或段落切小块——这样每块天然带上下文，也避免把一句话拦腰截断。切分单位定错了，后面换模型、调 top-k 都救不回来。

• 先定切分单位：按标题层级切比按固定字数切更稳，一份文档先按章节拆大块，再在大块内按语义或段落切小块
• 块大小没有万能值，经验做法是让每块能独立讲清一件事；块太小丢上下文，太大挤占上下文预算，具体阈值到 /guides 查当时的推荐口径
• 保留元数据：文件名、章节路径、页码都存进每块的附加字段，后续做引用和过滤全靠它，别只存正文
• 清洗这步不能跳：表格、扫描件、页眉页脚先处理干净，脏数据入库后召回质量会一路拖垮结果

第二步：选嵌入模型并把向量写进库

嵌入模型和生成模型要分开选，别图省事用同一家。中文资料优先看中文语料上表现好的模型，维度、最大输入长度、是否支持批量是三个硬指标。切块长度要和嵌入模型的最大输入对齐，超长的块会被静默截断，等于白切。具体型号和参数可以到 /models 对比，那里的数字是实时维护的。

写入一定要按批量走，别一条一条写。批次大小和并发要压住，写太快容易被向量库限流，失败的记录要落盘记下来重投，否则你以为入库了、实际少了一半，后面排查会非常痛苦。建库那一刻还要把维度、距离度量和索引类型固定下来，这几项后期改动成本高。

第三步：串起检索链路并验证

最小可跑链路就四步：问题向量化、向量库召回 top-k、拼进提示词、交给生成模型。先用一条命令行跑通端到端，再谈优化。不要一上来就加混合检索、重排、多路召回，那样出了问题你分不清是哪层的锅。

1. 跑通最小链路用一条脚本把问题转向量、查库、拼提示词、调生成模型串起来，能返回带出处的答案就算过。
2. 肉眼读命中片段把召回的原文打出来读一遍，是切碎了、还是语义没对上，一眼能判断，别急着换模型。
3. 定位慢在哪一步分别给向量化、检索、生成打时间戳，看是嵌入慢还是库慢，再针对性优化。
4. 固定在脚本里把整条流程写成可重复执行的脚本，改切分或换模型时能一键重跑，别每次手动点。

召回不对先查切分和嵌入，别急着换模型——大部分问题是数据没切好，不是模型不行。

加一层重排或关键词混合检索确实能明显提升命中率，但前提是基础召回已经及格。基础召回不过关的时候调参，等于在错误的底子上刷分，换一批问题就露馅。这套流程适合内部知识库、文档问答这类场景；如果你的资料本身结构极乱、或者问题需要跨文档推理，纯向量召回可能不够，得考虑加检索策略，这点要提前有预期。