数据库管理456期 2026-08-07胖头鱼的技术专栏-456 全文检索到多模态混合检索数据库减少AI Agent超96%的Token消耗20260807开篇第一轮SQLite FTS5 基础检索实验一、全量加载与数据库检索的对比方案二、5 类技术文档与 5 个典型 Agent 问题三、用 cl100k_base 精确计数输入 Token四、SQLite FTS5 检索减少 96.75% 输入 Token第二轮Oracle 多模态混合检索实验五、全文检索无法覆盖语义、权限与关系约束六、多模态混合检索的五个维度协同排序七、Oracle 26ai 上 108 个内容块的多模态融合检索八、多模态混合检索减少 96.54% 输入 Token九、两轮降幅均超 96%但选人逻辑截然不同十、四点关键发现1. Token 降低来自先判断再装配2. 图关系不是展示层装饰3. 标签和元数据让检索具备业务语境4. 单 SQL 融合有工程意义总结胖头鱼的技术专栏-456 全文检索到多模态混合检索数据库减少AI Agent超96%的Token消耗20260807作者胖头鱼的鱼缸尹海文 Oracle ACE Pro: Database PostgreSQL ACE 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVPITPUB认证专家 圈内拥有“总监”称号非著名社恐社交恐怖分子 全网同名胖头鱼的鱼缸 ITPUByhw1809 除授权转载并标明出处外均为“非法”抄袭开篇现在很多 Agent 的记忆和知识还以文件形式存着。文件少、内容短的时候这没啥问题——够用、简单、不折腾。但问题是Agent 面对的场景不会一直这么温柔。当文件越来越多、单个文件越来越大Agent 往往只能把一堆内容一次性塞进上下文再从里面翻出真正相关的那几条。这一塞三个问题就冒出来了输入 Token 暴涨——不该进上下文的内容也跟着进去了噪音干扰答案——上下文中混入大量无关内容模型容易跑偏规模一大就崩——知识越多越难维护文件管理本身就成了负担。而且还有一个很多人容易忽略的事实——大模型需要简短且精确的上下文。上下文越长、噪音越多模型越容易跑偏、产生幻觉、抓不住重点。不是你塞得越多它就越聪明恰恰相反——塞多了反而把它绕晕了。“川序”作为AI Agent底座选择数据库存放Agent数据的价值不光是存这些内容。更重要的是——它可以先做结构化检索再把有限且相关的上下文交给模型。那么问题来了用数据库检索替代全量加载到底能省多少 Token本期我会用两轮渐进式的对比实验回答这个问题。第一轮用 SQLite FTS5 做基础全文检索第二轮直接上 Oracle AI Database 26ai做多模态混合检索——向量、全文、元数据、标签、图关系五个维度一起参与排序。两轮实验同一组文档同一组问题层层递进。老规矩先打个广告https://db4agent.cn。没错我换域名了。第一轮SQLite FTS5 基础检索实验一、全量加载与数据库检索的对比方案说白了就是两种给模型递材料的方式。第一种文件式全量加载。每次提问题把一整套架构、接口、部署、迁移、安全文档全部拼进 Prompt。问题本身也计入输入 Token。这就好比你要查个电话号码别人把整本电话簿甩你面前——“自己翻”。第二种数据库检索。先把同一组文档按段落切成不超过 1600 字符的内容块写进 SQLite 的 FTS5 全文索引提问后按全文相关性排序只取排名最高的 3 个内容块再和问题拼成 Prompt。这次是别人帮你翻好了只递给你三张便签。两种方式用的文档和问题完全一样唯一变的只有发送给模型之前如何选上下文。所以这次实验不是比哪个模型强也不是比不同版本的知识库。二、5 类技术文档与 5 个典型 Agent 问题实验语料来自项目的 5 类技术文档系统架构与数据库控制面API 认证与授权规则部署和运行方式数据库迁移与回滚流程安全边界和凭证隔离这组文档合计约 14 万字符覆盖了 Agent 身份隔离、Skill 接入、持久化执行、数据库迁移和 API 安全等典型问题这些内容源自于“川序”的研发过程产出。为了避免挑一个对自己有利的问题这种嫌疑实验准备了 5 个不同方向的问题Business Agent 如何使用独立数据库身份并禁止回退到 Schema Owner。Skill 如何获取、校验并交付给 Agent 使用。持久化任务如何处理审批、租约、重试和副作用。数据库部署如何执行迁移和回滚。Admin 与 Business Agent API 如何进行认证和授权。每个问题还设了最基本的内容检查——要求检索结果包含与问题相关的关键术语。5 个问题都通过了。需要说明的是这只是检索内容的最低一致性检查不是对模型最终答案质量的完整评价。三、用 cl100k_base 精确计数输入 TokenToken 不是简单的字符数除以几这种粗略估算而是用cl100k_base分词器对最终 Prompt 编码后精确计数。每个问题分别算两项全量方案 问题 全部五类文档 检索方案 问题 FTS5 返回的 Top-3 内容块问题文本和拼接换行符在两种方案中都保留保证比较公平。统计范围是发送给模型的输入 Token不包括模型输出、系统隐藏提示词、工具调用返回、网络传输和数据库查询本身的资源消耗。四、SQLite FTS5 检索减少 96.75% 输入 Token问题方向全量加载Top-3 检索减少 Token减少比例身份隔离28,29389127,40296.85%Skill 接入28,29287727,41596.90%持久化执行28,29294827,34496.65%迁移与回滚28,28996327,32696.60%API 认证授权28,28892227,36696.74%合计141,4544,601136,85396.75%换句话说在这组固定实验中检索方案只向模型提交了全量方案约 3.25% 的输入 Token。相当于你原来要递 14 万字的材料给模型现在只递了 4600 字——该说的都说了废话全砍了。但这个实验说白了还只是第一刀——只用了一种检索维度全文检索数据库也用的是最轻量的 SQLite。企业里的 Agent 场景远比这复杂光靠哪个段落包含这个词是不够的。第二轮Oracle 多模态混合检索实验五、全文检索无法覆盖语义、权限与关系约束全文检索很适合回答哪个内容包含这个词。但 Agent 的问题往往同时带有多层约束用户表达的是自然语言未必使用文档中的原词。某些知识只属于特定业务域、工作区或责任范围。同一个概念可能存在不同版本、标签和重要级别。当前任务可能已经关联了计划、审批、记忆、工具或其他 Agent。即使内容相关也不代表当前主体有权访问。如果只使用向量关键词和精确术语可能不够稳定只使用全文语义改写和同义表达又容易被漏掉只有结构化过滤则难以处理开放式问题只有图关系也不能替代文本相关性。多模态混合检索的目标不是把所有维度简单叠加而是让数据库在模型调用前完成候选筛选、关系判断和排序把相关、可解释、且在授权范围内的少量内容交给 Agent。六、多模态混合检索的五个维度协同排序本次实验使用项目的单 SQL 融合策略——unified_sql。它首先根据向量距离选出有限候选再在 Oracle 内将多个检索维度合成为最终分数。检索维度Oracle 中的实现在 Agent 场景中的作用向量VECTOR_DISTANCE余弦距离识别语义相近但用词不同的内容全文Oracle TextCONTAINS与SCORE保留精确术语、关键短语和词项命中能力结构化元数据文档域、主题、分类和重要级别把内容限制在当前业务或任务语境标签实体与标签关系对已标注的主题、风险或资源属性加权图关系实体边和图邻近度让与当前任务、记忆或知识锚点直接关联的内容优先五个维度的权重可配置。实验中每条结果都记录了各维度得分和最终分数因而可以解释为什么这三段内容进入了 Prompt而不是只得到一个黑盒排序结果。七、Oracle 26ai 上 108 个内容块的多模态融合检索这轮实验在 Oracle AI Database 26ai 上执行。文档选取和第一轮一致——同样的 5 类技术文档但这次按自然段落切分为108 个内容块每块目标上限同样为 1600 个字符。每个内容块在 Oracle 中同时具备原文内容和 Oracle Text 可检索索引text-embedding-bge-m3生成的 1024 维向量对应的知识域、主题和重要级别主题标签与查询域锚点的图关系。实验覆盖的 5 个问题方向与第一轮一致数据库身份隔离、Skill 接入、持久化执行、迁移回滚以及 API 认证授权。每个问题均以 Oracle Text 可执行的受控词项参与全文维度同时使用相同文本生成向量。对照组每次将全部 5 类文档送入 Prompt实验组使用 Oracle 多模态混合检索排序只取 Top-3 内容块。两组均使用cl100k_base对问题 上下文计数。用于实验的实体、向量、元数据、标签和图边均以唯一前缀临时写入结束后自动清理。实验后复查确认临时实体和标签数量均为0没有修改既有基线数据。八、多模态混合检索减少 96.54% 输入 Token问题方向全量上下文 Token多模态混合 Top-3 Token减少比例核心概念检查数据库身份隔离34,1151,42295.83%通过Skill 接入34,1141,52495.53%通过持久化执行34,11681197.62%通过迁移与回滚34,1111,02197.01%通过API 认证授权34,1131,12396.71%通过合计170,5695,90196.54%5/5 通过这意味着在本实验条件下最终送入模型的上下文约为全量加载方案的3.46%。九、两轮降幅均超 96%但选人逻辑截然不同把两轮放一起看维度第一轮SQLite FTS5第二轮Oracle 多模态混合检索数据库SQLiteOracle AI Database 26ai检索维度全文检索1 种向量 全文 元数据 标签 图关系5 种全量 Token141,454170,569检索后 Token4,6015,901降幅96.75%96.54%可解释性全文相关性排序五个维度分别计分可追溯业务语境无有元数据 标签 图关系两轮的降幅都在 96% 以上乍一看差不多。但区别藏在为什么这三段内容被选中这个问题里。第一轮的回答是因为它们包含的关键词最多。第二轮的回答是因为它们在语义上最接近、在全文中命中了精确术语、属于当前业务域、带有关联标签、并且与当前任务的图锚点直接相连——五个维度共同决定。前者是找得到包含某个词的段落后者是理解语义、遵守数据分类、识别标签、利用已有关系并且只在允许的范围内装配上下文。十、四点关键发现1. Token 降低来自先判断再装配不管是 SQLite 还是 OracleToken 的减少都不是因为数据库把文本变短了。原因只有一个——在模型调用之前数据库已经完成了检索、匹配、判断和排序只有最终 Top-3 内容块进入上下文。先管权限再管相关性最后才管模型——这个顺序才是数据库在 Agent 场景下真正的价值。2. 图关系不是展示层装饰第二轮实验为不同问题域设置了不同的关系锚点。与当前锚点直接相连的内容块获得图邻近度加分而无关域的内容不会得到同样加分。实际平台中这个锚点可以来自任务、工作区、记忆、知识、审批或协作频道而不必手工指定一篇文档。3. 标签和元数据让检索具备业务语境向量相似不等于业务相关。例如安全相关内容可能同时出现在部署、权限、审计和代码示例中。文档域、分类、重要级别和标签可以把检索进一步收束到当前任务的语境中并为后续的权限过滤提供承载点。4. 单 SQL 融合有工程意义向量、全文、元数据、标签和图关系不必由 Agent 在多轮调用中逐一拼接。项目将候选和评分放在数据库单条 SQL 中完成减少应用侧多次往返也让排序逻辑、审计和权限边界可以被统一治理。总结从141,454 到 4,601再到170,569 到 5,901——两轮实验两种数据库从单一全文检索到多模态混合检索降幅始终在 96% 以上。这并不是说数据库能替 Agent 思考也不是说所有任务都可以固定用 Top-3。它说的是一件更基础的事当数据库负责结构化保存、索引和筛选时Agent 不必每次都重新阅读整个知识集合。再回到开头那句话——大模型需要简短且精确的上下文。数据库做的就是在模型开口之前把简短和精确这两件事扛下来先判断哪些内容相关、哪些内容在授权范围内、哪些内容跟当前任务有关系再把最终选出来的那几段交给模型。把记忆、知识、权限和上下文边界交给数据库管让模型专注于当前任务——这才是 AI Agent 从个人工具走向可持续运行基础设施的关键一步。需要强调的是本次实验的测试方式不一定完全符合 AI Agent 的全部实际运行场景实验数据仅供参考。老规矩知道写了些啥。