I1：AI 原生数据库基础

Easy Data x AI 课程 · 产业应用篇 · 第 1 节

本节定位

本节建立 AI 原生数据库的能力框架，重点回答“AI 应用为什么仍然需要数据库”以及“什么样的数据底座更适合 Agent”。向量检索、AI Functions 和 AI 列的实现细节将在 I2、I3、I5 中展开。

学习目标

完成本节后，你将能够：

1. 解释 Agent 的数据需求为什么不等同于“保存聊天记录”或“接一个向量数据库”；
2. 从数据、检索、事务、AI 调用、试验工作流和部署形态六个维度识别 AI 原生数据库；
3. 说明关系、向量、文本、JSON 等数据统一管理的价值与代价；
4. 画出从用户查询到混合召回、融合、重排的完整链路；
5. 判断一个场景应采用统一数据库、组合式架构，还是暂时不引入专门的数据系统。

1. AI 时代，为什么还需要数据库？

大模型擅长从上下文生成结果，却不会天然保存可靠、可查询、可恢复的业务状态。一次模型调用结束后，应用仍然要回答一组传统但关键的问题：

• 用户、订单、权限和任务现在是什么状态？
• 回答依据来自哪份文档，是否仍然有效？
• 某条记忆由谁写入，何时更新，能否撤销？
• Agent 试写的数据是否应进入主数据？
• 服务异常后，已确认的操作能否恢复？

因此，模型推理并没有取代数据库。恰恰相反，Agent 把数据库从“保存最终结果”的后台组件，推到了检索、推理、工具调用和状态修正的过程中。

1.1 Agent 能力建立在数据之上

一个典型 Agent 可以拥有 RAG、记忆、技能和工具调用能力，但这些能力都依赖数据层：

Agent 能力	依赖的数据	数据层需要保证什么
RAG	文档、分段、向量、来源、权限	召回相关内容，并保留证据与访问边界
长期记忆	会话、实体、事实、偏好、时间	可更新、可遗忘、可追踪、可消除冲突
任务执行	计划、步骤、工具输入输出、状态	多步操作的一致性、幂等性与恢复能力
业务决策	用户、订单、库存、规则	精确查询、事务约束与最小权限
试验与修正	候选方案、临时修改、评估结果	隔离试写、比较差异、选择性采纳

模型提供的是概率性的推理能力，数据库提供的是持久状态、事实约束和可恢复性。两者解决的问题不同，但必须协同工作。

1.2 三个独立系统带来的隐性成本

一种常见架构是同时使用关系数据库、向量数据库和搜索引擎。它在大型、专业化负载下可能是正确选择，但应用层必须额外处理：

• 数据在多个系统间复制，产生同步延迟；
• 业务记录已提交，而向量或全文索引尚未可见；
• 权限、租户、时间等过滤规则需要在多处重复实现；
• 多路召回结果需要在应用层拼接、去重和排序；
• 备份、恢复、监控、容量和故障处理的对象变多。

这里的关键不是“系统越少越好”，而是认清拆分的成本。只有当独立系统带来的专业能力或规模收益大于同步与治理成本时，拆分才值得。

2. 什么是 AI 原生数据库？

“AI 原生”不是指数据库内置了一个大模型，也不意味着所有 AI 逻辑都应该写进 SQL。更有用的判断方式是：数据库是否围绕 AI 应用的核心数据流，提供可组合、可治理的原生能力。

本课程将 AI 原生数据库概括为六个观察维度：

维度	关键问题
多类数据	能否共同管理关系、向量、文本和半结构化数据？
混合检索	能否组合语义召回、关键词召回和业务过滤？
事务与恢复	AI 相关数据能否与业务状态保持一致并在故障后恢复？
模型调用	能否在靠近数据的位置管理嵌入、重排和生成调用？
Agent 工作流	是否支持隔离试验、差异检查和受控采纳？
交付形态	能否适应本地、嵌入式、服务器和跨平台部署？

不要把“AI 原生”当作单一产品标签

