胖头鱼的技术专栏-456 全文检索到多模态混合检索：数据库减少AI Agent超96%的Token消耗（20260807）

作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE 10年+数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 全网同名：胖头鱼的鱼缸 ITPUB：yhw1809 除授权转载并标明出处外，均为“非法”抄袭

开篇

现在很多 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 个不同方向的问题：

1. Business Agent 如何使用独立数据库身份，并禁止回退到 Schema Owner。
2. Skill 如何获取、校验并交付给 Agent 使用。
3. 持久化任务如何处理审批、租约、重试和副作用。
4. 数据库部署如何执行迁移和回滚。
5. Admin 与 Business Agent API 如何进行认证和授权。

每个问题还设了最基本的内容检查——要求检索结果包含与问题相关的关键术语。5 个问题都通过了。需要说明的是，这只是检索内容的最低一致性检查，不是对模型最终答案质量的完整评价。

三、用 cl100k_base 精确计数输入 Token

Token 不是简单的"字符数除以几"这种粗略估算，而是用cl100k_base分词器对最终 Prompt 编码后精确计数。每个问题分别算两项：

全量方案 = 问题 + 全部五类文档 检索方案 = 问题 + FTS5 返回的 Top-3 内容块

问题文本和拼接换行符在两种方案中都保留，保证比较公平。统计范围是发送给模型的输入 Token，不包括模型输出、系统隐藏提示词、工具调用返回、网络传输和数据库查询本身的资源消耗。

四、SQLite FTS5 检索减少 96.75% 输入 Token

换句话说，在这组固定实验中，检索方案只向模型提交了全量方案约 3.25% 的输入 Token。相当于你原来要递 14 万字的材料给模型，现在只递了 4600 字——该说的都说了，废话全砍了。

但这个实验说白了还只是"第一刀"——只用了一种检索维度（全文检索），数据库也用的是最轻量的 SQLite。企业里的 Agent 场景远比这复杂，光靠"哪个段落包含这个词"是不够的。

第二轮：Oracle 多模态混合检索实验

五、全文检索无法覆盖语义、权限与关系约束

全文检索很适合回答"哪个内容包含这个词"。但 Agent 的问题往往同时带有多层约束：

• 用户表达的是自然语言，未必使用文档中的原词。
• 某些知识只属于特定业务域、工作区或责任范围。
• 同一个概念可能存在不同版本、标签和重要级别。
• 当前任务可能已经关联了计划、审批、记忆、工具或其他 Agent。
• 即使内容相关，也不代表当前主体有权访问。

如果只使用向量，关键词和精确术语可能不够稳定；只使用全文，语义改写和同义表达又容易被漏掉；只有结构化过滤，则难以处理开放式问题；只有图关系，也不能替代文本相关性。

多模态混合检索的目标不是把所有维度简单叠加，而是让数据库在模型调用前完成候选筛选、关系判断和排序，把"相关、可解释、且在授权范围内"的少量内容交给 Agent。

六、多模态混合检索的五个维度协同排序

本次实验使用项目的单 SQL 融合策略——unified_sql。它首先根据向量距离选出有限候选，再在 Oracle 内将多个检索维度合成为最终分数。

五个维度的权重可配置。实验中每条结果都记录了各维度得分和最终分数，因而可以解释"为什么这三段内容进入了 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

这意味着，在本实验条件下，最终送入模型的上下文约为全量加载方案的3.46%。

九、两轮降幅均超 96%，但选人逻辑截然不同

把两轮放一起看：

两轮的降幅都在 96% 以上，乍一看差不多。但区别藏在"为什么这三段内容被选中"这个问题里。

第一轮的回答是：因为它们包含的关键词最多。

第二轮的回答是：因为它们在语义上最接近、在全文中命中了精确术语、属于当前业务域、带有关联标签、并且与当前任务的图锚点直接相连——五个维度共同决定。

前者是"找得到包含某个词的段落"，后者是"理解语义、遵守数据分类、识别标签、利用已有关系，并且只在允许的范围内装配上下文"。

十、四点关键发现

1. Token 降低来自"先判断，再装配"

不管是 SQLite 还是 Oracle，Token 的减少都不是因为数据库把文本变短了。原因只有一个——在模型调用之前，数据库已经完成了检索、匹配、判断和排序，只有最终 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 的全部实际运行场景，实验数据仅供参考。

老规矩，知道写了些啥。