Zilliz 05月27日 20:06
为什么向量数据库不需要SQL
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

文章探讨了自然语言查询作为未来数据库交互方式的可能性,并预测到2026年,大多数企业将优先采用自然语言查询接口。文章指出,传统SQL查询方式在处理非结构化数据和向量检索方面存在局限性。而基于自然语言的交互,结合Agent调度、向量检索等技术,能降低使用门槛,提升查询效率,并更好地适配大模型和AI应用场景。向量数据库的出现,弥补了传统关系型数据库在AI时代的不足,有望成为新型基础设施。

✅自然语言交互通过Agent调度,能够解析用户意图,选择合适的查询策略(结构化过滤或向量检索),调用API或SDK,并以用户易懂的方式包装结果,极大地降低了数据库查询的门槛,让非技术人员也能轻松使用。

✨传统关系型数据库在进行向量检索时,存在执行路径复杂、I/O压力大等问题,导致查询延迟高、吞吐量低。相比之下,向量数据库在设计哲学、数据结构和查询逻辑上都更适合处理非结构化数据和自然语言查询。

💡向量数据库具备四大优势:支持多样化模型结构,能灵活处理嵌套文档、时间序列向量等多类型数据;提供Agent友好的原生API,方便大模型调用;具备深度语义理解能力,能理解用户意图;通过结构化过滤、混合检索等手段优化召回率,实现性能与召回的平衡。

📚向量数据库并非要取代关系型数据库,而是一种与AI场景相伴生的新型基础设施,能更好地响应自然语言查询,对语义信息进行检索,从而将数据库转变为真正理解上下文、主动帮助用户决策的数据智能体。

原创 栾小凡 2025-05-27 18:06 上海

到 2026 年,大多数企业将优先采用自然语言作为查询接口

前言

几十年来,从报表系统到财务分析,再到用户行为查询,我们早已习惯了通过 SELECT–FROM–WHERE 的方式与数据库对话。而在这一过程中,SQL 也逐渐成为人们对‘数据库查询’的默认理解方式。甚至,当年标榜“反 SQL 革命”的 NoSQL,有无一例外,引入了 SQL 支持。

但历来如此,就代表永远正确吗?

根据 Gartner 预测,到 2026 年,大多数企业将优先采用自然语言作为查询接口,SQL 将从“必选项”变成“可选项”。

而随着大模型与向量数据库的落地速度加快,我们需要重新审视:SQL是否还是数据库查询的最优解?

01

自然语言交互,数据库查询的另一种解法

想象一下,不再需要写复杂 SQL 查询,而是直接说一句:“帮我找出最近购买行为和我最像的用户最喜欢的商品。”

后台就听懂了你的意图,然后迅速决定:

做完这些决策,数据库就能自行搞定所有执行细节,返回你想要的结果。

而这样做带来的用户升级主要包括:

✅ 零语法门槛,我们不需要记字段名、不怕括号乱套,表达需求更自然。

✅ 对非结构化数据查询更友好,图像、音频、文本都能作为查询对象。

✅ 这套系统会的受众会更加广泛:不仅是工程师能用,运营、产品甚至市场部也都能对数据进行交互。

02

自然语言交互背后是Agent调度

那么实现基于自然语言的交互?业内通常的做法是自然语言解析 + 向量检索 + Agent 调度

自然,这其中最重要的一环就是Agent 调度,它主要可以完成四大功能

举个例子:  在向量数据库 Milvus 中,一行代码就能完成一次复杂的相似度检索:

    results = collection.search(query_vector, top_k=10, filter="is_active == true")

    这种“API-first” 的思路,天然适配大模型的 Function Calling、MCP 能力,执行更快,出错更少,也更容易标准化和集成。

    03

    SQL为什么不适合做向量检索?

    一个共识是,非结构化数据占据了全世界数据总量的80%,而向量数据库,相比传统的关系型数据库,天生适配自然语言查询也更适配大模型。

    当然,为了解决传统关系型数据库无法对非结构化数据做查询的这一弊病,很多传统关系型数据库也推出了“SQL 风格的向量检索”功能,比如PostgreSQL + PGVector 提供了 

    <->

     运算符,下面这样的语句看起来“挺高级”的:

      SELECT *

        FROM items

       ORDER BY embedding <-> query_vector

       LIMIT 10;

      但表面上的“兼容”,又带来了新的问题:这种SQL并未形成标准,从而给开发者带来了更高的学习成本。不仅如此,将向量数据存储在关系型数据库中还存在严重的性能问题:

      问题一,执行路径复杂:但传统数据库会强制走解析器、优化器、事务等重逻辑路径,导致消耗了大量额外的资源

      问题二,I/O 压力大:向量存成 BLOB,每次检索都要解码;图索引场景还可能频繁跳转磁盘,极度消耗性能。

      我们做过一个测试,在相同检索条件下,Milvus 查询延迟是 pgvector 的 40%,吞吐量提升了 4.5 倍。换句话说,传统关系型数据库套壳向量检索,其实反而带来了更大的系统复杂度。

      整体来说,关系型数据库和向量数据库在设计哲学、数据结构和查询逻辑上,思路天差地别:

      尾声

      总结来说,应对AI时代,向量数据库的优势有四:

      1. 支持多样化模型结构

      现实世界的数据远比表格复杂。向量数据库能灵活支持嵌套文档、时间序列向量,以及 ColBERT、CoLPAL 等多向量结构,以适配不同模型生成的丰富语义表示。

      2. Agent 友好的原生 API

      大模型更擅长调用函数而不是写 SQL。向量数据库具备 Python-first 的 API 设计,原生支持 Function Calling,一行代码即可完成嵌入检索、过滤、重排序和语义高亮,极大降低开发和运维成本。

      3. 深度语义理解能力

      向量数据库不只是执行命令,更能理解意图。它与 AI Agent 协作,可以跳出“字面匹配”的束缚,实现语义层面的智能检索,让未来的数据库不只要知道“怎么查”,更要知道“你真正想查什么”。

      4. 召回率的极致优化

      通过结构化过滤、混合检索、Rerank 等手段,向量数据库可以不断优化搜索结果的相关性,把更多真正有价值的内容找回来,达成性能与召回的平衡。

      一句话总结,向量数据库并不是为了替代关系型数据库,它更多情况下,是一种专门与 AI 场景相伴生的新型基础设施,能更好的响应你的自然语言查询,也能够对语义信息进行检索。最终让数据库从死板的执行者,转变为真正理解上下文、主动帮你决策的数据智能体。

      作者介绍

      栾小凡

      Zilliz 合伙人和研发 VP

      LF Al & Data 基金会技术咨询委员会成员

      推荐阅读

      从部署到迁移,怎么用好Milvus,这是我们的经验总结

      从BGE到 CLIP,从文本到多模态,Embedding 模型选型终极指南

      一文读懂Milvus核心参数,十分钟解决80% 的配置问题

      点击“阅读原文”即可体验zillz cloud

      阅读原文

      跳转微信打开

      Fish AI Reader

      Fish AI Reader

      AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

      FishAI

      FishAI

      鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

      联系邮箱 441953276@qq.com

      相关标签

      自然语言查询 向量数据库 Agent调度 AI 数据库
      相关文章