1. 为什么说“向量数据库”还不够？聊聊企业AI落地的真实痛点

最近几年，AI大模型火得一塌糊涂，很多企业都摩拳擦掌，想搞点自己的AI应用，比如做个智能客服、搞个文档问答助手，或者给产品加个智能推荐。但真干起来，你会发现，技术选型第一步就卡住了：数据这块，到底该用啥？

很多人第一反应是：上向量数据库啊！毕竟现在RAG（检索增强生成）这么火，向量搜索不就是核心吗？我刚开始也这么想，但踩过几个坑之后，发现事情没这么简单。向量搜索确实厉害，它能理解语义，你问“怎么优化数据库性能”，它能找到讲“SQL查询调优”的文档，这是传统关键词匹配做不到的。但光有“理解”能力，在企业里是远远不够的。

我举个例子你就明白了。假设你们公司内部有个知识库，里面有很多技术文档、项目报告和客户资料。你开发了一个Copilot助手，希望员工能快速查询。一个很常见的需求是：法务部的同事只能查询和他权限相关的合同文档，研发部的同事看不到销售数据。这个需求听起来很简单吧？但用纯向量数据库来实现，就非常头疼。

向量数据库的核心是向量索引，它只管“像不像”，不管“能不能看”。权限过滤这种精确匹配的条件，向量数据库本身是不擅长的。常见的做法是，你得先做一遍ETL（数据抽取、转换、加载），把用户的部门、权限等级这些信息，作为“标量”字段，和文档向量一起存到向量数据库里。查询的时候，先做向量搜索召回一批相似的文档，再用这些标量字段过滤出有权限的。

这个流程听起来就麻烦，实际用起来问题更多。第一，引入了高成本的ETL。数据源一变，比如员工调岗了，你得重新跑一遍ETL流程，延迟高，维护成本巨大。第二，数据一致性难保证。业务数据库里的权限信息更新了，向量数据库里的标量字段可能还没同步，导致用户查到了不该看的东西，或者该看的没看到，这可是安全大事。第三，造成了不必要的数据膨胀。为了满足各种过滤条件（日期范围、文档类型、状态等），你不得不在向量数据库里建一张包含所有字段的“宽表”，大量冗余数据不仅浪费存储，更拖慢查询速度。

这还只是权限问题。再比如，用户问：“请把2023年Q3的销售报表中，华东区销售额超过100万的项目列出来。”这种问题混合了精确查询（2023年Q3、华东区、>100万）和语义理解（“销售报表”可能对应多个不同名称的文档）。纯向量搜索很可能召回一堆相关的季度报告，但无法精确锁定到“2023年Q3华东区”的具体表格行。结果就是，你喂给大模型（LLM）的参考信息是模糊的，LLM基于这些模糊信息生成的答案，很可能“胡言乱语”，也就是我们常说的“幻觉”。

所以你看，企业级的AI应用，光有“大脑”（大模型）和“模糊记忆”（向量搜索）是不够的，还必须有一个“精准且有条理的记忆系统”。这个系统需要同时具备三种能力：语义搜索（向量）、精确搜索（全文/关键词）、条件过滤（结构化查询）。而这，正是传统向量数据库的短板，也是新一代AI原生数据库诞生的根本原因。

2. 从拼凑到一体：AI原生数据库如何简化你的技术栈

过去十年，企业为了搭建智能应用，技术栈那叫一个复杂。我经历过那个阶段，简直是个“缝合怪”现场。我们来回顾一下，你就知道现在有多幸福了。

2.1 第一代：搜索引擎时代

在深度学习普及之前，企业做智能推荐、简单分类，主要靠统计模型。那时候的数据基础设施，核心是搜索引擎（比如Elasticsearch、Solr）加传统数据库（MySQL、PostgreSQL）。业务数据存在MySQL里，需要搜索和分析的内容导入Elasticsearch。两者之间靠应用层代码或者ETL工具连接。这套架构能解决关键词匹配和简单聚合问题，但完全不懂语义，用户体验上限不高。

2.2 第二代：向量数据库与AI中台

随着BERT、GPT等模型出现，语义向量火了。大家发现，用向量表示文本，搜索效果质的飞跃。于是，向量数据库（如Milvus、Pinecone）作为一个新品类出现了。但问题来了，向量数据库只管向量搜索，其他啥也不管。企业要做一个完整的RAG应用，后台技术栈就变成了：业务数据库（存原始数据）+ 向量数据库（存向量）+ 搜索引擎（做精确召回）+ 可能还有缓存、消息队列…… 应用开发者需要写大量的胶水代码，来协调这些数据源，进行所谓的“联邦搜索”。不仅开发复杂，性能也是瓶颈，更别提数据一致性的噩梦了。这套复杂的东西，常常被包装成“AI中台”，听着高大上，用起来谁痛苦谁知道。