一个系统满足的维度越多，不代表它一定更适合你的场景。正确的选型仍要结合数据规模、延迟、写入频率、一致性、团队经验、成本和运维边界。

3. 从应用到底层：理解统一数据库架构

以 seekdb 这一类统一数据库为例，可以把整体架构自上而下分为六层：

1. 应用与工具层：Agent、RAG、智能业务应用以及既有 MySQL 应用；
2. 统一接入层：MySQL 协议、SQL、常见语言驱动和多语言 SDK；
3. 查询、检索与 AI 层：SQL 解析、优化、执行，混合检索、AI 函数和 Agent 数据工作流；
4. 数据与索引层：关系、向量、文本、JSON、GIS，以及 B-Tree、全文和向量索引；
5. 事务与日志层：ACID、MVCC、Redo Log、故障恢复和数据分支；
6. 持久化存储层：MemTable、SSTable、Compaction、缓存和持久化空间。

这套分层的重点不在于记住每个组件名称，而在于理解三条贯穿全栈的主线：

• 同一份事实数据可以被精确查询、语义检索和关键词检索；
• 同一个事务边界可以同时约束业务字段和 AI 相关字段；
• 同一条执行链路可以先缩小数据范围，再调用昂贵的外部模型。

3.1 SQL 为什么仍然重要？

AI 应用并没有取消精确查询。租户、权限、状态、价格、时间和地域等约束仍然更适合用结构化表达。SQL 的价值在于把这些约束与检索组合起来，并交给查询优化器选择执行路径。

例如，一次知识检索不仅要寻找语义相近的内容，还必须确保结果属于当前租户且已经发布：

SELECT id, title, category,
       l2_distance(embedding, :query_vector) AS distance
FROM knowledge
WHERE tenant_id = :tenant_id
  AND status = 'published'
ORDER BY distance APPROXIMATE
LIMIT 20;

向量距离回答“像不像”，结构化条件回答“能不能看、是否有效”。真实业务通常需要两者同时成立。

3.2 事务、MVCC 和恢复提供什么？

• ACID 事务确保一组相关操作要么全部成功，要么全部回滚；
• MVCC让读写并发时仍可获得一致性视图；
• Redo Log为已提交数据提供崩溃恢复基础；
• 权限与角色限制不同主体能够读取或修改的对象。

假设应用在一次事务中同时更新订单状态、客服摘要和检索元数据。若这些数据分散在不同系统中，“订单已完成、检索信息未更新”就可能成为需要应用层补偿的中间状态。统一事务可以缩小这类不一致窗口。

4. LSM-Tree：写入、整理与读取如何协作

seekdb 的持久化存储采用 LSM-Tree。初学者可以把它理解为“前台追加变化，后台持续整理”：

1. INSERT、UPDATE、DELETE 先形成事务增量；
2. 变更写入 Redo Log 以获得持久化保障，同时进入内存中的 Active MemTable；
3. MemTable 冻结后，通过 Mini Compaction 转储成磁盘上的 SSTable；
4. 后台 Minor、Medium 或 Major Compaction 继续归并数据，控制文件数量、空间占用与读取放大；
5. 查询依据事务快照，同时读取相关 MemTable 和 SSTable，再由 MVCC 与多路归并选择可见版本。

这解释了两个容易混淆的事实：

• “数据尚未整理进最终基线文件”不等于“已提交数据会丢失”；
• LSM-Tree 优化写入路径，但后台整理、读放大和空间放大仍然需要权衡。

对本课程而言，不需要深入实现 Compaction 算法，但要知道 AI 数据的持续写入（新文档、新记忆、新向量）最终会落到真实的存储与并发机制上。

5. 一份事实，多种数据表达

AI 应用中的一条记录往往不止一种数据形态。例如，一段企业知识可以同时包含：

