AI 時代正在重塑數據庫的角色。過去，數據庫主要為人類分析者提供報表與查詢能力；而現在，越來越多的查詢來自智能代理（Agent），它們會自動檢索知識、過濾數據、組合多種信號，並將數據庫作為“實時信息源”支撐推理與決策。

這一根本性變化，對數據庫的檢索能力提出了全新挑戰。傳統單一的搜索模式（無論是關鍵詞還是向量搜索）已顯不足，在應對複雜多模態的 Agent 查詢時，往往在缺乏結果的全面性、語義的精確性以及流程的可控性。而這就要求數據庫同時具備三種能力，將結構化分析、文本搜索和向量語義搜索集為一體，實現高效的混合搜索能力。特別是在以檢索增強生成（RAG）為代表的應用中，混合搜索能力變得更為關鍵，已成為避免幻覺、提高相關性與保持實時性的基礎能力。

1. 多系統拼接方案的痛點

為實現混合搜索的能力，許多系統採用“向量數據庫 + 搜索數據庫 + OLAP 數據庫”組合式架構來支撐類似能力。然而，多系統拼接會帶來一系列問題：

• 數據冗餘與複雜 ETL：文本數據庫、向量數據庫與分析數據庫分別持有不同格式的數據副本，任何更新都需要跨系統同步，導致延遲與運維成本上升。
• 查詢鏈路長、延遲高：一次混合搜索需要多次跳轉調用，例如先在向量庫召回、再到搜索庫過濾、最後進入 OLAP 聚合，成倍增加的鏈路延遲遠高於單引擎執行。
• 難以保障一致性：數據按不同時間寫入不同系統，搜索結果與結構化結果可能基於不同版本的數據，難以保障 Agent 邏輯穩定性。
• 調度無法統一：每個系統有獨立的優化器，無法形成全局執行計劃，也無法共享過濾、分區裁剪或索引下推。

這些問題共同形成所謂的“數據煙囱”效應，使本應一次完成的混合查詢被迫拆成多段執行，不僅增加複雜度，也使其在 RAG、Agent、推薦等對延遲敏感的場景中無法真正落地。

2. HSAP：面向 AI 應用的混合搜索與分析處理

相對而言，Hybrid Search and Analytics Processing（HSAP） 是當下更優的解決方案。它能在同一引擎中同時處理結構化分析、全文搜索和向量搜索，並通過統一優化器調度協同執行。

在 HSAP 模型下，不同搜索方式不再彼此獨立，共同參與完整的查詢生命週期，滿足語義廣度、關鍵詞精確匹配以及業務約束等多維需求。在實際執行中，HSAP 的查詢流程通常呈現為簡潔且高效的協同模式，流程如下：

A. 單次查詢請求（Single Request）

用户僅需提交一次查詢請求，該請求可同時包含文本檢索、向量檢索和複雜的結構化分析需求（過濾、聚合統計、排序等）。這些需求以統一的 SQL 表達，進入同一個執行計劃。

B. 並行執行（Parallel Execution）

系統並行化處理兩種搜索負載：

• 文本搜索通過倒排索引查詢，完成關鍵詞匹配和 BM25 排序召回
• 向量搜索通過 ANN 索引查詢，完成語義相似度召回，其中結構化過濾作為前過濾（縮小候選數據量）或後過濾（對召回結果進一步篩選）統一參與執行

這種並行化和下推機制，使得整體延遲僅受限於最慢的單一搜索路徑，而非多系統串聯調用的鏈路延遲，從根本上提升了查詢的效率。

C. 結果融合與分析（Result Fusion & Analytics）

各搜索路徑生成 Top-K 結果後，系統利用 RRF 算法生成統一排序；隨後依託 OLAP 引擎的分析處理能力，執行復雜的統計聚合與明細查詢，直接返回完整的分析結果。

3. Apache Doris HSAP 的實現

HSAP 模型提供了理想的理論框架，而 Apache Doris 則是一個將其工程化落地的典範。Doris 通過統一的存儲格式、執行引擎和 SQL 工作流，將結構化分析、倒排索引和向量索引三大能力整合為一個系統，實現了高效的混合搜索和實時分析能力。