2.3 第三代：All-in-One的AI原生数据库

大模型的出现，让AI应用场景爆炸式增长。大家猛然发现，之前那套“拼积木”的架构，根本撑不起未来。我们需要的是一个专门为AI时代设计的数据底座。它不应该让开发者去适应多个数据库的接口和特性，而应该让数据库来适应AI的查询模式。

这就是AI原生数据库的定位。它不是一个简单的向量数据库升级版，而是一个全新的品类。它的设计目标很明确：一站式满足大模型对数据的所有需求。也就是说，你只需要一个Infinity这样的数据库，加上一个大模型（现在是LLM，未来可能是多模态模型），就能支撑起企业内主要的AI场景，比如Copilot、智能搜索、个性化推荐、对话机器人。

它的工作流程非常直观：企业内部的各种数据，无论是结构化的数据库表（MySQL、PostgreSQL里的数据）、半结构化的日志和API数据，还是非结构化的PDF、Word、PPT文档，都可以通过内置的连接器或简单的导入工具，统一汇聚到Infinity中。Infinity内部会自动或按需为这些数据构建向量索引、全文索引，并管理好原始的结构化字段。当应用发起一个查询时，无论是语义问题、精确问题还是混合问题，Infinity都能在内部完成多路召回和智能融合，把最相关、最准确的数据片段整理好，交给大模型去生成最终答案。开发者只需要面对一个简单的API，再也不用操心数据到底在哪、该怎么搜了。

3. 拆解Infinity：不只是“三合一”，更是“融会贯通”

说了这么多理念，我们具体看看Infinity是怎么做到的。它可不是简单地把向量、全文、结构化查询三个引擎塞进一个软件里，那样顶多算个“三合一”套装。Infinity是从存储层到计算层，为AI查询场景从头设计的。

3.1 存储层：为混合负载而生

Infinity的存储层设计得非常精巧，它同时维护着三种索引，各司其职又紧密协作：

1. 列式存储：这是处理结构化数据过滤和聚合的利器。比如，当你需要筛选“创建时间在最近一周、状态为‘已完成’的所有工单”时，列存引擎可以飞速完成。而且，它保证了数据的ACID特性，让你的业务数据既跑得快又靠得住。
2. ANN向量索引：这是语义搜索的核心。Infinity目前提供了两种主流的向量索引算法：IVF和HNSW。这里有个很实在的细节，Infinity对HNSW做了内存优化，采用了局部量化技术。我实测过，在保证相同甚至更高精度的前提下，它的内存占用比标准的HNSW小很多。这意味着你用更便宜的机器，就能服务更大的数据量。更酷的是，Infinity允许一张表里有多个向量列。比如，你可以同时为文档的“标题”和“正文内容”分别生成向量并建立索引，查询时可以根据需要选择在哪个字段上搜索，甚至进行多向量联合查询，这比只能有一个向量的数据库灵活太多了。
3. 倒排索引：这个大家伙身兼两职。一是作为全文搜索引擎，提供基于BM25的相关度打分、短语查询、通配符查询等，确保你能精确召回“MySQL索引优化”这样的关键词。二是作为结构化数据的二级索引，可以极大加速对某些标量字段（如用户ID、商品分类）的等值或范围查询。

这三种索引底层的数据其实是同一份，只是以不同的组织形式存在。这避免了为了不同查询需求而反复复制数据，从根本上解决了数据一致性和膨胀问题。

3.2 计算层：智能的查询大脑

光有好的存储引擎还不够，怎么高效地使用它们才是关键。Infinity的计算层有个智能的“执行器”，它的作用就像一个有经验的调度官。

当你发起一个混合查询，比如“帮我找一下去年发布的、关于神经网络架构优化的技术博客，要内容比较深入的”。这个查询会被解析成几个部分：时间过滤（“去年发布”）、主题向量搜索（“神经网络架构优化”的语义）、内容深度判断（可能也需要向量或全文特征）。Infinity的执行器不会僵化地固定执行路径，它会进行动态优化：