数据形态	示例字段	主要用途
关系数据	tenant_id、owner_id、status	业务实体、权限、状态和精确过滤
向量数据	embedding	语义相似度检索
文本数据	title、content	阅读、关键词检索、证据引用
JSON 数据	metadata	动态属性、模型输出、工具上下文
GIS 数据	location	距离、区域与空间关系查询

把这些字段放在同一数据上下文中，能够减少跨系统复制，并让权限、来源和状态直接参与检索。但“统一”也不是免费的：不同索引会增加写入、存储和维护成本，表结构与索引策略仍需按查询模式设计。

6. 混合检索：从“相似”走向“可用”

单一向量检索擅长捕捉语义近似，却可能漏掉产品型号、错误码、人名等精确词项；全文检索擅长关键词匹配，却不一定理解同义表达。因此，产业场景常采用混合检索。

一条完整链路通常包含：

1. 对用户问题生成查询向量，得到向量 Top-K 候选；
2. 保留查询文本，通过全文索引和 BM25 得到关键词候选；
3. 在召回前或召回过程中应用租户、权限、时间、状态、JSON 属性等条件；
4. 使用加权融合或 RRF 合并不同通道的排名；
5. 对有限候选集进行可选重排；
6. 返回最终 Top-K、业务字段、分数与证据来源。

6.1 为什么要融合排名而不是直接相加分数？

向量距离、BM25 分数和模型重排分数的量纲不同，直接相加往往没有稳定意义。RRF（Reciprocal Rank Fusion）更关注候选在各通道中的名次：

$$\mathrm{RRF}(d)=\sum _{r\in R}\frac{1}{k+r(d)}$$

其中，$r(d)$ 是文档 $d$ 在某个召回通道中的排名，$k$ 是用于减小头部排名波动的常数。它不要求不同召回器输出可比较的原始分数，因此常被用作混合召回的稳健基线。

6.2 同步索引与异步索引

持续写入时，复杂向量索引的同步维护会增加事务关键路径成本。因此系统可能提供两种模式：

• 同步索引：提交后可立即通过索引看到新数据，适合强可见性要求和可控写入压力；
• 异步索引：先提交基表，再异步追平索引，换取更平稳的写入，但存在最终一致窗口。

选型时必须明确“提交成功”指的是基表可见，还是向量索引也已可见。若业务在写入后立即检索，应确认是否需要主动刷新索引或采用同步模式。

与 I2 的边界

本节只建立混合检索全景。索引类型、召回参数、文档切分、检索评测和 RAG 实战将在 I2《向量数据库与 RAG》中继续展开。

7. 数据库内 AI：让模型调用靠近数据

数据库内 AI 的核心不是在数据库进程中运行所有模型，而是把模型定义、服务端点和调用方式纳入数据查询链路。以 seekdb 为例，典型能力包括：

• AI_EMBED：把文本转换为向量；
• AI_RERANK：对查询与候选文档进行相关性重排；
• AI_COMPLETE：调用生成模型完成摘要、抽取、生成或判断。

SELECT AI_EMBED('embedding_model', content) FROM documents;
SELECT AI_RERANK('rerank_model', :query, :documents_json);
SELECT AI_COMPLETE('chat_model', :prompt, :config_json);

模型定义与服务端点分离后，应用可以使用稳定的逻辑模型名；更换提供方、地址或凭据时，不必同步修改所有查询。

7.1 正确的调用顺序

外部模型调用通常比本地谓词和索引查询更慢、更贵，也更容易超时。稳妥的执行顺序是：

先过滤 → 再召回 → 缩小候选集 → 最后重排或生成

不要对无限结果集逐行调用模型。生产系统还应明确并发上限、超时、重试、费用预算、敏感数据边界和失败后的降级策略。

与 I3、I5 的边界

I3 将讨论 AI Functions 的设计与执行，I5 将讨论模型驱动派生数据如何自动维护。本节只说明这些能力在整体数据库架构中的位置。

8. Fork / Diff / Merge：给 Agent 一个可写沙箱

传统只读 RAG 的风险相对有限；一旦 Agent 可以修改记忆、计划或业务数据，就需要更严格的控制面。直接写主数据容易造成误操作，而完整复制数据库又可能成本过高。