而 Apache Doris HSAP 能力的實現並非一蹴而就，整體架構的演進分為三個階段，如下所示。自 2.x 版本起奠定了基礎，最終在 4.0 版本實現了融合檢索，升級為文本與向量並重的混合搜索體系。接下來，我們將逐一介紹 Apache Doris HSAP 核心能力、最佳實踐以及性能表現。

4. 基於倒排索引的高性能文本分析

文本搜索能力對於大型語言模型（LLM）是不可或缺的基石，從根本上決定了 LLM 應用的可靠性、準確性和實用性。Apache Doris 主要基於倒排索引實現了高性能的文本分析能力。

倒排索引基本原理是將文本拆分成詞項（Term），並記錄每個詞項出現的文檔。查詢時無需逐行掃描，直接通過索引定位相關行號，將查詢複雜度從 O（n） 下降到 O（log n） 級別。為了讓搜索能力真正適配 AI Agent 的分析場景，Doris 對倒排索引進行了系統化的架構設計與工程優化。

1. 在結構上：Doris 實現了外掛式索引結構，可將倒排索引與 segment 數據文件解耦，作為獨立文件存儲。這種結構更加靈活，可在已有表上直接新增倒排索引，無需重建數據和下線業務。並支持按需異步與增量式構建索引，有效避免對在線服務的衝擊。此外，索引在 compaction 階段可不按照數據重寫，僅需對索引內容進行合併，減少分詞帶來的資源消耗。
2. 在查詢上：引入雙層索引緩存體系，對象緩存減少文件 IO，查詢緩存避免重複執行。同時優化了索引查詢不回表策略，針對 COUNT 統計或純謂詞過濾場景，當查詢條件僅依賴倒排索引即可判定結果時，執行引擎將直接跳過數據文件（Data Segment）的讀取與解壓，僅通過索引文件完成計算，這樣可將 I/O 開銷降至最低，提升了聚合分析吞吐量。
3. 在存儲上：為更好在性能與存儲成本間取得平衡，Doris 引入了多種自適應壓縮算法，對倒排索引的詞典、倒排表、短語位置等信息進行壓縮存儲。
4. 內置分詞器及自定義分詞：內置多種分詞器，覆蓋中英文、多語種 Unicode、ICU 國際化等主流語言；同時支持自定義分析器，可配置字符清洗、分詞模式、停用詞、拼音轉換、大小寫規整等能力。
5. 豐富的查詢算子：在倒排索引的基礎上，Doris 實現了完整的搜索算子體系，完整可見下圖：

6. BM25 相關性打分：

BM25（Best Matching 25）是一種基於概率的文本相關性評分算法，廣泛應用於全文搜索引擎中。Doris 4.0 版本引入 BM25，為倒排索引查詢提供了相關性評分功能.BM25 可根據文檔長度動態調整詞頻權重，在長文本、多字段檢索場景下（如日誌分析、文檔檢索），顯著提升結果相關性與檢索準確性。

在 Doris 這樣的分佈式架構下，BM25 打分流程有三個階段。該流程對 Tablet 級 和 Segment 級分別統計，可有效保證穩定性。

階段 1：在 Tablet 級別執行，負責遍歷所有 Segment 並收集 BM25 計算所需的全局元數據：

• 統計收集： 累加總文檔數 （$$N$$） 和每個詞項的全局文檔頻率 （$$f(qi,D)$$）。
• 平均計算： 累加所有文檔的總詞數，計算出全局的平均文檔長度 （$$avgdl$$）。
• 核心產出： 根據 $$N$$和 $$f(qi,D)$$計算出每個查詢詞項的 全局 $$IDF $$值。

階段 2：在 Segment 級別執行，並行計算 BM25 分數並篩選 Top-K。由於 BM25 的計算是文檔獨立的（一旦$$IDF $$確定，文檔分數只依賴自身信息），每個 Segment 可以利用階段 1 提供的全局統計信息，獨立並行地完成打分和局部裁剪：