• 查询路由：它会分析查询条件，决定哪些部分用列存过滤最快，哪些用向量索引更准，哪些必须用倒排索引做精确匹配。
• 资源调度：如果你的查询对延迟极其敏感（比如对话机器人的第一响应），执行器可能会启动多个计算单元，并行搜索不同的索引，最后快速合并。如果系统并发压力很大，它又会调整策略，优先保证整体吞吐量。
• 融合排序：这是Infinity的“杀手锏”级操作，叫做Fusion算子。想象一下，向量搜索返回了10篇相关博客（按语义相似度排序），全文搜索根据“架构优化”关键词返回了8篇（按BM25分数排序），时间过滤框定了15篇。这三份结果列表怎么合并成一个最终排序？传统联邦搜索的做法是在应用层写复杂逻辑，效率低且效果难调优。而Infinity的Fusion算子在数据库内部，使用学习到的排序模型（Learning to Rank）或可配置的规则，将多路召回的结果进行深度融合与重排，直接输出一个综合相关度最高的结果列表。这一步，把最脏最累的活从应用层挪到了数据库内核，不仅性能提升一个数量级，效果也更好把控。

4. 手把手实战：5分钟搭建你的第一个RAG应用

理论讲得再多，不如动手试一下。我来带你快速走一遍，用Infinity和任意一个大模型API，搭建一个最简单的文档问答应用。你会惊讶于它的简洁。

4.1 环境准备与启动

Infinity是开源的，直接用Docker跑起来最方便。确保你的机器上安装了Docker和Python3。

# 1. 拉取Infinity镜像
docker pull infiniflow/infinity:latest

# 2. 启动Infinity服务，默认端口是23817
docker run -p 23817:23817 -d infiniflow/infinity:latest

就这么两行命令，一个功能完整的AI原生数据库服务就跑起来了。它同时支持高性能的向量搜索、全文搜索和SQL查询。

4.2 连接数据库与插入数据

接下来，我们用Python客户端来操作。Infinity的API设计非常Pythonic，学起来很快。

# pip install infinity-sdk
import infinity
from infinity import NetworkAddress, TableInfo, ColumnInfo, ColumnType, CreateTableOptions
from infinity import IndexInfo, IndexType, CreateIndexOptions, EmbeddingModel

# 1. 连接到本地Infinity
conn = infinity.connect(NetworkAddress("127.0.0.1", 23817))
db = conn.get_database("default_db")
# 创建一张表来存技术文档
table_name = "tech_docs"
# 定义表结构：有id、文本内容、以及文本对应的向量
db.drop_table(table_name) # 如果存在先删除，方便演示
db.create_table(table_name, [
    ColumnInfo("id", ColumnType.INT64, primary_key=True),
    ColumnInfo("content", ColumnType.VARCHAR),
    ColumnInfo("content_embedding", ColumnType.VECTOR, dimension=768) # 假设我们用768维向量
])

table = db.get_table(table_name)

# 2. 插入一些示例文档
documents = [
    {"id": 1, "content": "PostgreSQL是一种强大的开源关系型数据库，支持ACID事务。"},
    {"id": 2, "content": "向量数据库专门用于存储和检索高维向量，适用于AI语义搜索。"},
    {"id": 3, "content": "Infinity是一款AI原生数据库，融合了向量、全文和结构化查询。"},
    {"id": 4, "content": "大语言模型如GPT-4，在RAG架构中负责生成最终答案。"},
]
# 这里需要先将文本转换为向量。实践中，你可以用OpenAI、智谱AI等任何嵌入模型。
# 为简化，我们假设有一个函数 get_embedding(text) 返回768维向量。
import numpy as np
def mock_embedding(text):
    # 模拟生成向量，实际请替换为真实模型调用
    return np.random.randn(768).tolist()

for doc in documents:
    doc["content_embedding"] = mock_embedding(doc["content"])
    table.insert([doc])

print("数据插入成功！")

4.3 构建向量索引与混合查询

数据有了，我们为向量列创建索引，然后执行一个典型的混合查询。

# 3. 为向量列创建HNSW索引（为了高性能搜索）
index_info = IndexInfo("vec_idx", IndexType.Hnsw, ["content_embedding"], CreateIndexOptions())
table.create_index(index_info)

# 4. 执行一个混合查询：语义搜索 + 关键词过滤
# 假设用户问题是：“有哪些开源的、和AI相关的数据库？”
query_text = "开源 AI 数据库"
query_vector = mock_embedding(query_text) # 将问题也转化为向量

# 使用Infinity的混合查询API
result = table.output(["id", "content"]).knn(
    "content_embedding", query_vector, "float", 768, 3  # 语义召回Top3
).match(
    "content", "开源", "topn=3"  # 全文搜索“开源”关键词Top3
).fusion('rrf').to_df()  # 使用倒数排序融合（RRF）策略合并结果

print("混合查询结果：")
print(result)

这个查询会同时利用向量索引寻找语义上“和AI相关的数据库”的文档，又利用倒排索引精确查找包含“开源”这个词的文档。最后，通过fusion('rrf')方法，将两路结果智能融合成一个去重且排序的列表。你拿到这个result，就可以直接作为上下文，喂给大模型去生成答案了。

