Apache Doris 4.x AI核心能力解析：文本搜索、向量检索与SQL智能分析

当数据处理遇上 AI，企业面临的核心痛点往往是架构的割裂：结构化数据在数仓，非结构化数据在搜索或向量库，AI 分析又依赖独立的引擎。这种多系统联动的模式直接导致了高延迟、高成本和复杂的开发流程。

Apache Doris 4.x 致力于从根本上解决这一问题。它通过原生的 AI 能力，将全文检索、向量搜索和 AI 函数深度集成到同一个实时分析引擎中。这意味着，你可以在一个系统内完成“结构化分析 + 文本搜索 + 向量检索 + AI 智能处理”。独立的向量库和搜索引擎不再是必选项；而大模型能力则通过 Doris 统一的 AI Resource 机制接入（如 OpenAI、DeepSeek、Gemini 或本地模型），并直接在 SQL 中调用。

一、为什么 Doris 要原生集成 AI 能力？

在 Doris 4.x 之前，企业处理“结构化 + 非结构化数据”的 AI 需求时，普遍面临三大痛点：

架构复杂

典型方案往往是组合使用数仓（如 Doris/Hive）、向量数据库、搜索引擎和独立的 AI 引擎（LLM 服务）。多系统部署和运维成本高昂，数据在系统间同步还会带来延迟和一致性问题。

开发门槛高

开发人员需要同时掌握 SQL、搜索 DSL、向量库 API、LLM 调用等多种技术栈，跨系统间的关联分析逻辑复杂，调试成本巨大。

性能损耗大

向量搜索结果、全文检索结果与结构化过滤条件往往需要在应用层进行拼接，跨系统的网络开销和数据搬运导致整体查询延迟很高，难以满足实时分析和在线服务的场景需求。

Doris 4.0 的核心解法是“AI 原生集成”：在一个 MPP 实时分析引擎中，同时提供结构化分析、全文检索、向量搜索和 AI 函数能力，实现统一存储与计算路径，最大限度减少系统间的数据流转，从而从架构层面降低复杂度和延迟。

二、核心 AI 能力：文本搜索、向量搜索、AI 函数

Doris 4.x 的 AI 能力主要围绕三大模块展开：文本搜索、向量搜索、AI 函数，并且全部通过 SQL 原生调用。

1. 文本搜索：倒排索引 + BM25 相关性评分

Doris 自 2.0 起便引入了倒排索引支持基础全文检索，并在 4.0 中进一步增强，提供了统一的 SEARCH() 函数和 BM25 相关性评分，用于高性能文本检索和 TopN 排序。

技术原理

倒排索引
对文本列建立倒排索引，存储“词 → 文档列表”的映射关系，以支持高效的关键词、短语等检索。

BM25 相关性评分
Doris 4.0 引入了 BM25 算法，可为匹配到的行计算相关性得分，从而实现按相关性排序返回 TopN 结果。

使用示例：

SELECT id, title, score() AS relevance
FROM docs
WHERE content MATCH_ANY 'real-time OLAP analytics'
ORDER BY relevance DESC
LIMIT 10;

统一搜索入口：SEARCH() 函数
4.0 新增的 SEARCH() 函数，提供了一种类似 Elasticsearch Query String 的轻量级 DSL。它可以让你在一个函数中组合多字段、多条件的全文检索逻辑，并将可下推的条件推入倒排索引执行。

示例：

-- Term 查询
SELECT * FROM docs WHERE SEARCH('title:apache');

-- ANY：匹配任意一个值
SELECT * FROM docs WHERE SEARCH('tags:ANY(java python golang)');

-- ALL：要求同时包含所有值
SELECT * FROM docs WHERE SEARCH('tags:ALL(machine learning)');

-- 多字段布尔组合
SELECT * FROM docs
WHERE SEARCH('(title:Doris OR content:database) AND NOT category:archived');

-- 结合结构化过滤
SELECT * FROM docs
WHERE SEARCH('title:apache') AND publish_date >= '2025-01-01';

丰富的全文操作符
除了 SEARCH()，Doris 还提供了 MATCH_ANY、MATCH_ALL、MATCH_PHRASE、MATCH_PHRASE_PREFIX、MATCH_REGEXP 等操作符，用于覆盖关键词匹配、短语匹配、前缀匹配和正则匹配等多种场景。

示例：全文检索 + 相关性排序

SELECT id, title, price, score() AS relevance
FROM product_table
WHERE title MATCH_ANY '手机'
AND price <= 5000
ORDER BY relevance DESC
LIMIT 10;

在上述查询中：

• MATCH_ANY ‘手机’ 使用倒排索引进行关键词匹配。
• score() 使用 BM25 算法计算相关性得分。
• 最终结果按相关性得分排序返回 TopN。