• 並行打分： 每個 Segment 使用全局$$IDF $$，結合自身的詞頻 （$$f(qi,D)$$） 和文檔長度 （$$|D|$$），計算所有匹配文檔的 BM25 分數。
• 局部裁剪： 在 Segment 內部直接執行 Top-K 篩選，只保 b 留和返回排名最高的文檔 ID 和對應的分數，減少數據傳輸開銷。

階段 3：上層彙總，合併各 Segment 的 Top-K。查詢的彙總節點（如 Backend 的聚合層）收集所有並行 Segment 返回的局部 Top-K 結果，進行全局歸併排序，最終生成滿足用户需求的 Top-K 結果集。

5. 基於 ANN 索引拓展 Doris 語義搜索

隨着語義向量在 AI 與檢索場景中的廣泛使用，向量搜索逐漸成為數據庫的基礎能力。Doris 在 4.0 版本中將向量索引納入其統一的索引架構，使向量搜索與結構化過濾、全文搜索在同一執行框架內協同工作，實現高效、可控、可擴展的語義搜索能力。

一般來説，向量索引的構建會消耗大量計算資源，尤其在億級 Embedding 的場景中。而 Doris 的向量索引與倒排索引採用一體化架構，用户可以像處理倒排索引一樣異步構建向量索引，最大限度降低對寫入性能的影響。同時，調整向量索引構建參數時，用户可以輕鬆進行索引的刪除與重建。

5.1 Doris 向量索引介紹

向量搜索通常需要在“召回率、查詢延遲、構建開銷”之間取得平衡，因此 Doris 內置了兩類主流 ANN 索引：HNSW 與 IVF。

• HNSW（Hierarchical Navigable Small World）基於分層圖結構，能夠在搜索時快速從稀疏層縮小範圍，並在底層進行精細查找。其優勢包括：高召回率，在語義檢索中接近精確搜索效果；低延遲，查詢複雜度接近 O(log n)，適合大規模場景；可調節精度，通過 ef_search 等參數動態控制召回率和延遲。HNSW 是業界應用最廣泛的 ANN 索引，在 RAG、問答檢索和相似度搜索等場景中至關重要。

• IVF（Inverted File Index）通過聚類（如 k-means）將向量劃分到不同分桶，僅在最相關的分桶中進行搜索。其構建速度快、資源佔用低，適合百萬至千萬級的大規模向量庫；可通過 nprobe 控制召回率與查詢速度的平衡。與 HNSW 相比，IVF 更適合於日誌、埋點和商品向量等“規模大但查詢精度可調”的場景。

5.2 支持多種向量查詢模式

此外，Doris 支持多種高效向量查詢模式，能夠滿足不同的搜索需求。下方將結合示例進行介紹：

A. Top-K 最近鄰檢索：支持 L2 距離與內積（Inner Product）兩種相似度度量，快速找出與目標向量最相似的前 K 個結果。

SELECT id, inner_product_approximate(embedding,[0,11,77...]) as distance FROM sift_1M ORDER BY distance limit 10
SELECT id, l2_distance_approximate(embedding,[0,11,77...]) as distance FROM sift_1M ORDER BY distance limit 10

B. 近似範圍查詢（Range Search）：支持對距離設置閾值條件，篩選出相似度在指定範圍內的所有項。

SELECT count(*)
FROM   sift_1m
WHERE  l2_distance_approximate( embedding, [0,11,77,...]) > 300 

C. 組合搜索：在同一條 SQL 中同時進行 ANN TopN 與 Range 條件過濾，返回滿足範圍約束的 TopN。

SELECT id,
       l2_distance_approximate(
        embedding, [0,11,77...]) as dist
FROM sift_1M
WHERE l2_distance_approximate(
        embedding, [0,11,77...])
        > 300
ORDER BY dist limit 10

5.3 量化與編碼機制

向量表示通常在維度和數據量上都非常龐大，帶來了顯著的計算和內存挑戰，而量化與編碼機制能夠在性能、精度和成本之間達到最優平衡。目前 Doris 編碼方式主要採用 FLAT 編碼，HNSW 索引本身會佔用較大內容，進行編碼後必須全量駐留內存才能工作，尤其在超大規模數據集上易成為瓶頸。

