被 AAAI 2026 接收的 Amazon 研究团队论文Keyword search is all you needarXiv:2602.23368提出让 LLM Agent 使用 shell 命令进行关键词搜索可以替代管理成本较高的向量数据库同时达到向量数据库 RAG 约 90% 的精度。 论文中的评估基于英文文本 PDF 和 Anthropic Claude 3 SonnetAmazon Bedrock。本文记录了作者在日文 PDF 与 claude-sonnet-4-6截至 2026 年 5 月条件下对这一方法所做的个人实验。 作者想确认以下 3 点在日文中是否也能同样有效成本方面会有什么差异精度是否存在差别本文对论文提出的“基于关键词搜索的 Agentic RAG”在日文 PDF 上做了一次小规模验证。 先说结论在表格和图表中的数值抽取任务上Agent RAG 更强但从 API 成本和延迟看Vector RAG 更稳定。 下文会介绍实验设置、实现、结果和对应解释。由于本文没有执行论文使用的 RAGAS 自动评估Faithfulness / Context Recall / Answer Correctness因此不能和论文数值直接对比。 此外本实验只有 10 道题并由作者手动评估只能观察小规模条件下的趋势并不能得出统计显著的结论。实验设置比较的两种方法Agent RAG论文方法让 LangChain ReAct Agent 把pdfgrep作为工具在没有预先索引的情况下直接全文搜索 PDF。每个查询由 LLM 决定搜索关键词并根据搜索结果继续选择下一组关键词形成迭代搜索。最大迭代次数为max_iterations15LangChainAgentExecutor的默认值。Vector RAG对照方法将intfloat/multilingual-e5-small生成的嵌入写入 ChromaDB再把查询向量化并做近邻搜索。分块设置为chunk_size600, overlap120。论文中使用chunk_size300但本实验考虑到日文 PDF 中语境不宜切得过碎经预先确认后改为chunk_size600。两种方法都使用claude-sonnet-4-6输入 输出15.0/1M tokens。主要库版本# pyproject.toml节选[project]requires-python 3.12dependencies [ langchain0.3.0,1.0, # 实际使用: 0.3.30 langchain-anthropic0.3.0,1.0, # 实际使用: 0.3.22 langchain-community0.3.0,1.0, # 实际使用: 0.3.31 anthropic0.102.0, chromadb1.5.0, sentence-transformers3.0.0, pypdf4.0.0,]评估数据实验对象是 5 份日文政府文档2 份 IPA 的 DX 相关资料、信息通信白皮书、2025 年版制造业白皮书以及大坝与堰设施技术标准。类别题数事实抽取4 题概念说明1 题比较问题2 题步骤/标准2 题多文档横断1 题评估采用作者手动标注correct / incorrect / partial。由于作者同时负责实现和评估结果可能受到确认偏差影响。实现pdfgrep 包装工具这里把pdfgrep包装成 LangChain 自定义工具。from langchain.tools import BaseToolfrom pydantic import BaseModel, Fieldimport subprocess, jsonfrom pathlib import PathPDF_DIR Path(data/japanese_pdfs)class PdfgrepSearchInput(BaseModel): pattern: str Field(description搜索模式可用 Perl 正则表达式用 | 做 OR 搜索) pdf_dir: str Field(defaultstr(PDF_DIR), descriptionPDF 目录路径)class PdfgrepSearchTool(BaseTool): name: str pdfgrep_search description: str ( 使用 pdfgrep 对 PDF 做全文搜索。 使用 Perl 正则表达式-P 标志因此可以像 目的|概要 这样做 OR 搜索。 ) args_schema: type[BaseModel] PdfgrepSearchInput def _run(self, pattern: str, pdf_dir: str str(PDF_DIR)) - str: # 定义 args_schema 时参数有时会以 JSON 字符串传入因此这里手动解析。 try: parsed json.loads(pattern.strip()) if isinstance(parsed, dict): pdf_dir parsed.get(pdf_dir, pdf_dir) pattern parsed.get(pattern, pattern) except (ValueError, TypeError): pass # -------------------------------- pdf_files list(Path(pdf_dir).glob(*.pdf)) ifnot pdf_files: returnfNo PDF files found in {pdf_dir} all_output [] for pdf in pdf_files: cmd [ pdfgrep, -P, # Perl 正则表达式用 | 做 OR 搜索 -i, # 不区分大小写 --context2, # 显示匹配行前后 2 行 pattern, str(pdf), ] result subprocess.run(cmd, capture_outputTrue, textTrue, timeout30) if result.stdout: all_output.append(f[{pdf.name}]\n{result.stdout}) return\n.join(all_output)[:3000] if all_output elseNo matches found.成本监控ReAct 循环会多次调用 LLM因此作者用下面的代码检查每次调用的成本。from langchain.callbacks.base import BaseCallbackHandlerfrom langchain_core.outputs import LLMResultINPUT_COST_PER_M 3.0 # USD / 1M tokens (claude-sonnet-4-6)OUTPUT_COST_PER_M 15.0class TokenUsageCallback(BaseCallbackHandler): def __init__(self) - None: self.total_input_tokens 0 self.total_output_tokens 0 self.llm_call_count 0 property def total_cost_usd(self) - float: return ( self.total_input_tokens / 1_000_000 * INPUT_COST_PER_M self.total_output_tokens / 1_000_000 * OUTPUT_COST_PER_M ) def on_llm_end(self, response: LLMResult, **kwargs) - None: self.llm_call_count 1 in_tok, out_tok self._extract_tokens(response) self.total_input_tokens in_tok self.total_output_tokens out_tok call_cost ( in_tok / 1_000_000 * INPUT_COST_PER_M out_tok / 1_000_000 * OUTPUT_COST_PER_M ) print( f [LLM#{self.llm_call_count}] fin{in_tok:,} out{out_tok:,} tokens | fcall${call_cost:.5f} | 累计${self.total_cost_usd:.5f} ) def _extract_tokens(self, response: LLMResult) - tuple[int, int]: # langchain-anthropic 0.3.x: usage_metadata 会存放在 AIMessage 中 for gens in response.generations: for gen in gens: msg getattr(gen, message, None) meta getattr(msg, usage_metadata, None) if msg elseNone if meta: return meta.get(input_tokens, 0), meta.get(output_tokens, 0) return0, 0定量结果综合比较指标Agent RAGVector RAG正确率10 题中9/1090%7/1070%API 总成本10 题$1.0401$0.1286平均 API 成本 / 每题$0.1040$0.0129平均延迟32.2 秒6.7 秒平均工具执行次数5.7 次 / 每题-平均 API 成本与平均延迟比较柱状图各题详情ID类别Agent 结果Agent 迭代Agent API 成本RAG 结果RAG API 成本q001事实抽取正确7 次$0.1000正确$0.0134q002比较问题正确4 次$0.0717正确$0.0171q003事实抽取正确5 次$0.0565错误$0.0120q004事实抽取正确4 次$0.0326错误$0.0107q005步骤/标准正确4 次$0.0513正确$0.0130q006多文档横断失败15 次$0.4878部分正确$0.0135q007概念说明正确5 次$0.0405正确$0.0098q008事实抽取正确3 次$0.0451正确$0.0083q009步骤/标准正确4 次$0.0710正确$0.0164q010比较问题正确6 次$0.0835正确$0.0144各题 API 成本横向柱状图—— q006 的 Agent 成本明显突出成本梳理API 调用成本和运维成本是两回事比较这两种方法的成本时需要把API 调用成本和基础设施/运维成本分开看。API 调用成本Agent RAG 高出 8.1 倍在这次验证中平均每题 API 成本为 Agent RAG 、0.0129也就是说Vector RAG 便宜 8.1 倍。Agent RAG 成本高有结构性原因。ReAct 循环每多调用一次 LLM就会产生一次 API 费用。每个问题平均发生 5.7 次工具调用q006多文档横断达到 15 次消耗 $0.4878。仅这一题就占 Agent RAG 全部 API 成本约 47%。两者的成本波动也很不同。Vector RAG 在 10 道题中都落在 到0.0171 之间约 2 倍范围而 Agent RAG 落在 到0.4878 之间约 15 倍范围。由于成本会随查询复杂度大幅波动若要嵌入生产服务就需要设计成本上限。需要注意的是论文在讨论成本优势时比较的是“向量数据库的基础设施成本”而不是 LLM API 调用成本。基础设施/运维成本Vector RAG 需要预先构建并持续维护Vector RAG 有运维上的固定成本。本实验中对 5 个文件、351 个分块构建索引约耗时 30 秒CPUmultilingual-e5-small。在生产环境中以下运维工作会持续发生每次新增、删除、更新文档时都需要增量更新索引需要管理嵌入模型版本更换模型时要全量重建需要处理向量数据库的存储和内存扩展Agent RAG 不会产生这些基础设施成本。它在查询时直接读取 PDF 文件因此文档新增或更新只需要替换原文件。论文所说的“降低成本”指的正是这种基础设施和运维成本的下降。不过如果同一组文档会被高频查询索引构建的固定成本也会很快被摊薄。回答质量分析Vector RAG 失败的情况表格和图表中的具体数值q003、q004q004 的问题是“在 2025 年版制造业白皮书中对员工自我提升提供支持的制造业事业所占比是多少”Agent RAG 的回答正确提供支持的事业所占比**80.7%**。最常见的支持形式是“课程费用等金钱援助”。 出处monodzukuri_hakusho_2025_gaiyo.pdf 中写有“对员工自我提升提供支持的事业所占比为 80.7%”。Vector RAG 的回答错误给定上下文中没有记载具体信息。上下文中只有这条信息“制造业中进行自我提升的劳动者比例正式员工约为 4 成……”这说的是劳动者一侧进行自我提升的比例因此没有找到答案。Vector RAG 把“自我提升”“比例”这些语义相近的另一段分块劳动者侧自我提升比例约 4 成取进了前 5 个结果而真正包含答案的位置事业所侧支持比例 80.7%没有进入排序靠前的结果。Agent RAG 则通过不断更换关键词抵达了正确记述位置。q003“在 DX 推进框架中明显低于总体平均的项目是什么”也出现了类似趋势。Vector RAG 返回了“心态/企业文化与投资决策”另一个指标而 Agent RAG 准确引用了“经营高层承诺、愿景为负值”。Agent RAG 失败的情况多文档横断查询q006q006 的问题是“《DX 动向 2025》和《DX 推进指标自我诊断报告 2024 年版》两份资料都指出的 DX 推进共同课题是什么”在这个问题上Agent RAG 达到max_iterations15后仍未能回答。根本原因在于工具设计限制。pdfgrep_search会搜索整个目录因此无法把特定文件的结果分离出来。Agent 在无法区分“结果来自哪份文档”的状态下持续收集证据无法进入合成答案阶段。从实际迭代过程可以看得很清楚。迭代搜索模式结果情况2 到 6课题 / 障碍 / 阻碍尝试指定特定文件但失败命中结果混在全部 PDF 中7 到 14人才短缺 / 人才确保、经营高层 / 承诺、局部最优 / 整体最优等从多个角度继续搜索但无法区分结果分别来自哪份文档15共同 / 主要课题 / 重要课题达到迭代上限搜索结果在上下文窗口中不断累积最终输入膨胀到 22,103 tokens累计成本达到 延迟达到秒。相比之下用0.0135、8.4 秒返回了一个部分正确的答案。Agent 一直判断“证据还不够”这种行为不能脱离工具设计来看。若要用 Agent RAG 处理多文档横断查询就需要拆分为可指定文件的工具或提前准备按文档划分的摘要。方法选择标准基于实验结果可以得到如下选择标准。Agent RAG 适合的场景对同一文档的查询较少无法摊销索引构建成本的用途一次性调查、分析等对表格和图表中具体数值的抽取精度要求较高的用途文档更新频率高难以持续维护索引的系统需要追踪回答依据中的关键词和引用位置的用途Vector RAG 适合的场景同一文档集合会被重复查询的系统可以利用 API 成本单价优势API 成本和延迟的可预测性对生产服务很重要需要跨多份文档整合信息的查询询问没有直接关键词匹配、但存在概念相似性的问题两种方法共同的弱点在本次实现中跨多文档整合信息的查询对两种方法都比较困难。Agent RAG 会导致迭代成本膨胀Vector RAG 则因为分块竞争而只能给出部分回答。不过两者失败的性质并不相同。 Vector RAG 暴露出的是这类简单 Top-k 分块搜索的限制独立检索分块时很难稳定完成跨文档整合。 相对而言Agent RAG 的失败主要来自工具设计。尤其是pdfgrep_search会搜索整个目录不容易按文档整理结果。只要改成可指定文档的工具或准备按文档划分的摘要索引Agent RAG 仍有改善空间。另外多文档横断是 2025 到 2026 年 RAG 研究中的活跃课题GraphRAG、IndexRAG 等专门方法也在不断出现。它是标准实现中被广泛认识到的限制但设计得当的 Agentic RAG 也可能克服这一问题。说真的这两年看着身边一个个搞Java、C、前端、数据、架构的开始卷大模型挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis稳稳当当过日子。结果GPT、DeepSeek火了之后整条线上的人都开始有点慌了大家都在想“我是不是要学大模型不然这饭碗还能保多久”我先给出最直接的答案一定要把现有的技术和大模型结合起来而不是抛弃你们现有技术掌握AI能力的Java工程师比纯Java岗要吃香的多。即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇这绝非空谈。数据说话2025年的最后一个月脉脉高聘发布了《2025年度人才迁徙报告》披露了2025年前10个月的招聘市场现状。AI领域的人才需求呈现出极为迫切的“井喷”态势2025年前10个月新发AI岗位量同比增长543%9月单月同比增幅超11倍。同时在薪资方面AI领域也显著领先。其中月薪排名前20的高薪岗位平均月薪均超过6万元而这些席位大部分被AI研发岗占据。与此相对应市场为AI人才支付了显著的溢价算法工程师中专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%产品经理岗位中AI方向的产品经理薪资也领先约20%。当你意识到“技术AI”是个人突围的最佳路径时整个就业市场的数据也印证了同一个事实AI大模型正成为高薪机会的最大源头。最后我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我整理出这套 AI 大模型突围资料包【允许白嫖】✅从入门到精通的全套视频教程✅AI大模型学习路线图0基础到项目实战仅需90天✅大模型书籍与技术文档PDF✅各大厂大模型面试题目详解✅640套AI大模型报告合集✅大模型入门实战训练这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】①从入门到精通的全套视频教程包含提示词工程、RAG、Agent等技术点② AI大模型学习路线图0基础到项目实战仅需90天全过程AI大模型学习路线③学习电子书籍和技术文档市面上的大模型书籍确实太多了这些是我精选出来的④各大厂大模型面试题目详解⑤640套AI大模型报告合集⑥大模型入门实战训练获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】
不用向量数据库做RAG？
被 AAAI 2026 接收的 Amazon 研究团队论文Keyword search is all you needarXiv:2602.23368提出让 LLM Agent 使用 shell 命令进行关键词搜索可以替代管理成本较高的向量数据库同时达到向量数据库 RAG 约 90% 的精度。 论文中的评估基于英文文本 PDF 和 Anthropic Claude 3 SonnetAmazon Bedrock。本文记录了作者在日文 PDF 与 claude-sonnet-4-6截至 2026 年 5 月条件下对这一方法所做的个人实验。 作者想确认以下 3 点在日文中是否也能同样有效成本方面会有什么差异精度是否存在差别本文对论文提出的“基于关键词搜索的 Agentic RAG”在日文 PDF 上做了一次小规模验证。 先说结论在表格和图表中的数值抽取任务上Agent RAG 更强但从 API 成本和延迟看Vector RAG 更稳定。 下文会介绍实验设置、实现、结果和对应解释。由于本文没有执行论文使用的 RAGAS 自动评估Faithfulness / Context Recall / Answer Correctness因此不能和论文数值直接对比。 此外本实验只有 10 道题并由作者手动评估只能观察小规模条件下的趋势并不能得出统计显著的结论。实验设置比较的两种方法Agent RAG论文方法让 LangChain ReAct Agent 把pdfgrep作为工具在没有预先索引的情况下直接全文搜索 PDF。每个查询由 LLM 决定搜索关键词并根据搜索结果继续选择下一组关键词形成迭代搜索。最大迭代次数为max_iterations15LangChainAgentExecutor的默认值。Vector RAG对照方法将intfloat/multilingual-e5-small生成的嵌入写入 ChromaDB再把查询向量化并做近邻搜索。分块设置为chunk_size600, overlap120。论文中使用chunk_size300但本实验考虑到日文 PDF 中语境不宜切得过碎经预先确认后改为chunk_size600。两种方法都使用claude-sonnet-4-6输入 输出15.0/1M tokens。主要库版本# pyproject.toml节选[project]requires-python 3.12dependencies [ langchain0.3.0,1.0, # 实际使用: 0.3.30 langchain-anthropic0.3.0,1.0, # 实际使用: 0.3.22 langchain-community0.3.0,1.0, # 实际使用: 0.3.31 anthropic0.102.0, chromadb1.5.0, sentence-transformers3.0.0, pypdf4.0.0,]评估数据实验对象是 5 份日文政府文档2 份 IPA 的 DX 相关资料、信息通信白皮书、2025 年版制造业白皮书以及大坝与堰设施技术标准。类别题数事实抽取4 题概念说明1 题比较问题2 题步骤/标准2 题多文档横断1 题评估采用作者手动标注correct / incorrect / partial。由于作者同时负责实现和评估结果可能受到确认偏差影响。实现pdfgrep 包装工具这里把pdfgrep包装成 LangChain 自定义工具。from langchain.tools import BaseToolfrom pydantic import BaseModel, Fieldimport subprocess, jsonfrom pathlib import PathPDF_DIR Path(data/japanese_pdfs)class PdfgrepSearchInput(BaseModel): pattern: str Field(description搜索模式可用 Perl 正则表达式用 | 做 OR 搜索) pdf_dir: str Field(defaultstr(PDF_DIR), descriptionPDF 目录路径)class PdfgrepSearchTool(BaseTool): name: str pdfgrep_search description: str ( 使用 pdfgrep 对 PDF 做全文搜索。 使用 Perl 正则表达式-P 标志因此可以像 目的|概要 这样做 OR 搜索。 ) args_schema: type[BaseModel] PdfgrepSearchInput def _run(self, pattern: str, pdf_dir: str str(PDF_DIR)) - str: # 定义 args_schema 时参数有时会以 JSON 字符串传入因此这里手动解析。 try: parsed json.loads(pattern.strip()) if isinstance(parsed, dict): pdf_dir parsed.get(pdf_dir, pdf_dir) pattern parsed.get(pattern, pattern) except (ValueError, TypeError): pass # -------------------------------- pdf_files list(Path(pdf_dir).glob(*.pdf)) ifnot pdf_files: returnfNo PDF files found in {pdf_dir} all_output [] for pdf in pdf_files: cmd [ pdfgrep, -P, # Perl 正则表达式用 | 做 OR 搜索 -i, # 不区分大小写 --context2, # 显示匹配行前后 2 行 pattern, str(pdf), ] result subprocess.run(cmd, capture_outputTrue, textTrue, timeout30) if result.stdout: all_output.append(f[{pdf.name}]\n{result.stdout}) return\n.join(all_output)[:3000] if all_output elseNo matches found.成本监控ReAct 循环会多次调用 LLM因此作者用下面的代码检查每次调用的成本。from langchain.callbacks.base import BaseCallbackHandlerfrom langchain_core.outputs import LLMResultINPUT_COST_PER_M 3.0 # USD / 1M tokens (claude-sonnet-4-6)OUTPUT_COST_PER_M 15.0class TokenUsageCallback(BaseCallbackHandler): def __init__(self) - None: self.total_input_tokens 0 self.total_output_tokens 0 self.llm_call_count 0 property def total_cost_usd(self) - float: return ( self.total_input_tokens / 1_000_000 * INPUT_COST_PER_M self.total_output_tokens / 1_000_000 * OUTPUT_COST_PER_M ) def on_llm_end(self, response: LLMResult, **kwargs) - None: self.llm_call_count 1 in_tok, out_tok self._extract_tokens(response) self.total_input_tokens in_tok self.total_output_tokens out_tok call_cost ( in_tok / 1_000_000 * INPUT_COST_PER_M out_tok / 1_000_000 * OUTPUT_COST_PER_M ) print( f [LLM#{self.llm_call_count}] fin{in_tok:,} out{out_tok:,} tokens | fcall${call_cost:.5f} | 累计${self.total_cost_usd:.5f} ) def _extract_tokens(self, response: LLMResult) - tuple[int, int]: # langchain-anthropic 0.3.x: usage_metadata 会存放在 AIMessage 中 for gens in response.generations: for gen in gens: msg getattr(gen, message, None) meta getattr(msg, usage_metadata, None) if msg elseNone if meta: return meta.get(input_tokens, 0), meta.get(output_tokens, 0) return0, 0定量结果综合比较指标Agent RAGVector RAG正确率10 题中9/1090%7/1070%API 总成本10 题$1.0401$0.1286平均 API 成本 / 每题$0.1040$0.0129平均延迟32.2 秒6.7 秒平均工具执行次数5.7 次 / 每题-平均 API 成本与平均延迟比较柱状图各题详情ID类别Agent 结果Agent 迭代Agent API 成本RAG 结果RAG API 成本q001事实抽取正确7 次$0.1000正确$0.0134q002比较问题正确4 次$0.0717正确$0.0171q003事实抽取正确5 次$0.0565错误$0.0120q004事实抽取正确4 次$0.0326错误$0.0107q005步骤/标准正确4 次$0.0513正确$0.0130q006多文档横断失败15 次$0.4878部分正确$0.0135q007概念说明正确5 次$0.0405正确$0.0098q008事实抽取正确3 次$0.0451正确$0.0083q009步骤/标准正确4 次$0.0710正确$0.0164q010比较问题正确6 次$0.0835正确$0.0144各题 API 成本横向柱状图—— q006 的 Agent 成本明显突出成本梳理API 调用成本和运维成本是两回事比较这两种方法的成本时需要把API 调用成本和基础设施/运维成本分开看。API 调用成本Agent RAG 高出 8.1 倍在这次验证中平均每题 API 成本为 Agent RAG 、0.0129也就是说Vector RAG 便宜 8.1 倍。Agent RAG 成本高有结构性原因。ReAct 循环每多调用一次 LLM就会产生一次 API 费用。每个问题平均发生 5.7 次工具调用q006多文档横断达到 15 次消耗 $0.4878。仅这一题就占 Agent RAG 全部 API 成本约 47%。两者的成本波动也很不同。Vector RAG 在 10 道题中都落在 到0.0171 之间约 2 倍范围而 Agent RAG 落在 到0.4878 之间约 15 倍范围。由于成本会随查询复杂度大幅波动若要嵌入生产服务就需要设计成本上限。需要注意的是论文在讨论成本优势时比较的是“向量数据库的基础设施成本”而不是 LLM API 调用成本。基础设施/运维成本Vector RAG 需要预先构建并持续维护Vector RAG 有运维上的固定成本。本实验中对 5 个文件、351 个分块构建索引约耗时 30 秒CPUmultilingual-e5-small。在生产环境中以下运维工作会持续发生每次新增、删除、更新文档时都需要增量更新索引需要管理嵌入模型版本更换模型时要全量重建需要处理向量数据库的存储和内存扩展Agent RAG 不会产生这些基础设施成本。它在查询时直接读取 PDF 文件因此文档新增或更新只需要替换原文件。论文所说的“降低成本”指的正是这种基础设施和运维成本的下降。不过如果同一组文档会被高频查询索引构建的固定成本也会很快被摊薄。回答质量分析Vector RAG 失败的情况表格和图表中的具体数值q003、q004q004 的问题是“在 2025 年版制造业白皮书中对员工自我提升提供支持的制造业事业所占比是多少”Agent RAG 的回答正确提供支持的事业所占比**80.7%**。最常见的支持形式是“课程费用等金钱援助”。 出处monodzukuri_hakusho_2025_gaiyo.pdf 中写有“对员工自我提升提供支持的事业所占比为 80.7%”。Vector RAG 的回答错误给定上下文中没有记载具体信息。上下文中只有这条信息“制造业中进行自我提升的劳动者比例正式员工约为 4 成……”这说的是劳动者一侧进行自我提升的比例因此没有找到答案。Vector RAG 把“自我提升”“比例”这些语义相近的另一段分块劳动者侧自我提升比例约 4 成取进了前 5 个结果而真正包含答案的位置事业所侧支持比例 80.7%没有进入排序靠前的结果。Agent RAG 则通过不断更换关键词抵达了正确记述位置。q003“在 DX 推进框架中明显低于总体平均的项目是什么”也出现了类似趋势。Vector RAG 返回了“心态/企业文化与投资决策”另一个指标而 Agent RAG 准确引用了“经营高层承诺、愿景为负值”。Agent RAG 失败的情况多文档横断查询q006q006 的问题是“《DX 动向 2025》和《DX 推进指标自我诊断报告 2024 年版》两份资料都指出的 DX 推进共同课题是什么”在这个问题上Agent RAG 达到max_iterations15后仍未能回答。根本原因在于工具设计限制。pdfgrep_search会搜索整个目录因此无法把特定文件的结果分离出来。Agent 在无法区分“结果来自哪份文档”的状态下持续收集证据无法进入合成答案阶段。从实际迭代过程可以看得很清楚。迭代搜索模式结果情况2 到 6课题 / 障碍 / 阻碍尝试指定特定文件但失败命中结果混在全部 PDF 中7 到 14人才短缺 / 人才确保、经营高层 / 承诺、局部最优 / 整体最优等从多个角度继续搜索但无法区分结果分别来自哪份文档15共同 / 主要课题 / 重要课题达到迭代上限搜索结果在上下文窗口中不断累积最终输入膨胀到 22,103 tokens累计成本达到 延迟达到秒。相比之下用0.0135、8.4 秒返回了一个部分正确的答案。Agent 一直判断“证据还不够”这种行为不能脱离工具设计来看。若要用 Agent RAG 处理多文档横断查询就需要拆分为可指定文件的工具或提前准备按文档划分的摘要。方法选择标准基于实验结果可以得到如下选择标准。Agent RAG 适合的场景对同一文档的查询较少无法摊销索引构建成本的用途一次性调查、分析等对表格和图表中具体数值的抽取精度要求较高的用途文档更新频率高难以持续维护索引的系统需要追踪回答依据中的关键词和引用位置的用途Vector RAG 适合的场景同一文档集合会被重复查询的系统可以利用 API 成本单价优势API 成本和延迟的可预测性对生产服务很重要需要跨多份文档整合信息的查询询问没有直接关键词匹配、但存在概念相似性的问题两种方法共同的弱点在本次实现中跨多文档整合信息的查询对两种方法都比较困难。Agent RAG 会导致迭代成本膨胀Vector RAG 则因为分块竞争而只能给出部分回答。不过两者失败的性质并不相同。 Vector RAG 暴露出的是这类简单 Top-k 分块搜索的限制独立检索分块时很难稳定完成跨文档整合。 相对而言Agent RAG 的失败主要来自工具设计。尤其是pdfgrep_search会搜索整个目录不容易按文档整理结果。只要改成可指定文档的工具或准备按文档划分的摘要索引Agent RAG 仍有改善空间。另外多文档横断是 2025 到 2026 年 RAG 研究中的活跃课题GraphRAG、IndexRAG 等专门方法也在不断出现。它是标准实现中被广泛认识到的限制但设计得当的 Agentic RAG 也可能克服这一问题。说真的这两年看着身边一个个搞Java、C、前端、数据、架构的开始卷大模型挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis稳稳当当过日子。结果GPT、DeepSeek火了之后整条线上的人都开始有点慌了大家都在想“我是不是要学大模型不然这饭碗还能保多久”我先给出最直接的答案一定要把现有的技术和大模型结合起来而不是抛弃你们现有技术掌握AI能力的Java工程师比纯Java岗要吃香的多。即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇这绝非空谈。数据说话2025年的最后一个月脉脉高聘发布了《2025年度人才迁徙报告》披露了2025年前10个月的招聘市场现状。AI领域的人才需求呈现出极为迫切的“井喷”态势2025年前10个月新发AI岗位量同比增长543%9月单月同比增幅超11倍。同时在薪资方面AI领域也显著领先。其中月薪排名前20的高薪岗位平均月薪均超过6万元而这些席位大部分被AI研发岗占据。与此相对应市场为AI人才支付了显著的溢价算法工程师中专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%产品经理岗位中AI方向的产品经理薪资也领先约20%。当你意识到“技术AI”是个人突围的最佳路径时整个就业市场的数据也印证了同一个事实AI大模型正成为高薪机会的最大源头。最后我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我整理出这套 AI 大模型突围资料包【允许白嫖】✅从入门到精通的全套视频教程✅AI大模型学习路线图0基础到项目实战仅需90天✅大模型书籍与技术文档PDF✅各大厂大模型面试题目详解✅640套AI大模型报告合集✅大模型入门实战训练这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】①从入门到精通的全套视频教程包含提示词工程、RAG、Agent等技术点② AI大模型学习路线图0基础到项目实战仅需90天全过程AI大模型学习路线③学习电子书籍和技术文档市面上的大模型书籍确实太多了这些是我精选出来的④各大厂大模型面试题目详解⑤640套AI大模型报告合集⑥大模型入门实战训练获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】