4.4 整合大模型生成答案

最后一步，我们把Infinity检索到的相关文档，发送给大模型API。

# 5. 将检索结果组合成提示词，发送给LLM（这里以OpenAI格式为例）
import openai # 需要安装openai库

context = "\n".join([f"{row['id']}: {row['content']}" for _, row in result.iterrows()])
prompt = f"""基于以下文档片段，回答问题。
文档：
{context}
问题：{query_text}
请用中文给出简洁答案。"""

# 调用大模型（请替换为你自己的API密钥和基座）
client = openai.OpenAI(api_key="your-api-key", base_url="https://api.openai.com/v1")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": prompt}]
)
print("\n大模型生成的答案：")
print(response.choices[0].message.content)

看，整个流程非常清晰。你不需要维护多个数据库的连接，不需要写复杂的多路召回合并逻辑，所有数据相关的复杂操作，都在Infinity内部高效完成了。作为应用开发者，你的关注点可以完全放在业务逻辑和提示词工程上。

5. 性能实测：为什么说Infinity是“性能怪兽”？

光说好用不行，数据库作为基础设施，性能是硬指标。Infinity在性能上的追求，可以用“极致”来形容。它采用C++20标准开发，从内存管理、算法实现到并发控制，都做了深度优化。

我参考官方基准测试，并结合自己的理解，给大家拆解一下它的性能表现。在标准测试数据集SIFT1M（100万条128维向量）上，在一台8核的普通云服务器上：

• 高并发吞吐：Infinity可以轻松达到每秒1万次以上的查询（QPS）。这是个什么概念？意味着它完全可以支撑千万日活应用的向量检索需求，比如大规模的推荐系统或实时搜索。
• 超低延迟：在单个客户端的场景下，查询响应延迟可以做到0.1毫秒级别。这个延迟对于交互式应用（如打字时的实时搜索建议）至关重要，用户几乎感觉不到等待。
• 内存效率：前面提到的局部量化HNSW索引，能在保证高召回率的前提下，将内存占用降低到传统HNSW的几分之一。对于企业来说，直接意味着硬件成本的大幅下降。

除了运行时性能，Infinity在开发体验上也下了功夫。它是最早一批全面采用C++ Modules的大型开源项目。这对我们C++开发者来说是个福音。传统C++编译，改一个头文件，可能触发几百个文件的重新编译，等上十几分钟是常事。而使用Modules后，在普通笔记本上编译Infinity及其依赖的百万行代码，也只需要几分钟，大大提升了开发调试的效率。

6. 展望未来：AI原生数据库会走向何方？

Infinity的开源，在我看来，标志着一个新阶段的开始。它不再是一个单纯的“向量数据库”，而是明确提出了“AI原生数据库”的赛道。这条路会怎么走？根据我的观察和项目实践，有几个趋势是比较明显的。

首先，多模态数据支持会成为标配。现在的大模型正在从纯文本走向图文、音频、视频多模态。未来的AI原生数据库，必然要能高效存储和检索图像嵌入、音频嵌入甚至3D模型嵌入。Infinity已经支持多向量列，这就是为多模态检索埋下的伏笔。想象一下，你可以用一张图片，同时检索相似的图片和描述该图片的文本，这种跨模态检索能力会催生全新的应用。

其次，更智能的查询优化与自治。现在的Fusion算子已经很智能，但未来可能会引入更深度学习的排序模型，甚至根据查询的实时反馈（比如用户最后点击了哪个结果）进行在线学习，自我优化检索效果。数据库的调参会越来越“自动化”，把开发者从繁琐的参数调整中解放出来。

再者，云原生与无缝集成。作为企业级基础设施，云上的部署体验、弹性伸缩、多租户隔离、与主流云厂商AI服务的深度集成（比如一键接入各种Embedding模型和LLM），都会是发展的重点。让开发者以最小的运维代价，获得最强的AI数据能力。

最后想说的是，开源是Infinity最明智的选择。AI基础设施领域变化太快，闭门造车很难跟上社区和需求的发展。开源意味着更多的开发者可以一起贡献代码、验证场景、提出需求。作为早期使用者，我提交过几个issue和小的PR，社区响应非常快。这种开放协作的模式，能让Infinity更快地成熟，真正成为支撑下一代AI应用的那个可靠的数据基石。如果你也在寻找一个能简化技术栈、提升开发效率的AI数据库方案，我强烈建议你花点时间，去GitHub上看看Infinity的源码和文档，亲手部署体验一下。有些东西，只有自己试过，才知道它到底能不能解决你的痛点。