OceanBase团队开源了seekdb，把向量搜索、全文检索和关系过滤塞进同一个查询里。更意外的是，他们把融合排序和重排逻辑也搬进了数据库内部——这套代码完全公开在GitHub上。
为什么搜索成了"拼接游戏"
现在的RAG系统通常要跑三个地方：向量库存语义相似度，全文库存关键词匹配，应用在中间做分数融合和重排。每个环节都是一次网络跳转，"仅该用户数据"这类过滤条件要在两套系统里各写一遍。
seekdb的解法是一张表同时建向量索引和全文索引。一次查询扔进去向量条件、文本条件、关系过滤，数据库内部做完融合排序直接返回结果。
好处很具体：过滤条件只定义一次，不会出现"向量侧过滤了、全文侧没过滤"的漂移；省掉应用层的融合跳转，延迟压进数据库内部；胶水代码可以删掉大半。
SQL层用DBMS_HYBRID_SEARCH.SEARCH()，填full_text_query、vector_query和可选的关系过滤。Python SDK的hybrid_search()更灵活，能给向量和全文分别设top_k，支持过滤表达式。
融合默认用RRF（倒数排名融合），把向量相似度和全文分数合并成统一排名。建表时需要VECTOR列配VECTOR INDEX，文本列配FULLTEXT INDEX，插入时双索引自动更新，没有额外同步步骤。
调参空间也公开了：向量侧控制top_k和相似度阈值，全文侧调分词和匹配模式，RRF合并时关注两侧结果比例防止一方碾压。社区反馈显示，语义+关键词混合比纯向量或纯全文更稳，特别是处理专有名词、数字和代码时。
AI函数：把"检索-重排-生成" pipeline收进数据库
混合搜索只是RAG的前半段，后面还有嵌入、重排、大模型。seekdb的AI Functions把这些也往里搬：写数据或查数据时直接调库内嵌入和重排，甚至能跑LLM推理和提示词处理。
嵌入可以在写入时向量化，也可以在查询时实时算，不用从应用层调外部API。重排模型同样内置，检索结果在库内完成精排再往外返。
整个"检索→重排→生成"的链条被压短，部分逻辑常驻数据库。对延迟敏感的场景，这意味着少跳几次网络；对架构复杂的系统，这意味着少维护几条服务依赖。
这套机制的代码和RRF融合逻辑一样，全在GitHub仓库里公开，可以审阅、修改、提PR。
开源姿态背后的产品判断
seekdb选择把核心机制开源，而不是封装成黑箱服务。这个决策本身说明了几件事：
第一，混合搜索的融合逻辑还没有形成行业标准，RRF是常用方案但不是唯一方案，开放出来让社区迭代比闭门造车更快。
第二，AI Functions的边界正在重新定义。数据库 traditionally 管存储和检索，现在把嵌入、重排、甚至LLM推理也纳入职责范围——这不是功能堆砌，而是对RAG架构瓶颈的回应：网络跳转和系统拼接的代价，在 latency-sensitive 场景里越来越难以忍受。
第三，OceanBase作为分布式数据库的老玩家，选择用seekdb这个独立项目探路AI原生能力，而不是直接改造主产品线。这种"卫星项目"策略降低了试错成本，也让社区反馈能更快回流。
从社区已有的体验反馈看，混合搜索在专有名词和代码场景下的稳定性提升是真实可感知的。这不是理论优势，是实际跑出来的结果。
seekdb目前开源在GitHub，文档覆盖了从建表、调参到RAG集成的完整路径。对于正在搭知识库或RAG系统的团队，值得花半天时间跑一遍示例——省掉的胶水代码和网络跳转，换算成工程人力和用户体验，数字会很直观。
热门跟贴