暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

DB4AI,到底需要做些什么能力?

白鳝的洞穴 2025-08-15
275
和很多国产数据库厂商谈到DB4AI,最终谈的都是向量数据库,在数据库中集成向量能力也并非难事,那么多开源的项目存在,似乎一下子让大多数国产数据库都已经很全面的支持了向量计算,同时都具备了向量、标量融合计算的能力,我想再过几年,标量、向量融合计算能力将会是所有关系型数据库的标配,独立的向量数据库也会变得可有可无了,因为向量计算所需要的基础能力大多数在交易型关系数据库中都具备并且十分完备,完全可以复用这些能力。独立的向量数据库要补全OLTP的能力则要难得多。
虽然很多国产交易型数据库虽然都集成了向量数据库的能力,也都支持了标量向量融合查询,不过向量标量混合重排的能力就要看各自的算法优化能力了。而更深层次的能力在国产数据库的内核中还没有看到,我和一些国产数据库厂商的朋友都讨论过,他们可能都不知道DB4AI,下一步该干点啥。
我在思考这个问题的时候,好像又回到了三十年前。当年我从RMS、TMS这种简单高效的记录管理型和交易管理型数据库迁移到关系型交易库上,是因为SQL处理数据的便捷性。因为有了SQL,就不需要花太多精力去设计内存管理、排序、连接等操作算法,哪怕一个受过编程训练的中专生都可以完成软件开发的工作了。这是关系型数据库会在信息化建设过程中大行其道的关键因素。
回到现在,很多企业都准备开发AI应用,但是AI应用中的一些虽然比较粗浅的门道,还是把很多正在从事这方面开发工作的程序员挡在了门外。我前几天和一个大行的开发人员交流AI应用开发的时候,他们十分关注的一些问题,大都是一些AI开发上门槛级别的问题。这些问题很基础,又很关键,没有真正干成功过一两个项目还真的容易踩坑。如果向量数据库能够像当年提供SQL一样,让AI应用开发变得更简单,那就是很有价值的一件事情。
想要做好这件事并不容易,因为标量计算引擎和向量计算引擎目前在绝大多数数据库中还是相对独立的,数据库服务器中也没有标配GPU,所以在一个服务中深度融合两种计算还是有难度的。不过谁规定了今后数据库服务器中不是必须配备GPU的?现在的数据库服务器上的很多必备的硬件,也不是3、40年代的服务器上都必须有的。融合计算所需要的两个引擎在核心层面的高度融合是未来必须要去做的。
目前标量计算和向量计算两路计算之后的rerank效率和效果都是妥协的结果,标量过滤和向量过滤的不确定性是目前很多AI开发者比较头痛的问题。哪怕在一些特别明确的场景中也无法很好的获得到高质量的返回结果。我们只能加大TOP N,来增加召回的充分性。前两天我突发奇想,能否在hnsw索引上动动脑筋,让hnsw具有标量向量混合索引的能力。比如我想检索移动5G/4G的知识库,4g/5g的资料是完全分离的,在创建HNSW索引的时候,能不能添加一个网络类型的字段,根据这个字段创建2个完全不同的子图,想搜索5g资料的时候走5g的子图。如果HNSW索引有这种功能,那么我就没必要把这些数据分表存放了,数据架构和应用都会变得优雅得多。
再进一步,向量标量多路召回后的rerank能不能在SQL引擎里就完成了,开发人员不需要去学习复杂的技术,只需要简单地写下SQL就可以完成这些工作了?我想DB4AI可以做的事情还是很多的。

文章转载自白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论