Fork / Diff / Merge 将代码分支的思路引入数据工作流：

1. Fork：基于主数据创建隔离、可写的数据库或表分支；
2. 试写：Agent 在沙箱中多步修改和验证，不影响主数据；
3. Diff：展示新增、删除、修改和同主键冲突；
4. 决策：由规则或人工判断是否采纳；
5. Merge 或丢弃：将结果按策略合入主数据，或直接放弃沙箱。

FORK DATABASE agent_state TO sandbox_42;

USE sandbox_42;
UPDATE memory SET content = :new_content WHERE id = :id;

DIFF TABLE sandbox_42.memory AGAINST agent_state.memory;

MERGE TABLE sandbox_42.memory
INTO agent_state.memory
STRATEGY THEIRS;

8.1 三种冲突策略

策略	冲突时的行为	适合场景
FAIL	检测到冲突即停止	默认安全策略；需要复核的任务
THEIRS	采用待合入侧内容	已验证的 Agent 结果或权威修订
OURS	保留目标侧内容	主数据优先，只接收无冲突新增

数据分支只解决隔离与采纳机制，并不替代权限、审批和审计。生产方案还应限制可 Fork 的对象，设置沙箱所有者、生命周期和空间配额，并记录任务、模型、提示词、差异与采纳人。

9. 嵌入式还是服务器模式？

AI 应用的交付位置差异很大：桌面 Agent 希望数据跟随应用，本地开发强调低门槛，团队服务则要求并发访问和集中运维。支持多形态运行的数据库可以使用同一数据模型和查询语义覆盖不同阶段。

维度	嵌入式模式	服务器模式
典型场景	桌面 Agent、个人知识库、边缘与离线应用	团队服务、集中数据平台、跨主机访问
接入方式	语言 SDK，随应用进程或本机部署	网络协议、驱动和连接池
优势	交付简单、低延迟、可离线	集中治理、资源隔离、并发与高可用
主要关注	进程生命周期、本地文件、升级与备份	账号权限、TLS、网络、容量与故障切换

轻量、跨平台和 MySQL 兼容能够降低从本地验证到服务器部署的迁移成本，但生产可用性仍取决于备份恢复、监控、权限、升级和容量规划，而不只是二进制体积或启动速度。

10. 选型：统一数据库还是组合式架构？

面对一个新项目，可以按以下顺序判断：

10.1 先问场景问题

1. 数据是否同时包含业务状态、文本、向量和动态元数据？
2. 检索是否必须带租户、权限、时间或状态过滤？
3. 写入后是否要求立即被语义检索到？
4. 数据规模、写入吞吐、查询并发和尾延迟目标是多少？
5. 团队能否承担多个系统的同步与运维？
6. Agent 是否会修改数据，是否需要隔离试验与审批？
7. 应用是否需要离线、边缘或嵌入式交付？

10.2 再比较方案

场景特征	更值得优先评估的方案
中小规模、数据类型多、强调开发与运维简化	统一数据库
业务过滤与语义/全文检索强耦合	统一数据库
单一检索负载达到极大规模，且需要专用能力	专业系统或组合式架构
已有成熟数据平台和可靠同步链路	延续组合式架构并评估边际收益
原型只需少量静态文档	先用最简单可验证方案，不必过早引入复杂基础设施
本地或离线 Agent，需要应用内数据能力	支持嵌入式的数据库

统一数据库减少的是系统边界，不会自动消除索引设计、模型成本、权限治理和评测工作。组合式架构增加的是集成成本，但可以换取更强的专业化扩展能力。二者没有脱离场景的绝对优劣。

11. 贯穿案例：企业知识助手的数据底座

假设要构建一个支持多租户、权限过滤和可追溯回答的企业知识助手，可以设计如下表结构：

