【强烈收藏】提升RAG回答质量：Agentic架构与Cleanlab Codex验证技术详解

1. 为什么你的 RAG 回答总在“一本正经胡说八道”如果你用 LlamaIndex Milvus 搭过 RAG大概率遇到过这种场景用户问“上季度华东区退货率是多少”系统检索回三段文档LLM 张口就给了一个精确到小数点的数字可你翻遍知识库也找不到这个数——它把两段不相干的文本“缝合”了。这就是典型的 RAG 幻觉检索没召回正确上下文生成阶段又缺乏校验最后输出一个看起来很像答案的错误结论。传统 RAG 的链路是“检索 → 拼接 → 生成”中间没有质量闸门。检索回来的 chunk 可能相关度只有 0.4LLM 照样硬着头皮编生成完的回答也没有任何机制判断它是否忠于上下文。结果就是召回率看着还行但回答准确率上不去幻觉率居高不下。这篇要解决的问题很具体在 LlamaIndex 编排、Milvus 做向量库的 RAG 场景里引入 Agentic 架构让 LLM 自己决定“该查文档还是查数据库”再用 Cleanlab Codex 对生成回答做信任度验证把不靠谱的回答拦下来。适合已经跑通基础 RAG、但被回答质量卡住的开发者。下面直接给可复制的配置、脚本和 Milvus 参数骨架最后用对比数据验证效果。2. TaoToken 前置把模型调用和验证链路先跑通Agentic RAG 需要 LLM 支持工具调用function calling否则路由逻辑没法落地。我这边统一用 TaoToken 作为模型接入层它兼容 OpenAI 风格的接口LlamaIndex 的OpenAILike可以直接对接省去改一堆 SDK 的麻烦。先拿 Key。打开 https://taotoken.net/api-keys 创建一个 API Key复制保存。注意这个 Key 只在创建时显示一次丢了就得重建。拿到 Key 后配置环境变量别硬编码在代码里export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用的是 Coding Plan 套餐模型调用额度会更适合长时间跑 Agent 工作流尤其是需要反复路由和验证的场景。具体套餐对比可以在 https://taotoken.net/coding-plan 看这里不展开。验证 Key 是否可用先用 curl 打一发curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: qwen3-235b, messages: [{role: user, content: 只回复 ok}] }返回里有choices[0].message.content且内容为ok说明链路通了。这一步别跳过后面 Agentic 工作流报错时你能快速判断是模型接入问题还是编排逻辑问题。3. 可复制配置Agentic 路由 Milvus 检索 Codex 验证3.1 安装依赖与 Milvus 连接骨架pip install llama-index llama-index-vector-stores-milvus \ llama-index-llms-openai-like pymilvus cleanlab-codex \ streamlit doclingMilvus 连接和索引参数直接给骨架重点看search_params里的ef和nprobe这两个值直接影响召回质量from pymilvus import connections, Collection, CollectionSchema, FieldSchema, DataType connections.connect(aliasdefault, host127.0.0.1, port19530) # 检索参数ef 越大召回越全但越慢nprobe 控制搜索的聚类簇数 search_params { metric_type: COSINE, params: {ef: 128, nprobe: 16} } collection Collection(rag_docs) results collection.search( data[query_embedding], anns_fieldembedding, paramsearch_params, limit5, output_fields[text, source] )ef128是我实测下来在召回率和延迟之间比较平衡的值文档量在十万级以内够用。如果你发现召回经常漏掉关键 chunk先把ef提到 256 试试别急着换 embedding 模型。3.2 LlamaIndex 接入 TaoToken 模型from llama_index.llms.openai_like import OpenAILike import os llm OpenAILike( modelqwen3-235b, api_baseos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], is_chat_modelTrue, is_function_calling_modelTrue, # Agentic 路由必须开 temperature0.1 )is_function_calling_modelTrue这行是关键不开的话 Agent 没法调用工具路由逻辑直接失效。3.3 定义两个查询工具Agentic 的核心是让 LLM 自己选工具。这里定义文档检索和 SQL 查询两个工具from llama_index.core.tools import FunctionTool def search_docs(query: str) - str: 从 Milvus 向量库检索相关文档片段 nodes retriever.retrieve(query) return \n.join([n.get_content() for n in nodes[:3]]) def query_sql(nl_query: str) - str: 将自然语言转为 SQL 并执行返回结果 sql nl_to_sql_engine.query(nl_query) return str(sql) doc_tool FunctionTool.from_defaults(fnsearch_docs) sql_tool FunctionTool.from_defaults(fnquery_sql)3.4 Cleanlab Codex 验证脚本生成回答后用 Codex 打信任分。分数低于阈值就触发重试或降级回复from cleanlab_codex import Codex codex Codex(api_keyos.environ[CLEANLAB_API_KEY]) def validate_answer(query: str, context: str, answer: str) - dict: result codex.validate( queryquery, contextcontext, responseanswer ) return { trust_score: result.trust_score, is_trustworthy: result.trust_score 0.7, reasoning: result.reasoning }trust_score低于 0.7 时我的做法是让 Agent 重新检索一次把 top_k 从 5 提到 8再生成一版。如果第二次还是低分就直接返回“当前知识库无法确认该问题”别硬答。3.5 组装 Agentic 工作流from llama_index.core.agent import FunctionCallingAgentWorker from llama_index.core.agent import AgentRunner worker FunctionCallingAgentWorker.from_tools( [doc_tool, sql_tool], llmllm, verboseTrue, allow_parallel_tool_callsFalse ) agent AgentRunner(worker) response agent.chat(上季度华东区退货率是多少) answer str(response)Agent 会根据问题类型自动选工具问“退货率”这种结构化指标它会走 SQL问“退货政策怎么写的”它会走文档检索。4. 验证请求与成功结果准确率与幻觉率对比配置跑通后做一组对照实验。准备 50 条测试问题其中 25 条答案在文档里25 条在数据库里。分别跑基础 RAG 和 Agentic Codex 两套流程人工核对回答正确性。指标基础 RAGAgentic Codex变化回答准确率68%89%21%幻觉率22%6%-16%平均响应延迟1.8s2.6s0.8s低信任分拦截数011—准确率提升主要来自两块一是 Agentic 路由让结构化问题走了 SQL不再靠文档瞎猜二是 Codex 把 11 条低质量回答拦下来了其中 8 条确实是幻觉。验证请求可以直接用 Streamlit 起个界面把信任分显示在回答旁边import streamlit as st st.title(RAG 质量验证 Demo) query st.text_input(输入问题) if query: response agent.chat(query) answer str(response) validation validate_answer(query, context, answer) st.write(answer) st.metric(信任分, f{validation[trust_score]:.2f}) if not validation[is_trustworthy]: st.warning(该回答信任分偏低建议人工复核)跑起来后你能直观看到哪些回答被标了低分点开reasoning还能看到 Codex 给出的判断依据。5. 本篇常见错排查报错一is_function_calling_model没开导致 Agent 不调用工具现象是 Agent 直接凭记忆回答verbose 日志里看不到 tool call。检查OpenAILike初始化时is_function_calling_modelTrue是否设置。另外确认模型本身支持 function callingqwen3 系列是支持的。报错二Milvus 检索返回空结果先确认 collection 已 loadcollection.load()。再检查search_params里的metric_type是否和建索引时一致建索引用 COSINE检索也得用 COSINE混用会报维度或度量不匹配。报错三Codex 信任分普遍偏低如果所有回答 trust_score 都低于 0.5大概率是 context 传错了。validate里的 context 必须是实际喂给 LLM 的那段检索文本不能传原始 query。另外检查 Codex API Key 是否有效额度是否用完。报错四Agent 路由到错误工具问结构化问题却走了文档检索通常是工具描述写得太模糊。把search_docs的 docstring 改成“用于查询政策、说明、非结构化文本”query_sql改成“用于查询数值、统计、指标类问题”LLM 选工具的准确率会明显提升。报错五延迟过高Agentic 多了一次 LLM 路由调用Codex 验证又是一次网络请求延迟涨 0.8s 正常。如果涨到 3s 以上检查是不是allow_parallel_tool_calls开了导致并发调用或者 Milvus 的ef设太大。把ef从 256 降到 128延迟能降 30% 左右。6. 把验证动作固化进你的 RAG 流水线上面这套跑通后建议把 Codex 验证做成一个独立的后处理节点而不是塞在 Agent 内部。这样你可以对任何 RAG 输出做批量质检甚至离线跑历史回答的信任分分布。具体做法每次 Agent 生成回答后把query、context、answer三元组写进一张日志表定时用 Codex 批量验证统计低分回答的占比。如果某类问题的低分率持续偏高说明对应的检索策略或文档切分有问题回去调 Milvus 的ef或 chunk size。模型对话调试可以用 https://taotoken.net/models 快速对比不同模型在相同 query 下的回答质量接入文档在 https://taotoken.net/doc 有完整的参数说明。长期跑 Agentic 工作流的话Coding Plan 的额度模型更适合这种高频调用场景。