對於該問題，量化可以很好的平衡。標量量化 SQ 通過壓縮 FLOAT32 減少內存開銷；乘積量化 PQ 通過分解高維向量並分別量化子向量來降低內存開銷。

Doris 當前支持兩種標量量化：INT8 與 INT4（SQ8 / SQ4），通過壓縮 FLOAT32 減少內存開銷。以 SQ8 為例：在 768 維的 Cohere-MEDIUM-1M 與 Cohere-LARGE-10M 數據集測試中，SQ8 可將索引大小壓縮至 FLAT 的約 1/3。

Doris 也支持乘積量化， 通過分解高維向量並分別量化子向量來降低內存開銷，PQ 量化可將索引大小壓縮至 FLAT 的約 1/5 左右。需要注意的是在使用 PQ 時需要提供額外的參數（詳見文檔：https://doris.apache.org/zh-CN/docs/4.x/ai/vector-search/inde...）

6. HSAP 高效分析的關鍵

如果説上述能力是構成 HSAP 混合搜索能力的技術基礎，那麼如何讓各模塊高效的協同、運轉也是一大核心所在。眾所周知， Doris 一貫以實時、極速著稱，那麼 Doris 是如何提供高效混合搜索體驗的呢？

6.1 前過濾性能優化

前過濾是混合檢索常用的執行模型：先通過結構化謂詞條件在大規模數據集中篩選候選行，然後對這些行進行相似度計算或打分。該模型的性能瓶頸在於：如果底層引擎無法支持海量數據的極速過濾，將會影響整體查詢的效率。而 Doris 自身所具備的能力優勢，能夠很好的規避該問題。具體能力如下：

• 分區 / 分桶裁剪：從物理佈局上縮小掃描範圍。在查詢計劃生成階段，優化器根據謂詞條件自動完成分區與分桶裁剪，僅訪問相關的 Tablet，從而減少每次查詢需掃描的數據塊，大幅降低系統負載。
• 索引加速過濾：Doris 採用多層索引體系，包括內置索引（zonemap、前綴索引以及排序鍵等）和二級索引（倒排索引、bloom filter 索引等），可在掃描前快速判定數據塊是否命中查詢條件，以跳過絕大多數無關數據。
• Pipeline 與向量化執行模型：Doris 充分利用多核 CPU 並行和內存的局部性，在執行階段提升算子吞吐與查詢併發度，從根本上確保混合檢索的高效執行。

6.2 虛擬列機制

在傳統架構中，混合搜索中的文本搜索打分函數和向量搜索相似度計算函數會在上層聚合節點和下層掃描節點重複計算，而在 Doris 4.0 中創新性的引入虛擬列機制，優化了這一過程。

具體而言，FE 規劃時將打分以及距離計算等函數映射為虛擬列，並將虛擬列的計算下推到掃描節點。掃描節點在索引過濾階段直接計算這些虛擬列結果，並填充到最終結果中。在該過程中，上層僅需做結果融合與排序，顯著降低 CPU 消耗與數據傳輸。

6.3 TopN 延遲物化

文本搜索打分函數和向量搜索相似度計算函數都是SELECT yyy FROM tableX ORDER BY xxx ASC/DESC LIMIT N 這種典型的 TopN 查詢模式，當數據規模龐大時，傳統執行方式需對全表數據進行掃描並排序，這會導致大量不必要的數據讀取，引發讀放大問題。

為解決這一問題，Doris 引入延遲物化機制，將 TopN 查詢拆解為兩階段高效執行：第一階段僅讀取排序字段（columnA）與用於定位數據的主鍵 / 行標識，通過排序快速篩選出符合 LIMIT N 條件的目標行；第二階段再基於行標識精準讀取目標行的所有列數據。該方案能大幅削減非必要列的讀取量，在寬表小 LIMIT 場景下，TopN 查詢的執行效率有數十倍的提升。

7. 最佳實踐

為了驗證 Apache Doris 在真實業務數據上的混合搜索性能，我們基於公開的 Hacker News 數據集進行了性能測試。該數據集涵蓋多維、文本和向量分析三種類型，是檢驗 Doris HSAP 統一引擎特性的權威樣本。