CREATE TABLE knowledge (
  id           BIGINT PRIMARY KEY,
  tenant_id    BIGINT NOT NULL,
  title        VARCHAR(512),
  content      TEXT,
  metadata     JSON,
  embedding    VECTOR(768),
  status       VARCHAR(32),
  updated_at   TIMESTAMP
);

完整的数据流不是“文档转向量”这么简单，而是：

1. 文档写入时保存正文、租户、权限、状态、来源和分段信息；
2. 调用嵌入模型生成向量，并建立向量与全文索引；
3. 查询时先注入当前用户的权限和业务过滤条件；
4. 并行进行向量与全文召回，通过 RRF 或加权策略融合；
5. 只对有限候选调用重排模型；
6. 将最终证据交给生成模型，并在答案中保留引用；
7. 记录问题、检索条件、候选、分数、模型版本和最终答案，用于追踪与评测。

这个案例贯穿了本节的核心：AI 原生数据底座不是单独增加一个向量字段，而是把业务事实、检索信号、模型调用和治理边界组织成一条可验证的数据链路。

12. 常见误区

误区一：有向量类型就是 AI 原生数据库

向量只是一个维度。真实应用还需要全文检索、标量过滤、事务、权限、恢复、模型治理和部署能力。

误区二：统一数据库一定比多个系统性能更好

统一架构的直接收益通常是简化一致性与工程复杂度，而不是在每一种专业负载上都获得最高性能。性能结论必须限定数据集、索引参数、写入速率、并发、召回率和硬件环境。

误区三：把模型调用放进 SQL 就能自动获得好效果

模型质量仍依赖输入数据、提示词、候选质量和评测。数据库只提供更靠近数据的调用与编排位置。

误区四：Agent 有沙箱就可以自动合并

Fork 隔离了试写，Diff 暴露了变化，但 Merge 决策仍需要业务规则、权限和必要的人工审批。

误区五：最终一致性只是实现细节

异步索引会影响“刚写入的数据能否马上搜到”。这是产品语义，必须在接口、测试和用户预期中明确。

13. 本节小结

本节可以浓缩为五句话：

1. 大模型负责概率推理，数据库负责持久状态、事实约束与恢复；
2. Agent 同时需要关系、向量、文本和半结构化数据；
3. 混合检索把语义、关键词和业务条件组合成可用结果；
4. 数据库内 AI 应遵循“先过滤与召回，再调用昂贵模型”；
5. Fork / Diff / Merge 为会写数据的 Agent 提供隔离试验和受控采纳机制。

课后行动

选择你熟悉的一个 AI 应用，完成一页“数据底座评审”：

1. 列出它的业务数据、知识数据、记忆数据和任务状态；
2. 标注每类数据需要精确查询、全文检索还是向量检索；
3. 写出一致性、写后可见性、权限和恢复要求；
4. 判断统一数据库与组合式架构各自的收益和风险；
5. 如果 Agent 可以写数据，补充一次 Fork → Diff → Merge 的审批流程。

思考题

1. 为什么“向量召回结果很相关”仍然不代表它可以展示给当前用户？
2. 在什么情况下，异步向量索引比同步索引更合理？
3. RRF 为什么比直接相加向量距离和 BM25 分数更稳健？
4. Fork / Diff / Merge 与数据库事务分别解决什么问题？
5. 你的场景中，拆分搜索引擎和向量数据库带来的收益是否足以覆盖同步成本？

与其他课程的关系

• D2《AI 应用的数据层》：跑通统一数据层的基础实践；
• D3《Agentic RAG 实战》：构建可执行的 RAG 流程；
• D4《Agent 开发与记忆系统》：理解 Agent 状态与长期记忆；
• I2《向量数据库与 RAG》：深入向量索引、混合检索与评测；
• I3《SQL × AI》：深入 AI Functions 的设计与执行；
• I5《AI 列》：讨论模型驱动派生数据的自动维护。

参考资料

• seekdb 技术架构与核心能力；
• seekdb 官网；
• seekdb GitHub。

共建说明

欢迎在课程共建 Issue #90 中补充案例、实验、图示和评测方法。