最近好多同行都在问我同一个问题同样都是RAG应用为什么别人家的成本一个月几千块我这边随便一跑就是几万说实话大部分人的第一反应是去换更便宜的模型API但我在实际项目里验证过——模型调用费只是露在水面上的那一角真正吃掉预算的是检索侧和工程侧那些不太起眼的选择向量库怎么选、top-k设多大、相似度阈值卡多严、缓存怎么做、索引怎么维护。这篇文章把我自己在一套知识库问答系统上做的完整成本优化过程拆开来讲包括4种向量库的选型取舍、检索策略的组合调优以及一组可以直接套用的成本测算方法。不管你现在是刚准备做架构选型还是已经被账单吓到准备改造下面这些内容应该都能用上。1. RAG成本不只在API账单先把手里的账算清楚先说一个我踩过的最大的坑接到一个RAG项目第一件事就去调向量库、写召回逻辑直到月底看到账单才发现钱不知道烧到哪去了。RAG应用的成本是个多变量函数API账单只是结果之一。1.1 三个容易被忽略的隐性成本点第一个是检索噪声造成的无效token消耗。这是最隐蔽、也最花钱的地方。很多检索链路默认一次返回5到10条chunk但里面真正和问题相关的可能只有两三条剩下的全被拼进上下文丢给模型了。模型不会说“你这几条我不看”它一视同仁地把所有内容都算进输入token计费。我见过一个项目检索后拼接的上下文达到4000多token但人工抽样看30%以上内容其实都在“凑数”。第二个是向量库自身的资源占用。把数据往向量库里一塞就完事是很多团队的做法。但不同向量库的内存占用可以差三四倍同样100万条向量有的方案要1GB内存有的能做到400MB以内。更别提那些拉了一整套分布式集群、只服务几百万条数据的情况——运维成本和机器成本比数据量本身还贵。第三个是embedding生成和索引重建的频率。数据一变就全量重新embedding、全量重建索引一次跑几个小时GPU/CPU资源一直在烧。很多更新其实只需要增量处理。1.2 一套可以复用的RAG成本测算框架我习惯把成本拆成三个账户来记账LLM调用费、向量存储与索引维护费、检索链路附加费包括rerank、混合检索的额外服务。其中LLM调用费通常占六到八成也是优化空间最大的地方。单次查询的LLM成本可以用这个公式粗算def estimate_llm_cost(monthly_queries, top_k, chunk_tokens, system_tokens1500, output_tokens600, input_price15, output_price45): 估算单月LLM调用成本 monthly_queries: 月查询次数 top_k: 检索返回条数 chunk_tokens: 每条chunk折算token数 input_price/output_price: 输入/输出单价单位 元/百万token retrieved_tokens top_k * chunk_tokens input_tokens system_tokens retrieved_tokens llm_input_cost monthly_queries * input_tokens / 1e6 * input_price llm_output_cost monthly_queries * output_tokens / 1e6 * output_price return { input_tokens_per_query: input_tokens, llm_input_cost: llm_input_cost, llm_output_cost: llm_output_cost, total_llm_cost: llm_input_cost llm_output_cost, } # 基线月查询30万次top_k5每条chunk折算600 token result estimate_llm_cost(monthly_queries300000, top_k5, chunk_tokens600) print(result)假设月查询30万次top_k5每条chunk折算600 token按输入15元/百万token、输出45元/百万token的常见口径算光LLM调用一个月就要2.8万左右。这时候你就能直观感受到top_k从5降到3光检索token就能省40%乘以月查询量这就是每月上万元级别的差异。所以我的核心观点是RAG成本优化第一优先级的杠杆永远在检索策略上而不是在模型选择上。选模型是最后一步不是第一步。2. 四种向量库的选型对比按规模与运维能力省钱选向量库这件事没有绝对的“哪个最好”只有“哪个在你的数据规模和运维条件下最划算”。我自己在项目里深度对比过四种方案各有各的适用边界。2.1 FAISS内存索引的极致性价比FAISS在我心里一直是“最省钱”的选项前提是你能接受单机部署。它是纯库形态没有独立服务你的代码直接调用索引文件零守护进程、零网络开销、零额外运维。FAISS在百万级向量以内表现非常稳查询毫秒级返回。它还支持PQ乘积量化能把内存压到原始float向量的一半甚至四分之一。代价是工程化能力弱没有原生的增量更新API并发和容灾都得自己实现多租户隔离更是别想。如果你在一个内部工具或中小系统里数据量一两百万条、查询量一天几万次FAISS真的够用而且是最省钱的方案。2.2 Qdrant独立服务里的均衡派Qdrant是Rust写的独立向量数据库不用JVM那套东西内存占用控制得相当好。它自带HNSW索引、稀疏向量、内置量化压缩、payload过滤API简洁单机亿级以下基本都能扛。和FAISS相比Qdrant多了一份服务化能力有原生的增量更新、有HTTP/gRPC接口、有Collection级别的资源隔离。运维成本其实不高就一个进程的事。如果你的团队不想在向量存储上写一堆自研封装又想要稳定的检索性能和完整功能Qdrant是“花一份运维成本买到完整功能”的均衡选项。我目前的主力系统就是用它。2.3 Milvus大集群的代价与收益Milvus的定位是分布式大规模向量检索。它把索引、数据、代理、协调等组件拆得很开支持滚动扩容、高可用、灾备数据量到千万甚至亿级以上是它的主场。但代价也很明确组件多了部署和运维复杂度直线上升。百万级以下的数据量用它确实是杀鸡用牛刀——光是把集群环境调稳花的时间比省下来的算力成本还贵。我的建议是如果你没有明确的“在线扩容、多副本、高可用”需求数据量又没到不该到的量级先别急着上Milvus。它是解决规模化问题的方案不是解决成本问题的方案。2.4 pgvector让PostgreSQL兼任向量库pgvector是在PostgreSQL里加一个向量类型和索引支持。它的最大优势一句话就能说清如果业务数据本来就在PostgreSQL里你等于零新增存储系统SQL一把梭事务一致性和业务数据的关联查询都顺带解决了。缺点是性能极限比较明显。pgvector的HNSW索引在百万级、高并发场景下查询延迟会明显高于专用向量库索引构建也偏慢。所以我把它定位成“中小规模的省心之选”适合数据量不大、不想再维护一套独立存储的团队。2.5 四种方案的快速决策表维度FAISSQdrantMilvuspgvector部署模式库形态嵌入应用独立服务分布式集群PostgreSQL扩展内存/存储开销低可分PQ量化低~中内置压缩高组件多中复用PG百万级查询延迟毫秒级毫秒级毫秒级但链路长中等并发受限扩展性不支持在线扩展支持单机扩展在线扩容、高可用依赖PG集群方案运维成本零低高低适用规模100万~500万100万~1亿千万以上100万以内推荐场景单机内部系统生产级通用RAG平台型/大规模检索业务库复用、轻量需求表格看下来我要重复一句老话选型不是选最强的是选最合适的。我自己踩过“一开始觉得数据量会涨就上重型架构”的坑半年后发现数据量根本没到那个量级集群维护成本反而成了负担。3. 检索策略调优top-k、阈值、混合检索与重排的组合拳向量库选完之后真正的省钱大戏从检索策略开始。这一节的核心理念是省token不是不检索而是尽量减少无价值内容进上下文。3.1 top-k与相似度阈值从源头控制token进入量top-k是最直观的参数也是最容易被无脑拉高的参数。很多人觉得“多返回一点总能多召回到正确答案”但代价是每次查询的输入token线性上涨。我经验上top-k一般落在3~8之间具体看chunk切得大还是小。比top-k更值得精细化调的是相似度阈值。两条规则要配合着用先按top-k粗取多几条再用阈值把低分项滤掉一部分最后进入模型的内容取两者交集或按规则截断。我在文首那个系统里测试过top_k设5加阈值过滤后实际平均只需要3.1条chunk进上下文检索token直接少了接近40%回答质量没有下降——因为那1.9条本来就是噪声。3.2 混合检索让精确匹配去补齐向量召回的盲区向量检索擅长语义接近但有一个明显盲区精确关键词匹配。比如设备型号、订单号、人名这种内容语义向量往往会把“型号M-3021”召回成“型号M-3020”因为它们的语义太像了。这时候BM25这类稀疏检索就有优势。我强烈建议在RAG链路里加上混合检索BM25按关键词精确命中捞一遍向量检索按语义捞一遍两路结果合并去重后再进重排。很多向量库已经内置了稀疏向量能力比如Qdrant的sparse vectorpgvector可以用tsvector并存。没有的话单独起一个轻量搜索服务做BM25也行。混合检索表面上是多算了一路检索实际效果往往是减少无效token因为精确命中的内容质量高可以让你有底气把向量检索那边收紧一点两条路合起来的总召回反而更精简。3.3 重排两级漏斗里的“小模型”省钱逻辑重排是我在所有优化动作里性价比最高的一个。思路很简单粗召回阶段从向量库取50到100条候选用一个轻量的排序模型比如cross-encoder逐条打精分最后只把得分最高的3到5条交给LLM。很多人一听“多一步重排”就觉得是加成本但算笔账就明白50条候选进排序模型的费用和50条候选全部塞给LLM生成一遍的token费用完全不是一个量级。何况重排还能顺手做个硬过滤低于指定分数的候选即使排在前面也不给LLM。这会直接改善生成质量和token浪费两个指标。3.4 分块策略与问题改写两个隐藏杠杆分块策略直接影响token成本和检索精度。块切得太大检索命中一块就等于往上下文里塞一大段废话块切得太小上下文碎片化模型缺乏整体信息照样生成不好。我实测比较舒服的经验值是单块400到800字overlap控制在10%到20%。更进阶一点可以试试父子分块小块用于检索定位命中了再取对应的大块上下文给模型。成本和质量的平衡点比单一切块好不少。还有一个容易被忽略的点是问题改写。用户实际提问往往口语化严重比如“上次那个报错咋解决来着”直接拿去做向量检索召回质量大概率崩。线上加一个query改写步骤把口语问题转成面向知识库的检索式query无效召回率能明显下降。每一次改写都在间接减少“模型被迫看垃圾内容”的成本。4. 实战账本某知识库问答系统从月成本3.2万到1.1万理论讲再多不如看一次完整的实战过程。我拿最近做的一套企业内部知识库问答系统当例子把整个成本优化路径拆开每一步带着数字说话。4.1 改造之前的基线数据项目背景是某企业的内部技术文档问答包含40万条chunk向量维度1536。日查询量1万次月查询量约30万次。优化前的链路很简单请求进来→向量检索top_k5→拼上下文→调LLM生成回答。基线成本构成大致如下项目月费用元LLM输入token含检索拼接和系统提示约20250LLM输出token约8100向量存储与索引维护约2500服务器与网络等杂项约1150合计32000LLM调用费一个月接近2.84万占比接近九成。而且我抽样看过检索结果相当一部分chunk分数刚过阈值、内容和问题只是沾边这就是典型的花钱买噪声。4.2 第一轮优化检索策略调整带来的万元级下降第一轮没有动模型只是把检索链路做了一次“修剪”top_k从5调整为5阈值过滤实际平均进上下文的chunk数降到3.1条加上BM25混合检索精确匹配内容能稳定召回引入轻量重排精排后再取top 3把原来的整块切分调整为父子分块这一轮下来单次查询的检索token从约3000降到约1860月LLM调用费从2.84万降到1.69万左右。加上重排服务的费用整个月成本降到2.1万以内。相当于只调整了检索链路就省下三成多的预算。4.3 第二轮优化语义缓存和推理档位下探第二轮的方向是减少重复计算和降低单次调用单价。先上语义缓存。很多用户问的问题高度重复比如“怎么重置密码”“备份失败怎么办”。传统缓存按字符串精确命中命中率很可怜语义缓存用query向量做相似度匹配相似的问题直接复用历史答案根本不用走LLM。缓存命中率跑到35%以后实际LLM调用次数从30万次/月降到19.5万次/月。再往下是推理档位优化。对内部知识库问答这个场景不需要每次都上最高档模型。把简单问题的生成任务迁移到更便宜的推理档位输出token单价降了将近一半。这一步省下来的钱直接进入总账。4.4 两轮优化后的最终成本对照项目优化前第一轮后第二轮后LLM调用费用元/月284001690010000向量存储与索引维护元/月25002200800重排与检索服务元/月01200600杂项元/月11007000月总成本320002100011400最终月成本稳定在1.1万元左右比基线降了约64%。整个过程中一个字的提示词没改模型也只在第二轮做了档位调整最大贡献都来自检索策略和缓存设计。这就是我在开头说“检索策略是省钱杠杆”的原因——因为大部分成本是在模型收到输入之前就已经决定了。5. 落地避坑索引参数、相似度口径与缓存设计这一节是实操里反复踩过的坑总结。方案看着都合理但一落地就出问题的概率其实很高。5.1 索引类型不是默认HNSW就完事很多向量库的默认索引是HNSW但它有个特性内存占用大约是原始向量的1.2到2倍。100万条768维float32向量原始占用约0.3GBHNSW可能到0.6GB上下。数据量翻十倍这个差距就很惊人了。如果你的场景对延迟不是极度敏感可以认真考虑IVF系索引。IVF内存占用明显更低查询时用nprobe控制探测的聚类数量精度也能通过调参逼近HNSW。关键是不能照搬默认参数要在自己的数据上跑一遍召回率对比。我是吃过这个亏的一个小项目用HNSW跑得欢数据量上来后发现内存预算不够回头改IVF又花了一周调参。5.2 “0.75”到底是相似度还是距离必须先确认不同向量库对相似度阈值的口径完全不同。有的库默认返回余弦相似度cosine similarity分数越接近1越相关有的库返回余弦距离cosine distance即1减去相似度分数越接近0越相关还有的库默认是欧氏距离分数含义又不一样。同是“0.75”在A库里是强相关在B库里可能就弱得没边了。配置阈值前先去文档里确认返回的score类型。别在一个库上调好的0.75换到另一个库直接套上然后发现召回质量断崖式下跌。这个坑我见过不止一次每次都是花半天排查才发现是“度量标准陷阱”。5.3 语义缓存的高命中率不是“越大越好”语义缓存的阈值设计是个微妙的平衡阈值设太严命中率低缓存形同虚设阈值设太松误命中率高用户问的是A问题却返回了B问题的答案体验直接崩。我建议缓存判断不要只看query向量的余弦相似度至少再加一层校验问题类型是否一致、涉及的文档范围是否相同、时效性敏感的查询直接绕过缓存。另外缓存的TTL要跟着源文档的更新频率走文档改了旧答案还挂在缓存里就是风险点。实测下来多一层校验之后命中率虽然略降但误命中风险小了很多整体效果反而更好。5.4 监控不能只盯账单要看过程指标账单是结果但等你看到账单的时候已经晚了。我自己在系统里会盯这么几项过程指标指标计算方式预警线每查询平均检索token数检索返回chunk的总token / 查询次数超过预算值即告警语义缓存命中率命中次数 / 查询总数低于15%说明阈值太严或query太杂无效召回率人工抽样判断返回与问题无关的比例超过20%需要调阈值或加重排P95端到端延迟链路日志统计超过3秒需要查向量库慢查询把这些指标做成一个简单的看板比月底看账单有效得多。数据异常的时候我基本都能提前一两周发现问题而不是等成本爆了才去翻日志。最后说点个人的实际体会。两轮优化做完之后我自己最大的感受是——RAG的成本优化本质上是一次检索精度治理。那些被丢进上下文的低分片段既烧钱又拖低回答质量把检索调准了省钱和提质是同一件事的两面。我也提醒一句别为了省token把阈值无脑调高召回质量如果断崖下跌用户会不断追问、反复重试反而更费钱。动手改之前先把你当前的账单按我前面那张表拆一遍找到占比最大的那一项再决定先动哪把刀。大多数情况下答案都是先动检索。 
长河君 · 2026/10/23 5:43:06 · 阅读 1.2k RAG成本优化实战：从向量库选型到检索策略调优
最近好多同行都在问我同一个问题同样都是RAG应用为什么别人家的成本一个月几千块我这边随便一跑就是几万说实话大部分人的第一反应是去换更便宜的模型API但我在实际项目里验证过——模型调用费只是露在水面上的那一角真正吃掉预算的是检索侧和工程侧那些不太起眼的选择向量库怎么选、top-k设多大、相似度阈值卡多严、缓存怎么做、索引怎么维护。这篇文章把我自己在一套知识库问答系统上做的完整成本优化过程拆开来讲包括4种向量库的选型取舍、检索策略的组合调优以及一组可以直接套用的成本测算方法。不管你现在是刚准备做架构选型还是已经被账单吓到准备改造下面这些内容应该都能用上。1. RAG成本不只在API账单先把手里的账算清楚先说一个我踩过的最大的坑接到一个RAG项目第一件事就去调向量库、写召回逻辑直到月底看到账单才发现钱不知道烧到哪去了。RAG应用的成本是个多变量函数API账单只是结果之一。1.1 三个容易被忽略的隐性成本点第一个是检索噪声造成的无效token消耗。这是最隐蔽、也最花钱的地方。很多检索链路默认一次返回5到10条chunk但里面真正和问题相关的可能只有两三条剩下的全被拼进上下文丢给模型了。模型不会说“你这几条我不看”它一视同仁地把所有内容都算进输入token计费。我见过一个项目检索后拼接的上下文达到4000多token但人工抽样看30%以上内容其实都在“凑数”。第二个是向量库自身的资源占用。把数据往向量库里一塞就完事是很多团队的做法。但不同向量库的内存占用可以差三四倍同样100万条向量有的方案要1GB内存有的能做到400MB以内。更别提那些拉了一整套分布式集群、只服务几百万条数据的情况——运维成本和机器成本比数据量本身还贵。第三个是embedding生成和索引重建的频率。数据一变就全量重新embedding、全量重建索引一次跑几个小时GPU/CPU资源一直在烧。很多更新其实只需要增量处理。1.2 一套可以复用的RAG成本测算框架我习惯把成本拆成三个账户来记账LLM调用费、向量存储与索引维护费、检索链路附加费包括rerank、混合检索的额外服务。其中LLM调用费通常占六到八成也是优化空间最大的地方。单次查询的LLM成本可以用这个公式粗算def estimate_llm_cost(monthly_queries, top_k, chunk_tokens, system_tokens1500, output_tokens600, input_price15, output_price45): 估算单月LLM调用成本 monthly_queries: 月查询次数 top_k: 检索返回条数 chunk_tokens: 每条chunk折算token数 input_price/output_price: 输入/输出单价单位 元/百万token retrieved_tokens top_k * chunk_tokens input_tokens system_tokens retrieved_tokens llm_input_cost monthly_queries * input_tokens / 1e6 * input_price llm_output_cost monthly_queries * output_tokens / 1e6 * output_price return { input_tokens_per_query: input_tokens, llm_input_cost: llm_input_cost, llm_output_cost: llm_output_cost, total_llm_cost: llm_input_cost llm_output_cost, } # 基线月查询30万次top_k5每条chunk折算600 token result estimate_llm_cost(monthly_queries300000, top_k5, chunk_tokens600) print(result)假设月查询30万次top_k5每条chunk折算600 token按输入15元/百万token、输出45元/百万token的常见口径算光LLM调用一个月就要2.8万左右。这时候你就能直观感受到top_k从5降到3光检索token就能省40%乘以月查询量这就是每月上万元级别的差异。所以我的核心观点是RAG成本优化第一优先级的杠杆永远在检索策略上而不是在模型选择上。选模型是最后一步不是第一步。2. 四种向量库的选型对比按规模与运维能力省钱选向量库这件事没有绝对的“哪个最好”只有“哪个在你的数据规模和运维条件下最划算”。我自己在项目里深度对比过四种方案各有各的适用边界。2.1 FAISS内存索引的极致性价比FAISS在我心里一直是“最省钱”的选项前提是你能接受单机部署。它是纯库形态没有独立服务你的代码直接调用索引文件零守护进程、零网络开销、零额外运维。FAISS在百万级向量以内表现非常稳查询毫秒级返回。它还支持PQ乘积量化能把内存压到原始float向量的一半甚至四分之一。代价是工程化能力弱没有原生的增量更新API并发和容灾都得自己实现多租户隔离更是别想。如果你在一个内部工具或中小系统里数据量一两百万条、查询量一天几万次FAISS真的够用而且是最省钱的方案。2.2 Qdrant独立服务里的均衡派Qdrant是Rust写的独立向量数据库不用JVM那套东西内存占用控制得相当好。它自带HNSW索引、稀疏向量、内置量化压缩、payload过滤API简洁单机亿级以下基本都能扛。和FAISS相比Qdrant多了一份服务化能力有原生的增量更新、有HTTP/gRPC接口、有Collection级别的资源隔离。运维成本其实不高就一个进程的事。如果你的团队不想在向量存储上写一堆自研封装又想要稳定的检索性能和完整功能Qdrant是“花一份运维成本买到完整功能”的均衡选项。我目前的主力系统就是用它。2.3 Milvus大集群的代价与收益Milvus的定位是分布式大规模向量检索。它把索引、数据、代理、协调等组件拆得很开支持滚动扩容、高可用、灾备数据量到千万甚至亿级以上是它的主场。但代价也很明确组件多了部署和运维复杂度直线上升。百万级以下的数据量用它确实是杀鸡用牛刀——光是把集群环境调稳花的时间比省下来的算力成本还贵。我的建议是如果你没有明确的“在线扩容、多副本、高可用”需求数据量又没到不该到的量级先别急着上Milvus。它是解决规模化问题的方案不是解决成本问题的方案。2.4 pgvector让PostgreSQL兼任向量库pgvector是在PostgreSQL里加一个向量类型和索引支持。它的最大优势一句话就能说清如果业务数据本来就在PostgreSQL里你等于零新增存储系统SQL一把梭事务一致性和业务数据的关联查询都顺带解决了。缺点是性能极限比较明显。pgvector的HNSW索引在百万级、高并发场景下查询延迟会明显高于专用向量库索引构建也偏慢。所以我把它定位成“中小规模的省心之选”适合数据量不大、不想再维护一套独立存储的团队。2.5 四种方案的快速决策表维度FAISSQdrantMilvuspgvector部署模式库形态嵌入应用独立服务分布式集群PostgreSQL扩展内存/存储开销低可分PQ量化低~中内置压缩高组件多中复用PG百万级查询延迟毫秒级毫秒级毫秒级但链路长中等并发受限扩展性不支持在线扩展支持单机扩展在线扩容、高可用依赖PG集群方案运维成本零低高低适用规模100万~500万100万~1亿千万以上100万以内推荐场景单机内部系统生产级通用RAG平台型/大规模检索业务库复用、轻量需求表格看下来我要重复一句老话选型不是选最强的是选最合适的。我自己踩过“一开始觉得数据量会涨就上重型架构”的坑半年后发现数据量根本没到那个量级集群维护成本反而成了负担。3. 检索策略调优top-k、阈值、混合检索与重排的组合拳向量库选完之后真正的省钱大戏从检索策略开始。这一节的核心理念是省token不是不检索而是尽量减少无价值内容进上下文。3.1 top-k与相似度阈值从源头控制token进入量top-k是最直观的参数也是最容易被无脑拉高的参数。很多人觉得“多返回一点总能多召回到正确答案”但代价是每次查询的输入token线性上涨。我经验上top-k一般落在3~8之间具体看chunk切得大还是小。比top-k更值得精细化调的是相似度阈值。两条规则要配合着用先按top-k粗取多几条再用阈值把低分项滤掉一部分最后进入模型的内容取两者交集或按规则截断。我在文首那个系统里测试过top_k设5加阈值过滤后实际平均只需要3.1条chunk进上下文检索token直接少了接近40%回答质量没有下降——因为那1.9条本来就是噪声。3.2 混合检索让精确匹配去补齐向量召回的盲区向量检索擅长语义接近但有一个明显盲区精确关键词匹配。比如设备型号、订单号、人名这种内容语义向量往往会把“型号M-3021”召回成“型号M-3020”因为它们的语义太像了。这时候BM25这类稀疏检索就有优势。我强烈建议在RAG链路里加上混合检索BM25按关键词精确命中捞一遍向量检索按语义捞一遍两路结果合并去重后再进重排。很多向量库已经内置了稀疏向量能力比如Qdrant的sparse vectorpgvector可以用tsvector并存。没有的话单独起一个轻量搜索服务做BM25也行。混合检索表面上是多算了一路检索实际效果往往是减少无效token因为精确命中的内容质量高可以让你有底气把向量检索那边收紧一点两条路合起来的总召回反而更精简。3.3 重排两级漏斗里的“小模型”省钱逻辑重排是我在所有优化动作里性价比最高的一个。思路很简单粗召回阶段从向量库取50到100条候选用一个轻量的排序模型比如cross-encoder逐条打精分最后只把得分最高的3到5条交给LLM。很多人一听“多一步重排”就觉得是加成本但算笔账就明白50条候选进排序模型的费用和50条候选全部塞给LLM生成一遍的token费用完全不是一个量级。何况重排还能顺手做个硬过滤低于指定分数的候选即使排在前面也不给LLM。这会直接改善生成质量和token浪费两个指标。3.4 分块策略与问题改写两个隐藏杠杆分块策略直接影响token成本和检索精度。块切得太大检索命中一块就等于往上下文里塞一大段废话块切得太小上下文碎片化模型缺乏整体信息照样生成不好。我实测比较舒服的经验值是单块400到800字overlap控制在10%到20%。更进阶一点可以试试父子分块小块用于检索定位命中了再取对应的大块上下文给模型。成本和质量的平衡点比单一切块好不少。还有一个容易被忽略的点是问题改写。用户实际提问往往口语化严重比如“上次那个报错咋解决来着”直接拿去做向量检索召回质量大概率崩。线上加一个query改写步骤把口语问题转成面向知识库的检索式query无效召回率能明显下降。每一次改写都在间接减少“模型被迫看垃圾内容”的成本。4. 实战账本某知识库问答系统从月成本3.2万到1.1万理论讲再多不如看一次完整的实战过程。我拿最近做的一套企业内部知识库问答系统当例子把整个成本优化路径拆开每一步带着数字说话。4.1 改造之前的基线数据项目背景是某企业的内部技术文档问答包含40万条chunk向量维度1536。日查询量1万次月查询量约30万次。优化前的链路很简单请求进来→向量检索top_k5→拼上下文→调LLM生成回答。基线成本构成大致如下项目月费用元LLM输入token含检索拼接和系统提示约20250LLM输出token约8100向量存储与索引维护约2500服务器与网络等杂项约1150合计32000LLM调用费一个月接近2.84万占比接近九成。而且我抽样看过检索结果相当一部分chunk分数刚过阈值、内容和问题只是沾边这就是典型的花钱买噪声。4.2 第一轮优化检索策略调整带来的万元级下降第一轮没有动模型只是把检索链路做了一次“修剪”top_k从5调整为5阈值过滤实际平均进上下文的chunk数降到3.1条加上BM25混合检索精确匹配内容能稳定召回引入轻量重排精排后再取top 3把原来的整块切分调整为父子分块这一轮下来单次查询的检索token从约3000降到约1860月LLM调用费从2.84万降到1.69万左右。加上重排服务的费用整个月成本降到2.1万以内。相当于只调整了检索链路就省下三成多的预算。4.3 第二轮优化语义缓存和推理档位下探第二轮的方向是减少重复计算和降低单次调用单价。先上语义缓存。很多用户问的问题高度重复比如“怎么重置密码”“备份失败怎么办”。传统缓存按字符串精确命中命中率很可怜语义缓存用query向量做相似度匹配相似的问题直接复用历史答案根本不用走LLM。缓存命中率跑到35%以后实际LLM调用次数从30万次/月降到19.5万次/月。再往下是推理档位优化。对内部知识库问答这个场景不需要每次都上最高档模型。把简单问题的生成任务迁移到更便宜的推理档位输出token单价降了将近一半。这一步省下来的钱直接进入总账。4.4 两轮优化后的最终成本对照项目优化前第一轮后第二轮后LLM调用费用元/月284001690010000向量存储与索引维护元/月25002200800重排与检索服务元/月01200600杂项元/月11007000月总成本320002100011400最终月成本稳定在1.1万元左右比基线降了约64%。整个过程中一个字的提示词没改模型也只在第二轮做了档位调整最大贡献都来自检索策略和缓存设计。这就是我在开头说“检索策略是省钱杠杆”的原因——因为大部分成本是在模型收到输入之前就已经决定了。5. 落地避坑索引参数、相似度口径与缓存设计这一节是实操里反复踩过的坑总结。方案看着都合理但一落地就出问题的概率其实很高。5.1 索引类型不是默认HNSW就完事很多向量库的默认索引是HNSW但它有个特性内存占用大约是原始向量的1.2到2倍。100万条768维float32向量原始占用约0.3GBHNSW可能到0.6GB上下。数据量翻十倍这个差距就很惊人了。如果你的场景对延迟不是极度敏感可以认真考虑IVF系索引。IVF内存占用明显更低查询时用nprobe控制探测的聚类数量精度也能通过调参逼近HNSW。关键是不能照搬默认参数要在自己的数据上跑一遍召回率对比。我是吃过这个亏的一个小项目用HNSW跑得欢数据量上来后发现内存预算不够回头改IVF又花了一周调参。5.2 “0.75”到底是相似度还是距离必须先确认不同向量库对相似度阈值的口径完全不同。有的库默认返回余弦相似度cosine similarity分数越接近1越相关有的库返回余弦距离cosine distance即1减去相似度分数越接近0越相关还有的库默认是欧氏距离分数含义又不一样。同是“0.75”在A库里是强相关在B库里可能就弱得没边了。配置阈值前先去文档里确认返回的score类型。别在一个库上调好的0.75换到另一个库直接套上然后发现召回质量断崖式下跌。这个坑我见过不止一次每次都是花半天排查才发现是“度量标准陷阱”。5.3 语义缓存的高命中率不是“越大越好”语义缓存的阈值设计是个微妙的平衡阈值设太严命中率低缓存形同虚设阈值设太松误命中率高用户问的是A问题却返回了B问题的答案体验直接崩。我建议缓存判断不要只看query向量的余弦相似度至少再加一层校验问题类型是否一致、涉及的文档范围是否相同、时效性敏感的查询直接绕过缓存。另外缓存的TTL要跟着源文档的更新频率走文档改了旧答案还挂在缓存里就是风险点。实测下来多一层校验之后命中率虽然略降但误命中风险小了很多整体效果反而更好。5.4 监控不能只盯账单要看过程指标账单是结果但等你看到账单的时候已经晚了。我自己在系统里会盯这么几项过程指标指标计算方式预警线每查询平均检索token数检索返回chunk的总token / 查询次数超过预算值即告警语义缓存命中率命中次数 / 查询总数低于15%说明阈值太严或query太杂无效召回率人工抽样判断返回与问题无关的比例超过20%需要调阈值或加重排P95端到端延迟链路日志统计超过3秒需要查向量库慢查询把这些指标做成一个简单的看板比月底看账单有效得多。数据异常的时候我基本都能提前一两周发现问题而不是等成本爆了才去翻日志。最后说点个人的实际体会。两轮优化做完之后我自己最大的感受是——RAG的成本优化本质上是一次检索精度治理。那些被丢进上下文的低分片段既烧钱又拖低回答质量把检索调准了省钱和提质是同一件事的两面。我也提醒一句别为了省token把阈值无脑调高召回质量如果断崖下跌用户会不断追问、反复重试反而更费钱。动手改之前先把你当前的账单按我前面那张表拆一遍找到占比最大的那一项再决定先动哪把刀。大多数情况下答案都是先动检索。