大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
做过RAG落地的团队，对外挂架构的延迟应该有切身体会。
一次语义检索，数据流是这样的：应用层向关系库发一条SELECT拿业务上下文，拿到结果后在应用代码里组装请求，再发给向量库做相似度匹配，向量库返回Top-K，应用层再拼装、再喂给大模型。两次跨进程网络往返，两次结果集序列化。
延迟从毫秒级起步，链路越长，抖动越大。更麻烦的是，关系库的数据和向量库的索引如果同步不及时，大模型拿到的是旧上下文，回答的口径就是错的。
金仓在2026产品发布会上提出的“库内计算推理”，要解决的就是这条链路上的结构性浪费。核心逻辑可以概括成一句话：不是让数据去找计算，而是让计算去找数据。
一、外挂方案的链路成本：两次往返，两次序列化
把外挂方案的执行路径拆开，延迟的来源一目了然。
第一段：应用 → 关系库。SELECT业务上下文，结果集经网络返回应用层，反序列化。
第二段：应用 → 向量库。应用层组装请求，发给独立的向量库进程（或服务），向量库在HNSW或IVF索引上做相似度检索，Top-K结果再经网络返回，再反序列化。
第三段：应用层拼装。关系上下文和向量结果在应用代码里做关联，再组装成大模型能消费的格式。
两次网络往返、两次序列化/反序列化，再加上向量库本身的检索耗时。更隐蔽的成本是一致性：关系库和向量库是两套独立的写入路径，同步延迟决定了模型拿到的上下文“新鲜”到什么程度。
二、库内计算推理的工程路径：把ONNX Runtime装进内核
金仓KES AI数据库的做法，是把AI推理能力下沉到数据库进程内部，而不是在外部挂一个推理服务。
技术实现上，关键组件是内核原生集成的ONNX Runtime。ONNX是AI模型的通用交换格式，把ONNX Runtime嵌入数据库内核，意味着模型可以直接在数据库进程内运行，不需要把数据导出到外部的Python进程或推理服务。
数据流因此变了：数据不出库，模型进库。SQL执行引擎在需要做推理的环节，调用内核内的ONNX Runtime完成计算，结果直接返回给执行计划的下一步。
三、算子融合：关系过滤和向量计算在同一条执行计划里
更关键的一层是算子下推（Operator Pushdown） 。
传统方案中，关系过滤和向量检索是两个独立系统各自完成、在应用层合并。库内融合后，优化器把AI相关的计算指令（向量距离计算、相似度排序）直接下推到数据库执行引擎中，和关系过滤算子进入同一个物理执行计划。
一条SQL可以同时表达两类条件：
SELECT id, content, vector_distance(embedding, :query_vec) AS score
FROM knowledge_base
WHERE tenant_id = :tenant AND category = '技术'
ORDER BY score
LIMIT 5;
tenant_id和category的过滤在关系引擎中完成，vector_distance和排序在向量算子中完成，但它们在同一个执行计划里协同，由统一的优化器生成全局物理计划。
带来的直接收益：
-
消除两次网络往返：从“应用→关系库→应用→向量库→应用”变为“一次SQL执行”。
-
消除应用层序列化：结果集以数据库原生格式返回，不需要在应用代码里做中间拼装。
-
事务级一致性：关系数据和向量数据在同一事务边界内，模型拿到的上下文和业务表在同一快照下。
四、延迟降低的工程解释
发布会给出的数据是查询延迟降低80%。从架构上拆解，这个收益来自三个环节的叠加：
第一，网络往返归零。 两次跨进程往返被消除，对于同机房部署，单次往返的延迟在亚毫秒到毫秒级，两次往返加上排队和序列化，累积效应明显。
第二，计算并行化。 ONNX Runtime和数据库执行引擎共享同一套并行计算资源。向量距离计算可以像聚合函数一样利用数据库已有的并行能力，而不是依赖独立的向量库进程去管理自己的线程池。
第三，消除了“数据搬运”的时间窗口。 外挂方案中，关系库的上下文要先返回应用层，再发给向量库。中间这段“在应用层等待”的时间，在融合方案中不存在。
五、边界：不是所有查询都能融合
库内计算推理有明确的能力边界。优化器会根据代价选择是否下推AI算子，不是“写了就一定融合”。如果向量索引没有覆盖过滤条件，或者模型推理的开销超过了网络往返的节省，优化器可能仍然选择分步执行。
另外，ONNX Runtime集成的是推理，不是训练。库内计算推理解决的是“模型在数据旁边跑推理”，不是“在数据库里训模型”。
六、小结
外挂向量库的延迟根因不在“向量检索慢”，在链路上的两次网络往返和两次序列化。库内计算推理把ONNX Runtime嵌入数据库内核，把向量相似度计算作为执行计划中的一个算子，与关系过滤算子协同下推。延迟降低80%的工程解释是：网络往返归零、计算共享并行资源、数据搬运的时间窗口消失。范式转变的核心不是“更快的向量算法”，是“计算向数据移动，而不是数据向计算移动”。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
