最近体验了YashanDB AI Edition这个版本。

我把数据库装到一台 Linux 8.10 机器上，用独立测试用户建表、建索引、接 Ollama、调真实 LLM API，再把向量、JSON、全文检索放进同一条 SQL。

一般来说DBA 看 AI 数据库，关心的还是老几样：数据留不留在库里，索引跟不跟事务走，查询能不能用 SQL 串起来。遇到异常时，日志和执行路径能不能查清楚。

这一轮测下来，我的判断是：YashanDB 把 AI 能力做成了 SQL 能调用的数据库能力。

一、先说结论

YashanDB AI Edition 这版吸引我的地方，是它把几类能力放进同一个数据库执行环境：

• 原生向量类型 VECTOR

• HNSW 向量索引

• JSON 文档能力

• 全文检索 contains

• DBMS_LLM 模型管理

• AI_EMBED 向量化函数

• AI_COMPLETE 大模型调用函数

这些能力分开看并不陌生。你把它们放进同一张表、同一条 SQL、同一个事务环境，数据库就开始接管 AI 检索链路里的核心工作。

我测试时创建了独立用户 AI_TEST，没有把对象堆到 SYS 下。向量、JSON、全文索引、模型注册、Embedding 入库、RAG 风格检索都能跑通。

生产环境里，DBA 不喜欢把一套业务查询链路拆成数据库、向量库、全文服务、脚本任务和大模型网关。链路越长，故障点越多，权限和审计也就越难收。

二、向量能力能落到 SQL 里

我先用手写 3 维向量做基础验证。

建表时使用 VECTOR(3)：

CREATE TABLE docs (
    id        BIGINT PRIMARY KEY,
    title     VARCHAR(200),
    content   CLOB,
    embedding VECTOR(3)
);

插入数据后，用 cosine_distance 排序，再创建 HNSW 索引做近似查询。

这一组验证通过：

• 向量字段可写入

• 精确 TopN 可排序

• HNSW 索引可创建

• FETCH APPROXIMATE 可用于单向量场景

• 官方

后面我又接入了 Ollama 的 nomic-embed-text。这个模型返回 768 维向量，YashanDB 可以写入 VECTOR(768)。

exec DBMS_LLM.CREATE_MODEL(  'ollama_embed_root',  'http://127.0.0.1:11434',  'nomic-embed-text',  'embedding',  'openai');

这里有个细节要记住：模型地址写服务根地址 http://127.0.0.1:11434，不要写 /v1/embeddings。YashanDB 会按 provider 和模型类型拼接接口。

验证结果如下：

AI_EMBED 返回 768 维
VECTOR(768) 入库成功
HNSW 索引创建成功
精确检索和近似检索都返回结果

你可以在数据库内完成文本向量化、写表、建索引和召回。应用不用先把数据抽出去，再写到另一个向量库。

三、全文、JSON、向量可以放在一条 SQL 里

在这次测试中，我把时间花在多模态组合上。

单独支持向量不难。单独支持 JSON 也不新鲜。不少数据库也能做全文检索。让我继续往下测的点，是这些能力能放进一条 SQL，让优化器和执行引擎一起处理。

我测试了这类组合：

SELECT id, titleFROM ai_docsWHERE JSON_VALUE(metadata, '$.source' RETURNING VARCHAR(30)) = 'base'
  AND contains(body, '数据库 | 搜索') > 0ORDER BY cosine_distance(embedding, to_vector('[1,1,0]', 3))FETCH FIRST 2 ROWS ONLY;

普通 FETCH FIRST 场景稳定返回结果。

这种 SQL 贴近真实业务：

• JSON 存放半结构化标签

• CLOB 存放正文

• VECTOR 存放语义向量

• SQL 负责组合过滤和排序

如果你做知识库、工单检索、合同检索、客服问答，这种表结构自然。业务人员搜一句话，数据库背后要同时处理关键词、标签和语义距离。YashanDB 已经能跑通这条链路。

四、AI 函数进 SQL

DBMS_LLM 负责模型注册，AI_EMBED 和 AI_COMPLETE 负责在 SQL 里调用模型。

Embedding 模型可以这样注册：