2. 向量搜索：HNSW 向量索引 + ANN 检索

Doris 4.0 引入了原生的向量索引能力，使得用户可以在同一个分析引擎中完成结构化查询与向量相似度检索，无需额外部署独立的向量数据库。

技术原理

向量存储
向量列的类型为 ARRAY<FLOAT> NOT NULL，并且要求导入向量的维度必须与创建索引时指定的 dim 参数完全一致。

HNSW 向量索引
目前支持的索引类型为 HNSW（Hierarchical Navigable Small Worlds），它通过图结构来实现高效的近似最近邻（ANN）检索。创建索引时需要指定以下属性：

• index_type: 必填，当前支持 hnsw。
• metric_type: 必填，l2_distance 或 inner_product。
• dim: 必填，向量维度。
• quantizer: 可选，flat / sq8 / sq4，用于控制量化方式和内存占用。
• 其他如 max_degree、ef_construction 等参数，用于控制 HNSW 图结构的构建和性能。

相似度函数
Doris 提供了近似相似度计算函数：

• l2_distance_approximate()：基于欧氏距离（L2），值越小越相似。
• inner_product_approximate()：基于内积，值越大越相似。

混合检索与预过滤
Doris 默认采用“先过滤后向量 TopN”的预过滤机制。即先利用可以精确定位的索引（如倒排索引、结构化条件）快速缩小候选集，再在剩余数据上执行 ANN 检索。这种策略兼顾了查询的可解释性和整体性能。

示例：建表与向量检索

建表并同时创建 HNSW 向量索引与文本倒排索引：

CREATE TABLE doc_store (
  id BIGINT,
  title STRING,
  tags ARRAY<STRING>,
  embedding ARRAY<FLOAT> NOT NULL,
  INDEX idx_vec (embedding) USING ANN PROPERTIES (
    "index_type"   = "hnsw",
    "metric_type"  = "l2_distance",
    "dim"          = "768",
    "quantizer"    = "flat"  -- flat / sq8 / sq4
  ),
  INDEX idx_title (title) USING INVERTED PROPERTIES ("parser" = "english")
)
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 16
PROPERTIES("replication_num"="1");

TopN 向量检索：

SELECT id, l2_distance_approximate(embedding, [...]) AS dist
FROM doc_store
ORDER BY dist ASC
LIMIT 10;

混合检索（文本过滤 + 标签过滤 + 向量 TopN）：

SELECT id, title,
       l2_distance_approximate(embedding, [...]) AS dist
FROM doc_store
WHERE title MATCH_ANY 'music'  -- 使用倒排索引过滤
AND array_contains(tags, 'recommendation')  -- 结构化过滤
ORDER BY dist ASC
LIMIT 5;

范围查询：

SELECT COUNT(*)
FROM doc_store
WHERE l2_distance_approximate(embedding, [...]) <= 0.35;

3. AI 函数：在 SQL 中直接调用外部大模型

Doris 4.x 内置了一组 AI 函数，允许用户直接在 SQL 中调用外部 LLM 服务（如 OpenAI、Anthropic、Gemini、DeepSeek 或本地模型等），轻松完成文本生成、翻译、摘要、分类、情感分析等任务。模型本身由外部提供，Doris 通过统一的 RESOURCE 机制来管理访问配置。

支持的 AI 函数类型

• AI_CLASSIFY：信息分类，从给定标签中选出最匹配的一个。
• AI_EXTRACT：按标签从文本中抽取关键信息。
• AI_FILTER：判断文本是否满足特定条件，返回布尔值。
• AI_FIXGRAMMAR：语法与拼写纠错。
• AI_GENERATE：根据输入提示生成文本。
• AI_MASK：按标签对文本中的敏感信息进行脱敏，替换为 [MASKED]。
• AI_SENTIMENT：情感分析，返回 positive / negative / neutral / mixed。
• AI_SIMILARITY：计算两段文本的语义相似度，返回 0–10 的浮点数。
• AI_SUMMARIZE：生成文本摘要。
• AI_TRANSLATE：将文本翻译为指定语言。
• AI_AGG：对多行文本进行跨行聚合分析。

配置 AI Resource

在使用 AI 函数前，需要创建一个 type = ‘ai’ 的 Resource，用于配置外部模型的访问信息，例如：

CREATE RESOURCE "ai_resource_name"
PROPERTIES (
  'type' = 'ai',
  'ai.provider_type' = 'openai',
  'ai.endpoint' = 'https://endpoint_example',
  'ai.model_name' = 'model_example',
  'ai.api_key' = 'sk-xxx',
  'ai.temperature' = '0.7',
  'ai.max_tokens' = '1024',
  'ai.max_retries' = '3',
  'ai.retry_delay_second' = '1'
);