測試方式

在 AWS 環境構建一個完整的端到端測試，從數據加載到 RRF 融合查詢，完整驗證 Doris 在語義搜索、文本搜索與結構化過濾三合一場景下的性能表現。

硬件環境

• AWS EC2 實例：m6i.8xlarge（32 vCPU，128 GiB 內存）
• 單節點部署 Apache Doris 4.0.1 版本

數據集

• 數據源：Hacker News 公開數據集
• 數據規模：2874 萬條記錄
• 向量維度：384 維（由 all-MiniLM-L6-v2 模型生成）
• 字段類型舉例：文本（text， title）、結構化（time， post_score）、向量（vector）

7.1 建表與索引設計

Doris 允許在同一張表中定義倒排索引與向量索引，從而實現“文本 + 向量 + 結構化”查詢的無縫結合。

CREATE TABLE hackernews (
  id           INT NOT NULL,
  text         STRING,
  title        STRING,
  vector       ARRAY<FLOAT> NOT NULL,
  time         DATETIME,
  post_score   INT,
  dead         TINYINT,
  deleted      TINYINT,
  INDEX ann_vector (`vector`) USING ANN PROPERTIES (
    "index_type"="hnsw",
    "metric_type"="l2_distance",
    "dim"="384",
    "quantizer"="flat",
    "ef_construction"="512"
  ),
  INDEX text_idx (`text`) USING INVERTED PROPERTIES("parser"="english", "support_phrase"="true"),
  INDEX title_idx (`title`) USING INVERTED PROPERTIES("parser"="english", "support_phrase"="true")
)
ENGINE=OLAP
DUPLICATE KEY(`id`)
DISTRIBUTED BY HASH(`id`) BUCKETS 4
PROPERTIES("replication_num"="1");

• text， title 字段用於全文搜索，創建英文分詞類型的倒排索引

• vector 字段用於 ANN 搜索，創建向量索引

  • "index_type"="hnsw"：採用 HNSW 算法。
  • "dim"="384"：必須與 all-MiniLM-L6-v2 模型輸出維度嚴格一致。
  • "quantizer"="flat"：指定使用 flat（浮點）進行量化，確保了最高的召回精度。在對內存佔用更敏感的場景下，可替換為 sq8（標量量化）。
  • "ef_construction"="512"：在索引構建階段設置較高的搜索上界（512），意味着在構建時投入更多資源，以建立一個連接更充分、質量更高的圖結構，從而為後續查詢提供更高的召回率。

7.2 數據導入

使用 Doris INSERT INTO ... FROM local() 功能，直接從本地磁盤加載 Parquet 文件，實現數據導入。

INSERT INTO hackernews
SELECT
  id,
  doc_id,
  `text`,
  `vector`,
  CAST(`node_info` AS JSON) AS nodeinfo,
  metadata,
  CAST(`type` AS TINYINT),
  `by`,
  `time`,
  `title`,
  post_score,
  CAST(`dead` AS TINYINT),
  CAST(`deleted` AS TINYINT),
  `length`
FROM local(
  "file_path" = "hackernews_part_1_of_1.parquet",
  "backend_id" = "1762257097281", -- 需替換為實際的 BE 節點 ID
  "format" = "parquet"
);

7.3 RRF 融合查詢

以下是一段 Doris 通過 SQL 實現 RRF 算法，將文本搜索和向量搜索的結果進行融合的示例查詢。

WITH
  text_raw AS (
      SELECT id, score() AS bm25
      FROM hackernews
      WHERE (`text` MATCH_PHRASE 'hybird search' 
             OR `title` MATCH_PHRASE 'hybird search')
        AND dead = 0 AND deleted = 0
      ORDER BY score() DESC
      LIMIT 1000
  ),
  vec_raw AS (
      SELECT id, l2_distance_approximate(`vector`, [0.12, 0.08, ...]) AS dist
      FROM hackernews
      ORDER BY dist ASC
      LIMIT 1000
  ),
  text_rank AS (
      SELECT id, ROW_NUMBER() OVER (ORDER BY bm25 DESC) AS r_text FROM text_raw
  ),
  vec_rank AS (
      SELECT id, ROW_NUMBER() OVER (ORDER BY dist ASC) AS r_vec FROM vec_raw
  ),
  fused AS (
      SELECT id, SUM(1.0/(60 + rank)) AS rrf_score
      FROM (
          SELECT id, r_text AS rank FROM text_rank
          UNION ALL
          SELECT id, r_vec  AS rank FROM vec_rank
      ) t
      GROUP BY id
      ORDER BY rrf_score DESC
      LIMIT 20
  )