exec DBMS_LLM.CREATE_MODEL(  'embed_model',  'http://127.0.0.1:11434',  'nomic-embed-text',  'embedding',  'openai');

写入数据时调用：

INSERT INTO docs VALUES (  1,  '向量检索',  '向量检索适合语义搜索和 RAG 场景',
  AI_EMBED('embed_model', '向量检索适合语义搜索和 RAG 场景', 768)
);

LLM 模型也可以注册后用 AI_COMPLETE 调用。我用本地 OpenAI 兼容代理接了真实 Chat API，SQL 能返回模型生成结果。

这类能力对开发者友好，对 DBA 也友好。开发者少写一段胶水代码，DBA 可以在数据库层看到对象、权限、执行路径和返回信息。

五、事务一致性经得起小样本检查

我专门测了回滚。

先插入一条由 AI_EMBED 生成向量的记录，当前事务里能查到。执行 ROLLBACK 后，记录不可见。

全文索引也做了类似测试。未提交的全文记录当前事务可查，回滚后查不到。

生产系统怕数据不一致。外挂式 AI 检索经常把业务表、向量库、全文服务拆开。业务表回滚了，外部索引却写进去了；主表更新了，向量库还没同步。DBA 排查这种问题会花掉大量时间。

YashanDB 把这些能力收进数据库事务环境后，我在小样本测试里看到了符合预期的事务行为。

六、自然语言查询能力的边界

我也关注了自然语言查库这条线。

成熟的自然语言查库方案通常会引入 credential、profile、object_list 这类配置，让数据库知道哪些表允许被自然语言查询。用户提问后，系统生成 SQL，再结合权限和审核策略返回结果。

YashanDB 当前已经把模型调用、Embedding、向量检索和 SQL 融合打通。你可以用 AI_COMPLETE 组织 prompt，把表结构交给模型，让模型生成 SQL。这条链路已经能做原型验证。

如果后续继续补强 AI Profile、对象白名单、只读 SQL 审核和 SQL 生成审计，YashanDB AI Edition 在企业内网知识库和业务查询场景里会更完整。

七、我为什么看好这个方向

企业做 AI 应用时，常见做法是上一个向量库，再接一个全文服务，再写一堆同步任务。

这条路能跑，但 DBA 会累。数据从业务库出去以后，权限、审计、回滚、补偿、延迟都要重新设计。

YashanDB AI Edition 给了另一种路径：把 AI 检索能力往数据库里收。

你可以把结构化数据、JSON 文档、全文内容、向量字段放在同一个数据库里，用 SQL 串起来。你也可以把 Embedding 模型接进来，让数据在入库时完成向量化。

高并发推理、复杂 Agent、长链路工具调用仍然适合放在应用层。数据库适合管数据、管事务、管查询、管权限。YashanDB AI Edition 让数据库承担 AI 检索链路里数据库该承担的部分。

八、适合哪些场景先试

我会优先把它放到这些场景里验证：

1. 企业知识库检索

2. 工单和故障案例检索

3. 合同、制度、技术文档检索

4. 数据库运维知识问答

5. 结构化条件 + 语义检索混合查询

这些场景有共同特征：数据在企业内部，权限要收紧，查询结果要可解释，更新和回滚不能乱。

如果团队已经有 Oracle、PostgreSQL 或国产数据库使用经验，上手 YashanDB AI Edition 的成本不高。SQL 仍然是主入口，AI 能力通过函数和索引进入查询链路。

九、结尾

这轮内测让我看到一个方向：国产数据库正在把 AI 能力往数据库内核和 SQL 体系里推。

YashanDB AI Edition 现在能完成向量入库、HNSW 检索、全文检索、JSON 查询、AI 函数调用和本地 Embedding 接入。后续如果继续丰富跨模态查询能力和自然语言查库产品形态，会更适合企业级 AI 数据场景。

从 DBA 视角看，这个版本值得继续研究。

数据库进入 AI 场景，不能只靠外接服务。事务、权限、索引、审计、恢复，这些老问题不会因为接了大模型就消失。企业敢用的 AI 数据底座，要把这些问题和 AI 检索放进一套体系里处理。YashanDB AI Edition 这版，已经在往这个方向走。我也看到了国产数据库厂家在 AI 方向的加速演进！