国产新秀 HaloDB 连载 4｜AI 内生:把大模型塞进数据库内核
digoal约 9 分钟TAG: #HaloMRT #内生智能 #RAG #向量数据库 #Graph-Transformer #TEXT2SQL #召回精排一体化 #实时向量化 #AI数据平台
过去两年,大模型应用落地的主旋律一直是"RAG"——检索增强生成。
工程师们搭起一套标准化的 RAG 架构:业务数据存到关系数据库里,需要喂给大模型时先用 embedding 模型向量化,存到专门的向量数据库集群,然后用户提问时召回相似片段,丢给 LLM 生成回答。这套架构在原理上很漂亮,但在生产环境里,工程师很快会发现一个让人头疼的问题——数据在多个系统之间反复搬运,延迟、安全性、一致性,每一个都是坑。
Halo 给出的解法思路和大多数厂商不一样:把 AI 模型运行时直接嵌入数据库内核,让数据库自己就是 AI 数据处理平台。
这篇文章拆开讲讲这条路到底走不走得通——以及它解决了哪些传统 RAG 架构的"传输税"问题。
在拆 Halo 的方案之前,先理解传统架构到底"贵"在哪里。
一个典型的企业级 RAG 系统,数据要流过这些节点:
业务系统产生数据 → 写入关系数据库(Oracle/MySQL) ETL 把数据搬运到数据仓库 → 清洗、转换、聚合 embedding 模型对每条数据向量化 → 调用外部模型服务(OpenAI、本地 vLLM 等) 向量数据存入向量数据库 → 单独的集群(专业的开源向量库) 用户提问时召回 → 向量数据库先检索出 Top-K 候选 精排模型重排 → 调用另一个外部服务(Cohere / BGE-reranker) 最终结果丢给 LLM 生成答案
数据在这条链路上要经历 5-6 次跨系统搬运,每一次搬运都带来三个成本:
延迟:每次跨系统调用 50-200 毫秒,加起来就是 0.5-1.5 秒的用户等待 一致性风险:源数据更新后,向量数据可能滞后几分钟甚至几小时;不同步导致 LLM 给用户过时答案 合规风险:数据在多个系统里存多份,任何一个系统的访问控制漏洞都是泄漏点
这是当前 AI 应用落地的"基础设施税"——每一个能力(向量化、检索、重排)都要单独的集群、单独的运维、单独的故障点。
二、Halo 的解法:把 AI 模型运行时塞进数据库内核
Halo 在架构上做了一个激进的选择——把 AI 模型运行时(Halo MRT,Model Runtime)直接嵌入数据库内核。
"嵌入内核"这件事的工程含义,远不是"在数据库里多装几个 Python 库"那么简单。它意味着:
向量化模型在数据库进程内运行,不需要拉起外部服务进程 embedding 推理和 SQL 查询走同一套内存管理,不需要数据拷贝 模型加载、版本管理、推理调度都在数据库内核调度器的统一掌控下
这件事带来的三个直接收益:
第一,延迟数量级下降——embedding 调用从"跨进程网络调用"变成"数据库内部函数调用",从 50-200 毫秒降到 1-5 毫秒。
第二,数据零搬运——业务数据写入数据库时,触发器可以在同一次事务里完成向量化,向量和原始数据永远在同一个库里、同一份存储上。
第三,运维统一——DBA 原来要管"关系数据库 + 向量数据库 + embedding 服务 + 重排服务"四个系统,现在只需要管一个数据库。
可行性报告 V5 §3.4 用了"内生智能计算"这个词来描述这套架构。它的核心不是"加一个新功能",而是"重新定义数据库是什么"——从"存数据的地方"变成"数据 + AI 推理的统一底座"。
三、Halo MRT 的四个核心能力
把"AI 嵌入数据库"这个抽象概念拆到工程实现,Halo MRT(Model Runtime)由四个具体能力组成。
能力 1:实时向量化
传统 RAG 架构里,数据从业务库搬到向量库,需要单独的批处理任务(每天跑一次或每小时跑一次)。这意味着业务数据进入数据库后,可能要等几小时才能在向量检索里被搜到。
Halo MRT 的实时向量化把这个流程彻底打掉:数据写入数据库的那一刻,触发器在同一个事务里调用 embedding 模型,生成向量并存到同一个表的隐藏列里。
效果是:业务数据入库即向量化,用户检索时永远拿不到过时数据。
性能数字(来自 Halo 优势 v2.2 的实测对比):数据量化效率至少提升 1 倍以上。一倍听起来不多,但考虑到向量化往往是 RAG 链路里 CPU 最密集的环节之一,这一倍意味着同样硬件可以撑两倍的吞吐量。
能力 2:召回精排一体化
传统 RAG 的另一个性能杀手是召回和精排的两次独立调用——向量数据库先做粗筛(召回 Top-100),然后精排模型对 Top-100 再打分排序(精排 Top-10)。
这两次调用走的是不同的服务、用的是不同的数据结构,中间要序列化/反序列化结果数据,延迟叠加是必然的。
Halo MRT 把这两步合并:向量检索的 SQL 查询里直接嵌入精排模型的推理,召回和精排在数据库内部一气呵成,中间结果不需要在内存里来回拷贝。
效果:Halo 优势 v2.2 给出的实测对比,召回精排一体化效率至少提升 1.5 倍。同时,因为中间结果不出数据库,数据"足不出户",安全性也大幅提升——这是金融、政务客户最在意的点。
能力 3:智能关系生成(Graph-Transformer)
这是 Halo MRT 里最有"前瞻感"的一个能力。
它的起点是这样一个观察——大模型对结构化数据的理解,主要障碍是"不懂数据之间的关系"。一个 LLM 看一张订单表,它知道"金额""客户 ID""产品 ID"这些字段名,但它不知道"订单的金额汇总后构成客户的累计消费,客户的累计消费决定了他的会员等级"。这些关系在 SQL 里是隐式的(需要 JOIN、子查询、聚合函数才能表达),LLM 直接拿数据是看不到的。
业内有一篇被引用很多的论文 Matthias Fey et al. 2023 的 Relational Deep Learning: Graph Representation Learning on Relational Databases 直接指出:大模型不理解关系数据库里的数据关系,这是它在企业级场景落地的核心瓶颈。
Halo 的 Graph-Transformer 架构在数据库内核里解决这件事:自动分析数据库的元数据(外键约束、索引、表结构、查询历史),构建出一张"数据关系图",然后让数据库能够基于这张图做更智能的查询和推理。
举个例子:用户问"上个月销售额最高的客户,他买了哪些产品?",LLM 自己答不上来,因为它不知道"销售额"需要 SUM(订单.金额)、需要 JOIN 客户表、需要 ORDER BY 排序。
如果数据库能自动把"客户-订单-产品-销售额"这条关系链预先构建好,LLM 拿到的就不是"一张表的数据",而是"一张关系图",它就能直接生成正确的 SQL。
可行性报告 V5 §3.4 把这个能力的目标总结为"为复杂的数据分析和查询提供强大的支持,最终实现自动发掘数据的价值"。
能力 4:TEXT2SQL 优化
这是最贴近"日常应用"的能力。
TEXT2SQL(把自然语言转成 SQL)是当前最热的 LLM 应用方向之一——用户输入"上个月销售额最高的客户",LLM 输出对应的 SQL。
但 TEXT2SQL 有一个"交互成本"问题:LLM 要先看数据库的 schema(表结构)才能写出正确的 SQL,而 schema 信息往往很大(几百张表),每次都完整塞给 LLM 会浪费大量 token。
Halo MRT 的解法:数据库预先把 schema 摘要、数据关系图、常用查询模式都准备好,LLM 只在需要的时候查询这些"预消化"过的元信息,而不是每次重新读取整个 schema。
效果:TEXT2SQL 减少了与大型 LLM 的交互次数,从而降低了资源消耗并提升了系统整体效率。这意味着企业可以用更小、成本更低的 LLM 模型(甚至是本地 7B/14B 模型)来完成原本需要 GPT-4 级别模型才能做好的 TEXT2SQL 任务。
四、流媒体与多模态:为机器人时代铺路
上面四个能力处理的都是结构化数据(表 + 向量)。Halo 还在做一件更前瞻的事——把数据库扩展到流媒体数据的处理。
当前主流的关系数据库,擅长处理数字、字符串、日期这些结构化数据,但对视频、音频、图像、文档这些非结构化数据基本无能为力。这些数据要么存在文件系统里、要么存在 OSS/MinIO 这类对象存储里,数据库只存它们的"指针"(路径),不参与实际处理。
Halo 在优势 v2.2 里明确指出,正在"创新性设计统一的数据处理架构,特别是针对视频、音频等流媒体数据的实时处理"。
战略意图很直白——机器人的未来需要数据库能处理"眼睛看到的"(视频)、"耳朵听到的"(音频)、"触摸感知的"(传感器数据),而这些数据的统一存取 + 实时向量化 + 关系推理,需要一个真正"全模态"的数据库。
这一块在可行性报告 V5 里被标记为"规划中",但方向已经清晰:Halo 不只做"AI 时代的关系数据库",而是要做"AI 时代的全模态数据基础设施"。
五、对 AI 应用开发者的实际意义
如果你正在或打算做 AI 应用(智能客服、知识库、Agent、RAG 系统),Halo 的 AI 内生能力能在哪些场景下帮你?
第一,如果你正在为"向量库和关系库数据不同步"的问题头痛,Halo 的实时向量化直接消除了这个数据不一致源。
第二,如果你的 RAG 系统里"召回后精排"的延迟占了总响应时间的 30% 以上,Halo 的一体化召回精排能直接砍掉一半。
第三,如果你打算做企业级 TEXT2SQL(让业务人员直接用自然语言查询数据),但被"大模型成本太高"拦住,Halo 的元数据预消化能让你用 7B 模型做到之前 70B 模型的效果。
第四,如果你的场景是"AI Agent 需要访问多个数据库",传统架构里 Agent 要分别对接关系库、向量库、embedding 服务等多个 endpoint,代码极其复杂;Halo 的统一内核让 Agent 只需要对接一个 endpoint,所有能力在一个 SQL 接口里完成。
一个具体的例子:一个企业知识库 Agent 要回答"上个月华东区销售额最高的客户,以及他最近一年的产品偏好"。传统 RAG 架构下:
先从业务库查"上个月华东区销售额最高客户" 再去另一个 embedding 服务做"该客户最近一年所有产品评论的语义检索" 把结果拼起来给 LLM
在 Halo 内核里,Agent 只需要写一个 SQL 调用,"实时向量化 + 召回精排一体化 + 智能关系生成 + TEXT2SQL 优化"四个能力在数据库内部一气呵成,Agent 拿到的就是最终答案。
这是从"RAG 拼装"到"AI 数据平台"的范式转换。
六、回到主理人的视角:为什么这一篇值得展开
前面四篇我们聊了信创背景、架构、传统创新技术、性能对标——这些是 Halo"硬"的一面。
这一篇我们看的是 Halo"软"的一面——它能不能适应 AI 时代的应用形态。
答案从可行性报告 V5、产品优势 v2.2、产品介绍 v6.6 三份资料来看是肯定的:Halo 不是把向量检索当附加功能塞进传统关系数据库,而是从内核层就把 AI 模型运行时纳入设计。
这件事的战略意义是:当其他国产数据库还在做"兼容 Oracle"这场 2010 年代的仗时,Halo 已经在打"AI 时代数据库长什么样"这场 2020 年代的仗。
它未必每一项能力都是业内最强(向量检索领域有专业的开源向量库玩家;TEXT2SQL 也有专门的开源工具),但把这些能力整合在一个内核里、提供统一的 SQL 接口,这是它差异化的地方。
下一篇,我们看三个真实标杆案例——南京证券、金税三期、天安财险,看 Halo 是怎么把这些架构和性能数字,在客户的真实生产环境里"打出来"的。