如果你做过站内搜索、知识库问答或者正在给 AI 应用做召回管线一定遇到过这种尴尬文本检索的逻辑写在业务代码里向量存储塞进专门的服务数据同步还得靠一个维护成本不低的管道。几个服务来回倒腾线上稍有点波动搜索体验就肉眼可见地劣化。这篇文章要聊的是我在某知识库项目里做的一次检索架构改造——把文本检索直接集成到 AI 数据库中用一套引擎同时承担全文匹配、语义召回和元数据过滤。所谓 AI 数据库可以通俗理解为一个原生支持向量存取和相似度计算的数据库它往往还保留着关系模型的 SQL 能力所以我们能在一个库里同时表达“标题包含某个词”和“内容与某段话语义相近”两类检索需求。这次集成实践解决的核心问题有三个一是去掉检索服务和业务库之间的数据同步环节二是把召回延迟降下来三是让检索条件可以像写 SQL 一样精确控制。全文会覆盖选型逻辑、建表与索引设计、查询改造、性能实测以及我踩过的那几个坑。适合正在做 RAG 应用、社区搜索、文档知识库的开发者和数据工程师阅读。项目本身不算复杂但细节很多。如果你也想把检索能力收敛进数据库又担心会不会引入新的性能瓶颈这篇内容应该能给你一份比较实在的参考。1. 为什么要折腾「数据库内检索」先说原来的架构。项目里有一批文档数据包括标题、正文、标签、作者、更新时间这些字段。为了做搜索我们维护了一个独立的检索集群业务数据需要写一份到检索集群里查询时先查检索集群再拿命中的 ID 回业务库补全详情。这套结构在数据量小的时候问题不大但到了百万级文档、每天几十万次更新的规模几个问题就变得很棘手。第一是同步链路太长。业务库一条记录更新后要经过变更日志捕获、消息队列、消费者、批量写入最快也要几秒才能被检索到。某些重要资料修改完用户立刻搜索搜出来的还是旧内容。这个延迟在对外场景里会变成投诉。第二是数据一致性问题。消息积压、写入失败、重试顺序错乱都会让检索结果和实际数据对不上。查不到或者查到旧的都属于这类问题。第三是额外的基础设施成本。检索集群至少两三个节点加上配套的队列、看板、运维机制小团队维护起来相当累。那 AI 数据库给了什么新选项呢它把向量索引和普通字段索引放进同一个存储引擎里查询时可以在一条语句里同时完成关键词匹配、向量相似度计算、过滤排序和分页。最关键的是业务库本身有这个能力之后我们就不再需要跨系统同步数据了。写入时生成好向量和正文一起存进去查询直接走同一份数据实时性天然就是一致的。这不是说所有场景都应该这么干。如果你的检索有极高的并发要求比如百万 QPS 的通用搜索还是得靠专门的分布式检索集群。但如果你做的是企业知识库、文档问答、社区内容搜索这类的流量量级把检索集成到 AI 数据库里架构会简洁很多。我们改造完检索服务这个组件直接从架构图上消失了相关的数据管道也删了大半。这个减法带来的维护收益比性能优化更让我觉得值。还有一点容易被忽略文本检索和向量检索放在同一个数据库里意味着我们可以在写事务里同时控制数据和索引的更新。比如插入一条文档正文、向量、标签、状态都是同一条事务的一部分。这在之前的两套系统方案里几乎不可能做到因为跨系统的“事务”只能靠分布式事务或者对账复杂度高很多。集成之后数据模型上的完整性约束可以做得更细比如确保文档被标记为“已发布”那一刻向量必然已经写进去了。2. 检索能力拆开看全文、向量、混合召回各自管什么做集成前得先把“文本检索”这个词拆清楚。很多刚接触 AI 数据库的人默认“检索 向量检索”这是个容易走偏的认知。真实场景里向量检索远不是万能的。全文检索解决的是精确匹配问题核心是分词和倒排索引。用户搜“接口文档”系统把查询切词找到同时包含“接口”和“文档”的文档按词频、逆文档频率这些统计量算相关性。它的特点是精准、可控、可解释。搜索引擎这么多年用的就是这套机制BM25 是其中最经典的打分公式。向量检索解决的是语义近似问题。它把文本映射成稠密向量通过向量之间的余弦相似度或者欧氏距离来判断文本在语义空间里是否接近。它擅长处理“用户想表达的意思和文档里的字面说法不一样”的情况比如搜“买笔记本心得”能召回“选购轻薄本的真实体验”这类不包含关键词但语义相近的内容。代价是结果不可解释而且对词表外的专名、ID、型号这类内容很不敏感。AI 数据库里的文本检索通常两种都要支持。比如一个文档检索场景里用户搜某型号名称这种序列号式的查询必须靠全文匹配向量几乎提不了精度用户搜“为什么最近风扇声音变大”这种描述性查询就适合向量召回文字完全不同也能找到相关文档。只靠任何一种召回效果都会明显偏科。混合召回是这两条的协同方式。常见做法是分别做全文查询和向量查询各拿一批候选集然后用 RRFReciprocal Rank Fusion倒数排名融合合并。逻辑是某条文档在两种查询里排名都靠前权重就高。RRF 给每个文档算一个融合分公式是 score sum(1/(k rank))k 一般取 60。三种策略的定位差异我用一个表格总结集成时要根据业务类型定比例策略适用查询类型优势劣势全文检索型号、专名、精确词精确可控、延迟低无语义泛化同义词召回差向量检索描述性、口语化查询语义相关能扩召回精度看模型偶发不相关混合召回长尾、无固定规范查询兼顾精度和召回融合参数需要调查询稍重元数据过滤也经常被忽视。实际业务里检索往往不是全库搜比如只搜某个分类、某个状态、某个时间范围之后的内容。AI 数据库的巧妙之处在于元数据过滤可以和向量匹配在同一个执行计划里做比如先按标签把搜索空间缩小再跑向量距离计算。这一点比外挂向量检索服务做得自然得多——外部服务往往只能后置过滤效率差一个量级。3. 集成落地的完整步骤从建表到召回选型确定后落地过程分四步数据建模、索引配置、写入改造、查询重写。每一步都有值得展开的细节。3.1 数据模型字段怎么设计决定检索上限我的建议是检索用的表和业务详情表分离但存放在同一个数据库里。检索表存的是“参与召回”的字段宁缺毋滥不要一股脑把几十个字段都放进去。字段越多索引体积越大写入越慢。一个比较典型的检索表结构如下CREATE TABLE doc_search ( doc_id VARCHAR(64) PRIMARY KEY, title VARCHAR(500), content TEXT, category VARCHAR(32), status TINYINT, owner_id VARCHAR(32), updated_at TIMESTAMP, embedding VECTOR(768), -- 全文索引建议使用数据库自带的倒排索引配置 FULLTEXT KEY idx_tc (title, content) );有几个字段我特意做了区分title和content放在一起建全文索引因为常见的搜索都希望标题匹配获得更高权重如果数据库不支持按字段加权可以在查询时给 title 匹配额外加 boostembedding存语义向量维度由 embedding 模型决定比如 768 维category、status、owner_id用于过滤必须单独建普通索引尤其是 category 这种基数不大但高频过滤的字段。这里有个容易犯的错把 embedding 直接放在业务大表里。业务表字段多、变更频繁向量列会导致表变大且每次普通字段更新都要处理向量。合理做法是业务数据和检索数据同库不同表通过 doc_id 关联两表在一个库里查询时 join 依然很快数据同步的痛点依然不存在。3.2 索引选型HNSW 的参数不是默认就行向量索引主流选择是 HNSWHierarchical Navigable Small World。它检索快但内存占用和写入成本高还有个备选是 IVF 系列内存更省召回率调参略麻烦。小型知识库一般 HNSW 足够。HNSW 核心参数是 M 和 ef_construction。M 是每个节点的最大邻居数控制图的分支多少ef_construction 是构建索引时的动态候选集大小控制索引质量。我们线上配置过两组对比数据量约 150 万条 768 维向量Mef_construction构建耗时单查询 p95 延迟召回率 Recall1016200约 22 分钟约 18ms96.2%32200约 31 分钟约 25ms97.8%16100约 15 分钟约 15ms92.5%大部分生产系统没必要追求极致召回率M16、ef_construction200 是个很均衡的起点。如果查得很慢优先检查是不是把 ef_search 设得过高那是查询时的动态候选数调低可以显著提速但别调到召回率跌破预期线。距离函数按数据集选。文本 embedding 基本用余弦相似度如果 embedding 做过归一化余弦和点积等价选点积速度更快。欧氏距离场景很少除非你明确测试过它更适合你的数据。3.3 写入链路向量生成要异步但不能失控生成 embedding 是要调模型的比较耗时不能写在用户请求的主链路里。我们设计的是文档更新后写入一个待处理队列后台 worker 拉取内容、调用 embedding 模型、把向量一并写入检索表。要注意两点。一是幂等性worker 重复处理同一条变更不能导致数据错乱用 doc_id updated_at 做唯一约束能避免旧数据覆盖新数据的问题。二是失败重试要有上限embedding 服务偶发超时很常见连续重试三次仍失败就要落死信队列。我强烈建议在写入检索表时“带条件更新”只在数据的 updated_at 大于当前库里值时执行否则并发下旧任务可能覆盖新数据UPDATE doc_search SET content :content, embedding :embedding, updated_at :now WHERE doc_id :docId AND updated_at :now;写入后还需要定期做一次全量对账比如按小时扫描业务表对比 doc_search 的 updated_at把缺失或滞后的记录重新捞出来处理。这一步我们一开始没做后来线上出现了几条“永远搜不到”的文档才补上的。3.4 查询重写一条 SQL 完成混合检索查询阶段最核心的就是把关键词匹配、语义召回、过滤和融合写进同一个查询计划里。不同数据库语法差异比较大但思路是通用的先得各自的候选集再做融合、过滤、排序、分页。我呈现的是抽象后的查询逻辑不是具体语法1. 用全文检索条件在 title、content 上找候选集 A 2. 用向量余弦相似度在 embedding 上找候选集 B保留每个命中的排名 3. 按 RRF 融合 A、B得到混合分 4. 对结果应用 category、status、时间等过滤条件 5. 按融合分排序分页返回 doc_id 列表 6. 拿这批 doc_id join 业务详情表补全展示字段。实际查询时会有两个隐藏细节。一个需要过滤条件名前置先缩小候选范围再跑向量计算而不是等向量结果出来再过滤尤其当过滤条件能把数据量缩小一个数量级以上时查询延迟差别明显另一个是对混合分数做动态权重全文分和向量分不一定均衡可以通过各自标准化后再加权让均衡偏向某一方比如偏向全文更稳偏向向量更泛。跑了一段时间后我们形成了一个惯例凡是从线上用户日志里看到点击率下降的搜索词都去跑一次混合查询排查看是全文没召回还是向量没召回。这个检查方法效率很高顺手就能定位是模型问题、索引参数问题还是融合权重问题。4. 线上性能与效果实测数据说话不靠感觉改造最怕的就是“感觉快了”。这次我们做了比较完整的压测和效果评估记录几组关键数据。4.1 测试方法与数据规模为保证可比性我们用线上真实查询日志抽了 2000 条查询分别跑旧架构外部检索服务 同步链路和新架构AI 数据库内检索对比 P50、P95 延迟和召回率。数据集是约 150 万篇文档平均文本长度约 1800 字embedding 模型统一向量 768 维。评估分两种一是精确匹配指标抽样用户明确点了某篇文档看排序里它出现在第几名之前二是语义相关性指标人工标注某查询是否应该召回某文档。压测环境四个节点每个节点 16 核 64GB。混合查询占整体比例的 40%其余全文查询和向量查询各占 30%。先看结果表格指标旧架构新架构变化查询 P50 延迟62ms35ms降低 43%查询 P95 延迟215ms86ms降低 60%精确匹配 Top5 命中率42.8%46.5%提升 3.7pt语义相关 Top10 命中率61.2%66.9%提升 5.7pt数据可搜延迟秒级到分钟级秒内事务提交即可搜大幅缩短同步链路故障率周4~6 次0无需再同步延迟改善在意料之中检索从“跨网络 多跳管道”变成“单引擎本地计算”多了几个里程碑式的好处去掉同步等待、去掉结果回表网络开销、去掉额外路由。召回率的提升我归因于两块。一是全文字段权重可以做得更细title 命中权重比旧配置高精确匹配场景收益明显二是混合召回把向量结果并入排序旧结构虽然也有向量召回但融合是在应用层做的候选集取少了现在融合发生在查询计划内部候选集可以取更大召回率自然提升。4.2 按查询类型拆分结果全局平均会掩盖问题。同样这批查询拆成三类后差异很明显查询类型占比P95 延迟Top10 语义命中率精确词查询型号、编号25%22ms49.8%描述性自然语言查询45%94ms75.6%长短句混合词描述30%108ms66.2%精确词查询的爆发点靠全文索引延迟最低纯描述性查询基本依赖向量索引延迟上了 90ms 也够用混合类型因为要同时跑两种召回再做融合延迟最高但命中率并没有比纯描述性下降太多值得接受。这个拆分让我意识到不能把所有查询的无脑都走上混合路线可以预判查询特征做轻量路由明显含专名代码的请求走全文优先明显口语化的请求走向量优先只有不好判断的才走完整融合。4.3 资源成本观察延迟好看是一回事机器成本也要算账。改造后检索组件和同步管道删掉换来的是数据库节点内存变大——主要因为 HNSW 索引要驻留在内存里。150 万条 768 维向量粗略估算向量本身约 4.6GBHNSW 的图结构为 M16 时约增加 2~3GB整体内存增量在 8GB 左右。四个节点平均每个节点多了约 2GB 占用完全可以接受。对比原来的检索集群至少省了 30% 的机器预算还省了大量维护时间和排障次数。不过我也得提醒一句如果向量数据过亿内存成本要重新测算必要时用分段索引或量化压缩策略这属于另一个课题。5. 集成路上的五个深坑与完整排查链路这部分才是实践里最有价值的部分。方案看着简洁坑全是隐性的。我按实际发生顺序复盘每个坑都给出触发现象、排查路径和修复方式。5.1 索引滞后新文档几小时搜不到现象文档管理后台显示某资料已发布但前台搜索不到。一开始以为是 normal 的写入延迟结果等了半小时还没有。排查链路先查数据入库状态SQL 直查 doc_search 表发现根本没有记录查待处理队列消费进度发现消息已经消费但下游 worker 报错查 worker 日志发现 embedding 服务超时后重试三次失败消息被转入死信队列死信队列没有配置告警和补单机制所以数据静默缺失。修复方案为死信队列加告警和人工重放入口worker 增加指数退避重试避免高峰期集中重试压垮 embedding 服务。后续还补了每小时对账任务从业务表全量扫描缺失记录双保险。这个坑告诉我们即使架构上消除了“同步”写入链路里仍然有异步环节任何队列丢失、失败未重试都会导致数据不一致。数据库内集成的优势是“数据层一致”但应用层的异步链路还是得认真设计。5.2 中文分词效果差查“数据库”搜不到“数据库系统”现象部分文档明明包含用户搜索的关键词但全文检索召回率偏低。排查链路拿一条目标文档直接执行关键词匹配查询确认真的召回不到查看该文档在全文索引里的词条切分结果发现内容被按单字切分“数据库系统”被切成“数据”“库”“系统”没有保留“数据库”这个完整词条查看查询侧分词发现“数据库”三个字又被切成了单字导致两个方向的词条根本对不上。修复方案给全文检索配置更智能的中文分词器同时维护一个业务专名词典把产品名、领域术语、通用组合词加进去。我们花了一下午把项目里的高频词全部捞出来整理成自定义词条效果立竿见影。排查慢还有一个原因分词器的配置错了一个参数自定义词典没有被加载这个以后需要用测试语句专门验证分词结果而不是直接看检索效果。5.3 融合权重失衡全文命中把语义结果全部挤掉现象用户搜描述性语句排名前几全是机械命中个别字的旧文档语义上相关的文档反而排在后面。排查链路把全文检索候选集和向量检索候选集分别查询单独看都正常打印混合后的融合分数发现全文查询的原始相关分跨度很大向量相似度分数集中在 0.75~0.85直接套 RRF 时全文候选的排名普遍靠前因为任一关键词命中就可能拿到较好的全文排序位置但语义相关文档没有关键词命中全文排名很差权重被压制。修复方案首先是归一化全文分先做 min-max 标准化再参与融合然后给 RRF 里向量候选集的 k 值调小让向量结果更容易靠前最后保留一个业务侧开关针对特定分类可以调融合偏向比如代码文档偏向全文、经验帖偏向向量。这种问题没法一次调到位需要配合线上搜索词的点击反馈持续迭代。我们后来做了一个简易的 A/B 方案同一查询出两组结果一组融合比例 0.5一组 0.6按点击率取优。自动调权重是后面的事先手动把流程跑起来再说。5.4 过滤器位置写错字段过滤后召回数量暴跌现象某分类下检索结果数量明显少于预期明显是数据量不对。排查链路统计该分类下的文档总数执行不带过滤条件的检索返回数量正常加上过滤条件后数量暴跌查看查询计划发现优化器把过滤条件放在向量检索之后执行——这等于先在全库做最近邻搜索再从少量结果里过滤自然容易把该分类的文档全部漏掉。修复方案显式调整查询计划让过滤条件作为索引检索的前置约束或者把过滤字段放入分区键。在 AI 数据库里尤其要注意向量索引和普通字段索引的执行顺序由优化器决定时不一定符合直觉。如果发现过滤后的召回异常变少优先检查这个。5.5 多租户环境下索引重建抢占资源现象某个租户触发向量索引重建导致整个库的查询延迟剧烈抖动。排查链路延迟抖动的时间窗口和索引重建窗口重合看系统指标发现 HNSW 构建期间 CPU 和内存占用明显上涨确认问题根源是索引构建任务没有做资源隔离。修复方案把重建任务改成低优级队列只在特定时段执行如果数据库支持给构建任务限流再不行就分区逐段重建避免一次性全量刷。平时也要准备索引重建演练因为 embedding 模型升级或新增字段很可能需要全量重建没有预案的话线上就会被动。这条经验后来被推广到了所有管理类操作凡是跟索引、统计信息、后台任务相关的都先跑演练再上生产。6. 从这次改造里沉淀下来的几条复用经验项目做了三个月踩了一堆坑沉淀的几条经验已经复制到其他两个项目里这里一并分享。第一个经验是凡是涉及检索改造先搭好召回评估的链路再动手不要上来就动代码。我们把线上用户点击日志中的搜索词和最终点击文档收集起来做成离线评估集。每次调参数先在这套评估集上跑分数看到至少 1 个百分点的提升再上线。这个习惯看着朴素但避免了无数次的“感觉好一点”导致上线后又回滚。第二个经验是全量重建索引永远要有预案。embedding 模型升个版本、维度变一下、新增业务字段都可能触发全量更新。我们为此总结了一套标准操作流程容量评估、低峰执行、分段推进、每段校验召回率、失败自动回退到旧索引。由于之前没有预案踩过坑以后才补上现在我建议任何用 AI 数据库的项目都先把这套流程做进发布手册。第三个经验是查询日志就是最好的数据资产。我们把每次检索查询的语句、候选集大小、最终展示排序、用户点击位置全部落日志。后来做检索质量分析、调融合权重、发现分词问题全靠这些日志。没有这套日志很多坑都只能靠用户投诉才暴露太被动。第四个经验是不要迷信向量检索。向量化确实能提升语义召回但精确词、型号、编码、多语言混合的内容仍然要依赖全文索引。把两者同时做进去只是开始让不同查询走不同的路径才是最终形态。最后补一句运维层面的话AI 数据库的运维逻辑和传统数据库不完全一样建索引、查计划、看资源消耗都有新的概念。项目上线前团队里至少要有一个人能把 HNSW 参数、embedding 模型版本、索引构建机制讲清楚否则出了问题只能干瞪眼。这次集成改造的整体收益坦白说比我预想的好。它不是把某一项指标拉满而是把架构做简单了——同步没了、跨服务调用没了、排障链路短了。架构简单带来的稳定性提升往往比单点优化更值钱。后面我们还打算做一层轻量的重排模型直接挂在查询后把混合召回的粗排结果再精排一遍那是另一个工程问题了。