1. 项目概述当语义检索遇上成本与效率的权衡在构建现代智能应用尤其是RAG检索增强生成系统时语义检索的质量直接决定了最终答案的准确性和相关性。大家常用的向量数据库比如通过OpenAI的text-embedding-ada-002这类嵌入模型把文本转换成高维向量然后计算余弦相似度来寻找最相关的文档片段。这个方法在概念上很直观效果也不错但它背后藏着一个经常被忽略的“成本陷阱”每一次查询都需要对海量的向量进行相似度计算这个过程计算开销大、响应延迟高更重要的是调用商业嵌入API是按token计费的当你的文档库膨胀到百万甚至千万级别时每一次检索的成本会变得非常可观。这就是“CAMI: Cost-Aware Agent-Guided Multi-Indexing for Semantic Retrieval”这个框架要解决的核心问题。它不是一个全新的向量模型而是一个检索策略与架构的优化框架。其核心思想是在“不惜一切代价追求最高召回率”和“为了控制成本而牺牲精度”之间找到一个智能的平衡点。CAMI通过引入“成本感知”的智能体和“多索引”的协同机制让系统能够根据查询的复杂度、可用预算以及对结果质量的要求动态地选择最经济高效的检索路径。简单来说它想让语义检索变得更“聪明”也更“抠门”。聪明在于它能理解不同查询的意图选择不同的检索策略抠门在于它时刻惦记着你的钱包和服务器资源力求用最小的代价拿到足够好的结果。这对于需要处理大规模私有知识库的企业应用、有严格API调用预算的创业公司或者对响应延迟极其敏感的在线服务来说具有非常现实的意义。接下来我们就深入拆解一下CAMI是如何实现这一目标的。2. 核心设计思路智能体引导的多层检索漏斗CAMI的设计哲学可以概括为“分而治之”和“量入为出”。它不依赖单一的、昂贵的全量向量相似度搜索而是构建了一个由智能体Agent协调的多层索引Multi-Index系统形成一个逐步求精的检索漏斗。2.1 成本感知Cost-Aware的核心是什么这里的“成本”是一个多维度的概念绝不仅仅是金钱。财务成本Monetary Cost最直接的就是调用商业嵌入模型API如OpenAI, Cohere或运行自托管大模型所产生的费用。这部分成本与处理的文本长度Token数和调用次数强相关。计算成本Computational Cost即使使用本地嵌入模型对海量向量进行相似度计算尤其是精确的K近邻搜索KNN也是非常消耗CPU/GPU资源和时间的。索引构建和查询时的计算开销都属于此类。时间成本/延迟Latency Cost用户等待结果返回的时间。复杂的检索策略可能会增加处理环节从而影响端到端的响应速度。CAMI的“成本感知”意味着系统内部需要有一个模型来量化这些成本。例如它可以为不同的操作设置一个成本权重执行一次基于关键词的BM25检索成本权重 0.1对1万个文档块执行一次向量相似度搜索成本权重 1.0调用一次GPT-4生成查询改写成本权重 2.0系统在规划检索路径时会累计算所选路径的总成本并与一个预设的“成本预算”或“质量-成本权衡参数”进行比较。2.2 智能体引导Agent-Guided的角色与决策智能体是CAMI的大脑。它不是一个完成最终答案生成的LLM而是一个负责检索策略规划的决策模块。它的输入是用户的原始查询Query输出是一个具体的“检索执行计划”。这个智能体的决策过程通常基于以下因素查询分析查询是简单的名词短语如“Python lambda函数”还是复杂的、多意图的句子如“请比较Transformer和RNN在长文本处理上的优劣并给出代码示例”简单查询可能只需要轻量级索引复杂查询则需要组合策略。可用索引与成本模型智能体知晓当前系统有哪些可用的索引如关键词索引、向量索引、摘要索引等以及每个索引的查询成本估算。历史反馈与自适应系统可以记录历史查询中不同策略组合的检索效果如最终生成答案的准确率和实际成本。智能体可以基于这些反馈进行强化学习优化未来的决策。例如面对查询“如何用Python连接MySQL数据库并插入数据”智能体可能判断这是一个结构清晰、包含明确技术栈Python, MySQL的问题。它可能决策首先使用低成本的关键词索引BM25快速筛选出所有包含“Python”、“MySQL”、“连接”、“插入”这些关键词的文档得到一个较小的候选集比如从100万篇文档缩小到1000篇。然后再对这个1000篇的候选集使用高成本的向量语义检索进行精排。这样总成本远低于直接对100万篇文档做向量搜索。2.3 多索引Multi-Indexing的协同架构这是CAMI的“武器库”。不同类型的索引各有优劣适合不同的场景关键词索引如BM25, Elasticsearch优点是构建和查询速度极快成本极低对精确术语匹配效果好。缺点是无法理解语义对表述不同但意思相同的查询无能为力如“电脑”和“计算机”。向量索引如FAISS, Chroma, Pinecone优点是语义理解能力强能应对多样化的查询表述。缺点是构建和查询成本高且存在“语义漂移”风险某些不相关但向量空间接近的文档被召回。图索引Graph Index如果文档之间存在丰富的关联如知识图谱中的实体关系图索引可以高效地进行关系推理和路径查找。摘要索引/元数据索引为文档存储一个简短的摘要或关键的元数据作者、类别、时间用于快速、粗粒度的过滤。CAMI并不要求同时维护所有这些索引而是根据数据特性和应用场景灵活配置。智能体的价值就在于知道在什么时候、按什么顺序去使用这些“武器”以达到效费比最优。3. CAMI系统架构与工作流程详解一个典型的CAMI系统工作流程可以分为离线构建和在线查询两个阶段。3.1 离线阶段多索引的构建与成本模型校准在数据准备阶段我们需要为文档库构建多种索引并为每种索引操作定义成本。步骤1文档预处理与分块Chunking这是所有检索系统的基础。将长文档切割成大小适中的片段如512个token的块。分块策略按段落、按句子、滑动窗口会直接影响检索粒度需要根据内容特点调整。步骤2并行构建多索引关键词索引构建对每个文本块进行分词去除停用词、词干提取等构建倒排索引。可以使用Lucene、Elasticsearch或轻量级的Whoosh库。向量索引构建使用选定的嵌入模型如text-embedding-3-small将每个文本块转换为向量然后使用FAISS或HNSWlib等库构建向量索引。这里的关键是选择正确的索引类型IVFFlat, HNSW等需要在召回率、速度和内存之间权衡。可选其他索引构建如果数据适合可以构建图索引或提取摘要建立轻量级索引。步骤3成本模型初始化为每个操作定义基础成本单位。例如cost_bm25(query, index) α * len(query_terms)α是一个很小的系数cost_vector_search(query, candidate_size) β γ * candidate_sizeβ是固定开销γ是处理每个候选向量的开销调用外部API的成本可以直接转换为货币单位。这个成本模型可以在系统运行中根据实际监控数据进行校准。3.2 在线阶段智能体引导的动态检索流程当用户查询到达时系统进入在线推理阶段。步骤1查询接收与智能体激活系统接收用户查询Q。成本感知智能体被激活其内部可能包含一个轻量级的LLM如微调的BERT或小型开源模型或一套规则引擎用于分析查询。步骤2查询分析与策略生成智能体分析Q意图识别是事实型问答、概念解释、代码查询还是比较分析复杂度评估查询长度、术语专业性、是否包含多个子问题。成本预算读取从本次会话或系统配置中读取允许的最大成本阈值C_max。基于以上分析智能体生成一个初步的检索计划P。例如“计划P先使用BM25索引选取关键词‘Python’、‘MySQL’、‘连接’召回Top 200个文档块作为候选集C1预估成本0.2。然后对C1使用向量检索进行重排序返回Top 5预估成本0.8。总预估成本1.0低于C_max2.0。执行。”步骤3多索引协同执行与结果融合系统按照计划P执行查询关键词索引获得粗候选集C1。将查询Q向量化并在C1对应的向量子集上进行相似度计算对C1进行精排。得到精排后的最终结果列表R。这里有一个关键点结果融合。如果计划中使用了多种索引且它们返回了不同来源的结果例如BM25返回了一些向量搜索返回了另一些可能需要一个融合策略如加权分数融合Weighted Score Fusion或交叉编码器重排Cross-Encoder Re-Ranking。步骤4成本核算与反馈学习执行完毕后系统记录实际消耗的成本计算时间、API调用次数等以及本次检索的“效果评估”。效果评估可以来自下游任务如生成的答案被用户点赞也可以通过人工标注或自动化指标如召回文档与理想答案的相关性来近似。 这些查询 计划 实际成本 效果数据点被存入经验池用于后续优化智能体的决策模型。4. 关键实现细节与避坑指南纸上谈兵终觉浅实现CAMI框架时有几个细节决定了成败。4.1 智能体的实现选型规则、模型还是混合这是第一个需要做出的架构选择。基于规则的智能体实现预设一系列if-then规则。例如IF 查询长度 5个词 THEN 使用BM25; IF 查询包含“比较”、“优缺点” THEN 使用向量搜索摘要过滤。优点简单、透明、零训练成本、决策速度快。缺点规则难以覆盖所有复杂情况维护成本随场景增加而剧增缺乏灵活性。适用场景查询模式相对固定、领域狭窄的初期项目或对可解释性要求极高的场景。基于模型的智能体实现训练一个分类器或序列生成模型。输入是查询文本输出是检索计划如索引类型的序列。可以使用微调的BERT模型将计划编码为标签。优点能处理复杂、未见过的查询模式泛化能力强。缺点需要大量的标注数据查询-最优计划对进行训练模型本身有推理成本。适用场景查询多样、数据量充足、追求长期自适应优化的成熟系统。混合型智能体推荐实现用规则处理简单、明确的case用轻量级模型处理模糊、复杂的case。例如先走规则引擎如果规则置信度低则触发小模型进行预测。优点在简单场景下保持高效和可解释在复杂场景下保持智能。实操建议项目启动时从规则引擎开始快速验证流程。同时收集真实的用户查询日志积累到一定量后例如数万条就可以开始着手训练一个简单的模型逐步替代部分规则。4.2 成本模型的量化如何设定成本系数成本系数α β γ不能拍脑袋决定需要基于实际测量。基准测试编写一个脚本模拟大量不同复杂度的查询分别记录执行一次BM25查询的平均耗时T_bm25和CPU使用率。对N个向量执行一次相似度搜索的平均耗时T_vec(N)。调用一次嵌入API的耗时T_api和实际费用F_api。归一化将所有成本统一到一个尺度上。例如以“单位时间成本”或“单位货币成本”为基准。一个简单的方法是将向量全量搜索的成本定义为1.0。假设对全部100万个文档做向量搜索的成本是1.0那么BM25搜索的成本可以量化为T_bm25 / T_vec(1M) * 资源缩放因子因为BM25通常更省资源缩放因子可能小于1。对10%候选集10万文档的向量搜索成本约为0.1。API调用成本可以按F_api / (单次向量搜索的等效费用)来折算。动态调整成本模型不是一成不变的。当硬件升级、数据量翻倍、API定价调整时需要重新校准。可以在系统内设置一个定期运行的校准任务。注意成本模型的精确度会影响智能体决策的最优性但在初期一个粗略但合理的模型远比没有模型要好。关键是建立起“成本意识”的框架具体数值可以迭代优化。4.3 索引选择与性能权衡不是索引越多越好。每增加一种索引就增加了存储开销和维护复杂性。必选项关键词索引 向量索引。这是当前语义检索的“黄金搭档”一个保效率一个保效果。可选项图索引。只有当你的数据是高度结构化的知识如产品手册、学术论文引用网络且查询频繁涉及关系推理时才值得引入。它的构建和维护成本最高。可选项摘要/元数据索引。适用于文档有清晰分类、标签或发布时间的场景可以用于查询前的快速过滤如“只搜索2023年之后的编程教程”能极大缩小后续检索的范围性价比很高。避坑指南向量索引的参数调优使用FAISS或HNSW时参数设置对性能影响巨大。HNSW的efConstruction和efSearchefConstruction影响索引构建质量和速度值越大索引质量越高但构建越慢。efSearch影响搜索时的精度和速度值越大搜索结果越准但越慢。建议在构建时使用较大的efConstruction如200-400以获得高质量索引在线查询时根据成本预算动态调整efSearch。智能体在制定计划时可以选择一个较小的efSearch值以降低成本虽然会轻微牺牲精度。IVFFlat的nlist和nprobenlist是将向量空间划分成的聚类中心数nprobe是搜索时探查的聚类数。nprobe越大搜索越精确越慢。智能体同样可以动态选择nprobe作为成本控制的一个维度。5. 实战构建一个简化版的CAMI系统我们以Python为例使用一些开源库搭建一个CAMI的简化原型演示核心流程。5.1 环境准备与依赖安装# 创建虚拟环境可选但推荐 python -m venv cami_env source cami_env/bin/activate # Linux/Mac # cami_env\Scripts\activate # Windows # 安装核心库 pip install langchain langchain-community # 用于框架和文档加载 pip install sentence-transformers # 用于本地嵌入模型节省API成本 pip install faiss-cpu # 向量索引库 pip install rank-bm25 # 轻量级BM25实现 pip install scikit-learn # 用于一些工具函数5.2 数据加载、分块与多索引构建假设我们有一系列Markdown格式的技术文档。import os from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from sentence_transformers import SentenceTransformer import faiss import numpy as np from rank_bm25 import BM25Okapi import pickle import time # 1. 加载文档 loader DirectoryLoader(./docs/, glob**/*.md, loader_clsTextLoader) documents loader.load() print(f加载了 {len(documents)} 篇文档) # 2. 文档分块 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, length_functionlen, separators[\n\n, \n, 。, , , , , 、, ] ) chunks text_splitter.split_documents(documents) print(f切分为 {len(chunks)} 个文本块) # 3. 准备文本和元数据 chunk_texts [chunk.page_content for chunk in chunks] chunk_metadata [chunk.metadata for chunk in chunks] # 保存来源等信息 # 4. 构建关键词索引 (BM25) print(正在构建BM25索引...) tokenized_corpus [doc.split( ) for doc in chunk_texts] # 简单空格分词生产环境应用更好的分词器 bm25_index BM25Okapi(tokenized_corpus) # 保存索引 with open(bm25_index.pkl, wb) as f: pickle.dump(bm25_index, f) print(BM25索引构建完成。) # 5. 构建向量索引 (FAISS) print(正在加载嵌入模型...) embed_model SentenceTransformer(all-MiniLM-L6-v2) # 轻量且效果不错的开源模型 print(正在生成嵌入向量...) chunk_embeddings embed_model.encode(chunk_texts, show_progress_barTrue) dimension chunk_embeddings.shape[1] print(正在构建FAISS索引...) faiss_index faiss.IndexFlatIP(dimension) # 使用内积余弦相似度需归一化 # 归一化向量以便使用内积计算余弦相似度 faiss.normalize_L2(chunk_embeddings) faiss_index.add(chunk_embeddings) # 保存索引 faiss.write_index(faiss_index, faiss_index.bin) # 保存文本和向量的映射 with open(chunk_data.pkl, wb) as f: pickle.dump({texts: chunk_texts, metadata: chunk_metadata}, f) print(向量索引构建完成。)5.3 实现一个规则型成本感知智能体我们实现一个简单的、基于规则的智能体它根据查询长度和术语判断策略。class RuleBasedCostAwareAgent: def __init__(self, bm25_cost_weight0.1, vector_cost_per_chunk0.001, api_call_cost5.0): self.bm25_cost_weight bm25_cost_weight self.vector_cost_per_chunk vector_cost_per_chunk self.api_call_cost api_call_cost # 定义一些需要复杂语义理解的触发词 self.complex_triggers [比较, 区别, 优缺点, 如何理解, 为什么, 阐述] self.tech_entities [python, java, mysql, docker, kubernetes] # 示例技术实体 def analyze_query(self, query): 分析查询并生成检索计划 plan { steps: [], estimated_cost: 0.0, candidate_limit: None } words query.lower().split() query_len len(words) # 规则1: 非常短的查询优先用BM25 if query_len 2: plan[steps] [(bm25, 50)] # 只用BM25返回50个候选 plan[estimated_cost] self.bm25_cost_weight return plan # 规则2: 包含复杂触发词需要深度语义理解 if any(trigger in query for trigger in self.complex_triggers): # 计划先用BM25粗筛再用向量精排 bm25_candidate_num 200 plan[steps] [(bm25, bm25_candidate_num), (vector_rerank, 10)] plan[estimated_cost] self.bm25_cost_weight (self.vector_cost_per_chunk * bm25_candidate_num) plan[candidate_limit] bm25_candidate_num return plan # 规则3: 包含明确技术实体可能用BM25效果就很好 if any(entity in query.lower() for entity in self.tech_entities): # 尝试先用BM25如果结果置信度低再fallback到向量 plan[steps] [(bm25_adaptive, 100), (vector_fallback, 10)] # 成本估算取平均值 plan[estimated_cost] self.bm25_cost_weight (self.vector_cost_per_chunk * 50) # 假设50%概率走fallback return plan # 默认规则中等长度查询混合策略 bm25_candidate_num 150 plan[steps] [(bm25, bm25_candidate_num), (vector_rerank, 10)] plan[estimated_cost] self.bm25_cost_weight (self.vector_cost_per_chunk * bm25_candidate_num) plan[candidate_limit] bm25_candidate_num return plan def execute_plan(self, plan, query, bm25_index, faiss_index, chunk_texts, embed_model): 执行检索计划 all_candidates list(range(len(chunk_texts))) # 初始候选集为全部索引 final_results [] total_actual_cost 0.0 for step in plan[steps]: step_type, param step if step_type bm25: # 执行BM25检索 start time.time() tokenized_query query.split( ) scores bm25_index.get_scores(tokenized_query) top_n_indices np.argsort(scores)[::-1][:param] elapsed time.time() - start all_candidates top_n_indices.tolist() total_actual_cost elapsed * 1000 # 将时间转换为成本单位毫秒 print(fBM25步骤完成筛选出 {len(all_candidates)} 个候选耗时 {elapsed:.3f}s) elif step_type vector_rerank: # 对BM25筛选后的候选集进行向量重排 if not all_candidates: break start time.time() query_embedding embed_model.encode([query]) faiss.normalize_L2(query_embedding) # 仅从候选集中获取向量 candidate_embeddings chunk_embeddings[all_candidates] # 创建一个临时的小FAISS索引进行搜索更高效 temp_index faiss.IndexFlatIP(dimension) faiss.normalize_L2(candidate_embeddings) temp_index.add(candidate_embeddings) D, I temp_index.search(query_embedding, min(param, len(all_candidates))) # I 中的索引是相对于 candidate_embeddings 的需要映射回原始索引 final_indices [all_candidates[i] for i in I[0]] final_results [(chunk_texts[idx], D[0][i]) for i, idx in enumerate(final_indices)] elapsed time.time() - start total_actual_cost elapsed * 1000 (self.vector_cost_per_chunk * len(all_candidates) * 1000) # 加入计算成本 print(f向量重排步骤完成返回Top {len(final_results)}耗时 {elapsed:.3f}s) elif step_type bm25_adaptive: # 自适应BM25检查结果置信度 start time.time() tokenized_query query.split( ) scores bm25_index.get_scores(tokenized_query) top_n_indices np.argsort(scores)[::-1][:param] top_scores scores[top_n_indices] elapsed time.time() - start total_actual_cost elapsed * 1000 # 简单置信度判断如果最高分远高于平均分则认为BM25结果可靠 if len(top_scores) 1 and top_scores[0] np.mean(top_scores[1:]) * 2: print(fBM25结果置信度高直接返回。) final_results [(chunk_texts[idx], scores[idx]) for idx in top_n_indices[:10]] return final_results, total_actual_cost else: print(fBM25结果置信度低进入备选向量流程。) all_candidates top_n_indices.tolist() # 将BM25结果作为向量搜索的候选集 elif step_type vector_fallback: # 作为备选的向量搜索 if not all_candidates: all_candidates list(range(len(chunk_texts))) # 如果上一步没给候选则用全量 # ... 执行与vector_rerank类似的逻辑 # 为简洁起见此处省略重复代码 return final_results, total_actual_cost5.4 组装与测试# 加载之前保存的索引和数据 print(加载索引和数据...) with open(bm25_index.pkl, rb) as f: bm25_index pickle.load(f) faiss_index faiss.read_index(faiss_index.bin) with open(chunk_data.pkl, rb) as f: chunk_data pickle.load(f) chunk_texts chunk_data[texts] chunk_embeddings embed_model.encode(chunk_texts) # 重新加载或从文件读取 faiss.normalize_L2(chunk_embeddings) # 初始化智能体 agent RuleBasedCostAwareAgent() # 测试查询 test_queries [ python lambda, # 短查询 比较mysql和postgresql的优缺点, # 复杂查询 docker容器网络配置, # 含技术实体的查询 机器学习模型训练的基本步骤 # 一般性查询 ] for query in test_queries: print(f\n{*50}) print(f处理查询: {query}) plan agent.analyze_query(query) print(f生成的计划: {plan[steps]}) print(f预估成本: {plan[estimated_cost]:.3f}) results, actual_cost agent.execute_plan(plan, query, bm25_index, faiss_index, chunk_texts, embed_model) print(f实际成本: {actual_cost:.3f} (单位)) print(f返回结果数: {len(results)}) if results: print(Top 1 结果预览:) print(results[0][0][:200]) # 打印前200个字符这个简化版原型展示了CAMI的核心闭环分析查询 - 生成成本感知计划 - 执行多步检索。在实际生产中你需要用更成熟的分词器如jieba用于中文、更鲁棒的索引库如用Elasticsearch替代rank-bm25、更复杂的智能体模型以及完整的历史反馈学习循环来替换这些组件。6. 性能评估、常见问题与优化方向部署CAMI后如何衡量它是否成功又会遇到哪些坑6.1 评估指标不只是准确率对于成本感知系统评估必须是多维度的检索质量指标召回率RecallK在Top K个结果中包含所有相关文档的比例。这是基础。平均精度Mean Average Precision, MAP考虑排序顺序的精度更能反映用户体验。归一化折损累计增益NDCG对于相关性有分级如非常相关、一般相关的场景更合适。成本与效率指标平均查询成本每次查询消耗的综合成本单位或实际货币成本。查询延迟P95, P9995%和99%的查询在多少毫秒内返回。资源利用率CPU/内存/GPU在检索期间的占用率。业务指标下游任务提升如果用于RAG最终生成答案的准确率或用户满意度是否有提升成本节省比例相比单一的向量全量检索节省了多少百分比的成本建立一个评估基准保留一个测试查询集分别用“全量向量搜索”黄金标准但成本高和你的CAMI策略运行对比以上指标。理想情况是CAMI在检索质量轻微下降可接受范围内的情况下带来显著的成本和延迟下降。6.2 常见问题与排查技巧智能体决策错误导致召回率暴跌现象对于某些查询返回的结果完全无关。排查检查该查询被智能体分配到了什么计划。是否是规则没有覆盖到这种查询类型或者模型预测错误解决将这些“问题查询”加入日志并人工标注正确的检索策略用作后续优化智能体规则或模型的训练数据。可以设置一个“降级开关”当智能体决策的置信度过低时自动回退到成本更高的保守策略如向量全量搜索保证基础效果。成本模型不准实际开销超出预期现象系统监控显示平均成本高于预估。排查对比预估成本和实际成本的分布。是某一类操作如向量搜索的成本被低估了还是成本模型没有考虑到某些隐性开销如网络IO解决进行更细致的性能剖析Profiling更新成本模型中的系数。考虑引入动态成本预测比如根据候选集大小实时预测向量搜索耗时。索引不一致性导致结果错误现象BM25返回的文档ID在向量库中找不到对应的向量导致程序崩溃或结果缺失。排查确保在文档更新、删除后所有索引能同步更新。检查构建多索引时文本块的顺序和对应关系是否严格一致。解决为每个文本块生成一个全局唯一ID如UUID所有索引都通过这个ID来关联文档块。建立索引版本管理机制确保查询时使用的多个索引属于同一版本。系统复杂度增加调试困难现象问题出现时很难定位是哪个环节智能体、BM25、向量搜索、融合出的错。解决建立完善的链路追踪Tracing和日志记录。为每一次查询生成一个trace_id记录下智能体的决策、每一步检索的输入输出、耗时和中间结果。这不仅能帮助调试也是优化智能体训练数据的宝贵来源。6.3 进阶优化方向当基本框架跑通后可以考虑以下方向进行深度优化智能体模型化与在线学习用监督学习或强化学习训练智能体。收集查询 上下文 最优检索路径 最终效果的四元组数据训练一个模型来预测最优路径。可以引入在线学习让智能体根据实时反馈微调。多路召回与精细融合不仅限于BM25-向量的串联可以尝试并行多路召回BM25、向量、元数据过滤同时进行然后使用更先进的融合算法如互信息MI加权或使用交叉编码器Cross-Encoder对多路召回的候选进行统一精排。虽然交叉编码器成本高但只对少量如50个候选使用性价比可能很高。索引本身的成本分级在向量索引内部实现成本分级。例如使用**分层可导航小世界图HNSW**时可以通过调整搜索参数efSearch来动态控制搜索深度和精度。智能体在制定计划时可以指定efSearch的值实现更细粒度的成本控制。查询理解与改写在检索前增加一个“查询理解”层。使用轻量级模型对查询进行意图分类、关键信息抽取或查询改写/扩展。例如将“苹果”根据上下文改写为“苹果公司”或“水果苹果”可以极大提升初步筛选的准确性从而减少后续昂贵操作的范围。缓存策略对高频、结果稳定的查询及其检索结果进行缓存。智能体在决策时可以先检查缓存命中则直接返回成本几乎为零。这尤其适合百科类、概念定义类的查询。CAMI框架的本质是将“检索”从一个简单的相似度计算问题提升为一个资源约束下的优化决策问题。它没有银弹需要你根据自身的数据特性、查询模式和资源约束进行仔细的调优和迭代。但一旦搭建起来它带来的成本节约和效率提升对于大规模、高并发的语义检索应用来说将是极具竞争力的优势。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
