best ollama model for rag

本地搭 RAG，最容易卡在选模型这一步：网上说的都挺好，装到自己机器上要么跑不动，要么答得飘。这篇不讲原理，只给一套可执行的挑选顺序——按显存和量化定候选范围，按检索片段长度选上下文，用二三十条自家问题做对照，最后留一个降级备选。照做能少走几轮重装的弯路。

本地搭 RAG，最容易卡在选模型这一步：网上说的都挺好，装到自己机器上要么跑不动，要么答得飘。这篇不讲原理，只给一套可执行的挑选顺序——按显存和量化定候选范围，按检索片段长度选上下文，用二三十条自家问题做对照，最后留一个降级备选。照做能少走几轮重装的弯路。

先说明一点：下面这套流程默认你已经在本地跑通了 Ollama，并且有基本的检索链路（比如向量库加切片）。如果连服务都还没起来，先把跑通这件事解决，再回来看选型。选型的价值在于把「试错」变成「按条件筛选」，不是让你一次就选中完美模型。

先量机器，再谈模型：把候选范围砍掉一半

挑模型之前先拿纸写下三条：可用显存或内存有多少、能接受的单次响应延迟是多少、要不要同时服务多个请求。这三条没定，后面全是瞎试——同一台机器上跑得动的候选，可能因为你要并发而直接砍掉一半。

1. 查可用显存在机器上跑一遍查看显存的命令，记下空闲值，不要用显卡标称值。系统、桌面环境、向量库进程都会占一部分。
2. 定延迟底线自己手动问几个长问题，从提交到看到完整回答计时。超过你能忍的秒数，就说明这个档位不能当主模型，只能当兜底。
3. 去站内算一遍拿这三个数字到 /models/deploy 输入机器配置，让它给出可承载的参数和量化档位范围，把候选缩到两三档。

RAG 场景对模型的要求，和聊天、写代码不一样

RAG 的活是「读一段检索回来的资料，照它回答」，重点是长上下文里的信息抽取和抗干扰，不是创作能力。资料里常有表格、条款编号、专有名词，模型能不能照抄原文比会不会润色重要得多。

所以别拿通用聊天榜单直接当 RAG 选型依据。聊天强的模型未必擅长「在一堆无关段落里找对那一段」，而 RAG 恰恰最吃这个。候选模型要在抗干扰上做对比，不是只比通用问答。

参数规模和量化档位：先定一个能跑的上限

先用 /models/deploy 按你的显卡算出可承载的参数范围，再在这个范围里挑，别先挑模型再回头发现装不下。同一档位里优先选对指令跟随和多语言友好的版本，因为中文资料抽取是常见刚需。

• 量化档位直接决定能不能装下：同一模型不同量化，占用和效果差一截，选中档位前先确认显存够用
• 留出余量：显存占满会让并发和长上下文直接崩，一般要留出给 KV 缓存和向量检索进程的空间
• 同一档位里优先选多语言表现好的版本，中文检索片段抽取是很多团队的刚需
• 具体型号和规格到 /models 里按当下在售的条目核对，别抄旧文章里的型号

这里有个常见误区：参数越大越好。在显存刚好卡住的情况下，大模型跑起来慢、并发上不去，实际体验远不如小一号但能流畅运行的版本。先保能跑顺，再谈效果上限。

上下文窗口怎么定：对准你实际检索回来的片段量

先量你一次塞进去多少字：切片大小 × 召回条数 + 模板开销，这个数字比模型标称窗口更有参考价值。很多模型标称能塞很长，实际到一半就开始丢信息。

1. 算实际输入量拿你真实的切片设置（比如每片多少字、召回几条）算出总字数，再加上提示词模板和系统提示的开销。
2. 用最长片段实测把你真实最长的那个片段喂进去，问一个必须从这段里找答案的问题，答不出来就换模型或缩减召回。
3. 观察注意力涣散塞得越满答案越飘，说明这个模型窗口够但注意力不够，宁可选小一点、召回少一点，反而更稳。

用二三十条自家问题做一次对照，别只看榜单

题目从你自己的文档里出，覆盖三类：能直接抄答案的、要跨两段拼的、文档里根本没有的（看它会不会硬编）。每轮只换生成模型，切片、召回条数、提示词模板全部锁死，否则结论无效。

• 记录三个数：答对数、答偏数、编造数，编造数权重最高
• 评测脚本和判定口径区别见 怎么测试rag系统答得准不准
• 整体榜单去 /benchmarks 看，但别把它当成自家场景的结论
• 每轮对照只改一个变量，否则分不清是模型变化还是配置变化

数量不用多，二三十条足够拉开差距。重点不是算出精确分数，而是看哪个模型在你最在意的那类问题上明显更稳。跑完一轮，把明显编造多的直接淘汰。

定一个主模型 + 一个兜底模型

主模型负责线上问答，兜底模型选更小、更快的那个，主模型超时或答不出时降级。降级要能自动触发：连续超时、连续答出空答案就切换，别等人发现。

主模型

效果优先，承担绝大多数线上问答请求

兜底模型

更小更快，主模型超时或答空时顶上

触发条件

连续超时、连续空答案，别设太敏感否则来回抖

降级记录

每次降级都要打日志，方便回头查是模型问题还是检索问题

这类重试与降级怎么落地见 多模型路由与降级。对稳定性要求高时，可以在本地模型之外预留一个远程接口做二段兜底，代价是数据出本地，这条按你的合规要求决定。

跑起来之后调什么：超时、并发、日志

首字慢是本地推理的常态，把超时按连接和读取分开设，别用一个全局值卡死。相关做法见 api 中转站 超时时间 怎么设置。并发数按显存实测，本地模型并发一高延迟是指数级上涨，宁可排队。

• 日志至少记：问题、召回片段数、命中的文档 ID、用的哪个模型、耗时，没有这几项出问题只能猜
• 并发能撑多少到 接口测速 量一遍基线，别拍脑袋定
• 超时分连接和读取两段设，读取超时给长一点，本地推理本来慢
• 模型预热：第一次请求会明显慢，上线前先打几个预热请求

这些参数不是一次定死的。模型换了、切片改了、机器负载变了，都要重新量一遍。把基线数据记下来，下次出问题两分钟就能判断是模型慢了还是检索慢了。

这几种情况，本地 Ollama 不适合当 RAG 的生成端

本地部署有它的边界，下面几种情况下硬上只会给自己找麻烦。判断标准很简单：看你对响应稳定性和并发的要求，以及团队有没有精力做运维。

如果数据本身不敏感、预算又有限，先用远程接口跑通业务，等模型和检索都稳定了再考虑往本地迁。反过来，如果数据不能出本地，那就接受本地推理的延迟上限，把并发和召回量压下来。

选型不是找最强的模型，是找在你机器上跑得顺、又能稳住你最关键那类问题的模型。