然后，可以通过会话变量设置默认使用的资源：

SET default_ai_resource = ‘ai_resource_name’;

调用时，可以显式指定资源，也可以省略参数以使用默认资源：

-- 使用默认资源
SELECT AI_SENTIMENT('Apache Doris is a great DBMS.');

-- 显式指定资源
SELECT AI_TRANSLATE(‘ai_resource_name’, ‘this is a test’, ‘Chinese’);

示例：摘要、情感分析与语义筛选

示例 1：生成摘要
使用 AI_SUMMARIZE 对长文本生成摘要（具体的提示词和长度控制可通过函数参数或设计 prompt 实现）：

SET default_ai_resource = ‘ai_resource_name’;

SELECT id, title,
       AI_SUMMARIZE(content) AS summary
FROM news_table
LIMIT 3;

示例 2：情感分析
对用户评论进行情感分类：

SET default_ai_resource = ‘ai_resource_name’;

SELECT comment,
       AI_SENTIMENT(comment) AS sentiment
FROM user_comment_table;

示例 3：语义筛选（招聘场景）

SELECT
    c.candidate_id, c.name,
    j.job_id, j.title
FROM candidate_profiles AS c
JOIN job_requirements AS j
WHERE AI_FILTER(CONCAT('Does the following candidate self-introduction match the job description?',
'Job: ', j.jd_text, ' Candidate: ', c.self_intro));

三、Doris AI 的核心技术优势：对比“多系统联动”

Doris 4.x AI 能力相对于传统的多系统拼装方案，具有以下显著优势：

一体化引擎，减少系统拼装

• 在一个 Doris 集群中即可同时完成结构化分析、全文检索、向量搜索和 AI 函数调用。
• 不再必须额外部署独立的向量数据库和搜索引擎，系统架构更加简洁。
• AI 模型通过 Resource 统一接入外部 LLM 服务，而非在应用层各自为政地调用。

数据同源，降低同步与延迟成本

• 结构化数据、文本数据、向量数据都统一存储在 Doris 中，避免了跨系统数据同步的麻烦。
• 查询可以在同一个执行计划中完成“结构化过滤 + 文本检索 + 向量匹配 + AI 分析”，极大减少了网络传输与序列化/反序列化的开销。

SQL 原生调用，降低开发门槛

• 文本搜索通过 MATCH_* 和 SEARCH()，向量搜索通过 l2_distance_approximate / inner_product_approximate，AI 能力通过 AI_* 函数，全部在 SQL 中完成。
• 数据分析师和工程师可以在他们最熟悉的 SQL 语境下，构建起复杂的 AI 数据处理工作流，这无疑大大降低了 人工智能 技术的应用门槛。

混合查询优化，面向 AI 场景调优

• 查询优化器能够智能地将可下推的条件（如利用倒排索引、向量索引）推入存储层执行。
• 支持“先结构化/文本过滤，再向量 TopN”的预过滤策略，在保证性能的同时也兼顾了结果的可解释性。

兼容主流 AI 生态，灵活选择模型

• 通过 ai.provider_type 支持 OpenAI、Anthropic、Gemini、DeepSeek、Local、MoonShot、MiniMax、智谱、通义千问、百川等多种提供方。
• 既可以接入公有云的 LLM 服务，也可以接入本地部署的模型，在成本与数据隐私之间提供了灵活的选择。

四、总结：让 AI 数据处理“简单、高效、低成本”

在AI驱动的数据应用场景下，Apache Doris 4.x 致力于成为“一套同时支持分析、全文检索和向量搜索的一体化引擎”，并通过原生的 AI 函数将 LLM 能力无缝引入 SQL 工作流。

简化架构

在一个 Doris 集群中集成多项能力，减少了对独立搜索/向量引擎的依赖，显著降低了系统数量和日常运维的复杂度。

降低门槛

所有增强能力均通过 SQL 原生调用，数据团队无需额外学习多套 DSL 或 SDK，即可快速构建从数据查询到 AI 分析的端到端链路。

提升效率

数据同源存储，结合面向 AI 场景深度优化的查询执行（倒排索引、向量索引、BM25 评分、预过滤等），能够显著降低查询延迟，非常适用于实时分析、RAG 检索、智能推荐、风险控制等在线业务场景。

通过原生集成 AI 能力，Apache Doris 4.x 为处理融合了结构化与非结构化数据的复杂 大数据 智能分析需求，提供了一套更简洁、更高效、更易用的解决方案。欢迎在 云栈社区 交流更多关于 Doris 及其 AI 特性的实践经验。