SELECT f.id, h.title, h.text, f.rrf_score
FROM fused f JOIN hackernews h ON h.id = f.id
ORDER BY f.rrf_score DESC;

執行流程説明：

1. 並行召回：倒排索引與 ANN 索引分別執行 BM25 與 L2 距離召回
2. 局部排序：各自計算內部排名
3. 融合打分：執行 RRF 公式 1/(k+rank)，融合文本與語義結果
4. 最終回表：僅對 Top-K 結果 JOIN 原表獲取正文。

7.4 實際查詢測試

在相同的環境下，正式對 Apache Doris 的混合搜索性能進行了測試。在這一測試中，使用了 hybrid search 作為關鍵詞，進行了文本召回+向量召回+ RRF 融合。結果顯示，查詢延遲僅為 65.83 毫秒，體現了系統對複雜查詢的高效處理能力。

==================================================================================================================================
id       | title                                              |  rrf_score | text_snippet                                           
----------------------------------------------------------------------------------------------------------------------------------
845652   | Google Bing Hybrid Search - badabingle             |   0.026010 | beendonebefore:  thenewguy: Sure it steals google an...
2199216  |                                                    |   0.017510 | citricsquid:FYI DDG just uses the bing API and then ...
2593213  | Ask HN:Why there's no Regular Expression search... |   0.016390 | bluegene: What's keeping Google/other search engines...
6931880  | Introducing Advanced Search                        |   0.016390 | mecredis:                                              
3038364  | Bing Using Adaptive Search                         |   0.016120 | brandignity:                                           
1727739  |                                                    |   0.016120 | pavs:I think the name is the only thing that is wron...
18453472 | AdaSearch: A Successive Elimination Approach to... |   0.015870 | jonbaer:                                               
1727788  |                                                    |   0.015870 | epi0Bauqu:It's a hybrid engine. I do my own crawling...
2390509  | Reinventing the classic search model               |   0.015620 | justnearme:                                            
2199325  |                                                    |   0.015380 | epi0Bauqu:FYI: no, actually we are a hybrid search e...
26328758 | Brave buys a search engine, promises no trackin... |   0.015150 | samizdis:  jerf: "The service will, eventually,...
325246   | Future of Search Won’t Be Incremental              |   0.015150 | qhoxie:                                                
3067986  | Concept-Based Search - Enter the Interllective     |   0.014920 | hendler:                                               
3709259  | Google Search: Change is Coming                    |   0.014920 | Steveism:  victork2: Well Google, a word of warning ...
10009267 | Hulbee – A Safe, Smart, Innovative Search Engine   |   0.014700 | doener:  captaincrunch: My previous comment didn&#x2...
1119177  | Elastic Search - You Know, for Search              |   0.014700 | yungchin:                                              
4485350  |                                                    |   0.014490 | ChuckMcM:Heh, perhaps.<p>DDG is a great product, we ...
23476454 |                                                    |   0.014490 | Multicomp:AstroGrep! ronjouch: BareGrep! For live&#x...
7381459  | HTML5 Incremental Search                           |   0.014280 | ultimatedelman:                                        
4485488  |                                                    |   0.014280 | epi0Bauqu:Hmm, we're (DDG) not a search engine? Come...
==================================================================================================================================

結束語

綜上所述，Apache Doris 在複雜、高維的混合搜索場景中的優異表現，充分證明其以在 AI 時代數據基礎設施解決方案中佔據一席之地。其統一的 HSAP 架構從根本上滿足了 Agent 對多模態數據分析，應具備全面性、語義的精確性以及流程的可控性的需求。