引言

隨著大模型和多模態 AI 的快速發展，向量已成為文本、圖像、音視頻等多元數據的通用語義表示。在這種背景下，檢索增強生成（RAG）技術成為連接私有知識與大模型的核心橋梁，而高效的向量檢索則是其關鍵支柱。

與將向量檢索視為獨立外掛服務的方案不同，Apache Doris 4.0 選擇將向量檢索能力深度集成于其 MPP 分析型數據庫內核。實現向量檢索與 SQL 計算、實時分析和事務保障的無縫融合。

本文旨在深入剖析 Doris 向量檢索的系統級設計與工程實踐，展示其如何在性能、易用性與規模擴展之間取得的平衡。

1. ANN 索引核心設計

Apache Doris 的向量索引基于 ANN（近似最近鄰）算法實現，并非獨立的外掛組件，而是深度集成于存儲、執行與 SQL 引擎中的原生能力。在 4.x 版本中，其核心 ANN 索引能力主要包括以下幾方面：

1. 多索引類型與距離度量支持：支持主流的 ANN 索引類型（HNSW、IVF）及常見距離度量（L2 距離、內積）。用戶可根據業務在構建速度、內存占用與召回率上的要求靈活權衡。
2. 原生 SQL 集成：向量檢索以原生 SQL 算子形式提供，支持直接定義向量列、通過 ORDER BY distance LIMIT K 進行相似度搜索，并能與過濾、聚合、JOIN 等算子自由組合，天然支持混合檢索與分析。
3. 構建與查詢解耦：采用異步索引構建機制，數據導入后即可查詢，索引在后臺構建并加載，避免導入阻塞，保障查詢高峰期的穩定低延遲寫入。
4. 向量壓縮優化：在導入與構建階段支持標量量化（SQ）、乘積量化（PQ）等壓縮技術，顯著降低存儲與內存開銷，提升高維大規模向量場景的資源效率。
5. 分布式并行執行：依托于分布式架構，Doris 向量索引天然支持數據分片與索引分布式存儲；查詢可在各 BE 節點并行執行；Top-K 結果在上層進行合并與裁剪。隨著節點數量增加，系統能夠在數據規模與吞吐能力上實現近線性擴展。

2. Benchmark & Analysis

Apache Doris 的目標并非追求單一指標的極限表現，而是在真實生產負載下，實現性能的均衡性、系統穩定性與架構可擴展性。本次測試將圍繞這一目標展開，所用工具為 ZillizTech 開源的向量搜索 BenchMark：https://github.com/zilliztech/VectorDBBench。

• 云服務商：阿里云
• CPU：Intel Xeon Platinum 8369B @ 2.70GHz (16 核)
• 內存：64GB

2.1 導入與構建性能

測試結果表明，在 Performance768D1M 數據集上，Apache Doris 在保證同等索引質量的前提下，導入性能顯著優于對比系統。尤為重要的是，其導入速度的提升并未以犧牲圖結構質量為代價。Doris 在 QPS 達到 895 的同時，仍保持了 97% 以上的召回率，在性能三角的三個維度上取得了出色的平衡。

2.2 查詢性能

即便單獨考量查詢性能，Apache Doris 同樣處于業界第一梯隊。

在 Performance768D10M 數據規模上，當召回率要求高于 95% 時，Apache Doris 的 QPS 表現優于 OpenSearch 與 Qdrant。此結果為默認配置下的開箱性能，未針對 Segment 文件數量等進行專項調優。

這里比較的是開箱性能測試，即不做 segment 文件數量的優化時的性能對比。

Milvus 的 flat 版本以及 Cloud 版本會有更好的性能表現，但是其出品的 VectorDBBench 只提供了 SQ8 量化后的成績。

3. 核心設計與性能優化

Apache Doris 采用 FE（協調節點）與 BE（計算節點）構成的分布式架構。BE 作為核心執行單元，承擔查詢計劃執行與數據導入任務，負責幾乎所有高負載計算與大規模數據吞吐，是系統高性能的基石。尤其在向量場景下，數據寫入、索引構建與向量距離計算都屬于典型的 CPU 與內存密集型工作。為充分發揮其性能、保障系統穩定運行，我們對 ANN 索引的寫入、構建與查詢路徑進行了系統優化。

3.1 寫入與構建路徑優化

優化主要分為兩類：功能優化與性能優化。

• 在功能層面，依托 Doris 成熟的分布式集群管理與存儲管理能力，引入 LightSchemaChange 實現輕量級的索引管理機制，這是目前專用向量數據庫普遍不具備的能力。
• 在性能層面，重點聚焦于索引構建流程的優化，以顯著提升索引構建速度和整體吞吐能力。

3.1.1 異步索引構建機制

Apache Doris 針對 ANN 索引構建開銷大的問題，提供了異步構建機制。用戶可在數據導入后，選擇業務低峰期觸發索引構建；在查詢高峰時，僅需將已建好的索引加載至內存即可快速檢索，從而將密集的 CPU 消耗轉移至成本更低的時段。

在 FE 側，CREATE INDEX 與 BUILD INDEX 通過 SchemaChangeHandler 編排：

1. 為每個分區創建影子索引與影子 Tablet（IndexState.SHADOW），并建立 origin→shadow 的 Tablet 映射與影子副本（副本初始態為 ALTER）。
2. 生成新的 schema version/hash，保障新舊版本隔離。
3. 通過 FE→BE 的 AgentTask（Thrift）分發構建任務到各 BE，BE 在 Tablet 層面完成索引數據構建。
4. 構建成功后，FE 原子性地將影子索引切換為正式索引，更新元數據并清理舊工件。

該流程在保證線上業務可讀寫的同時，實現了索引構建的在線隔離與數據一致性。

3.1.2 導入性能優化

為在保障索引質量的前提下提升寫入吞吐與穩定性，Doris 采用了 多層級分片、雙層并行、SIMD 向量化計算 的組合方式進行優化。

A. 多層級分片

Apache Doris 將邏輯表在內核層拆分為多個 Tablet。每次數據導入會生成一個 Rowset，每個 Rowset 又包含若干 Segment，而 ANN 索引正是在 Segment 粒度上構建與使用的。這一設計將“全表數據量”與“索引超參數”解耦，用戶只需根據單批次導入的數據規模來設定參數，無需因數據總量增加而反復重建索引。

以單 BE 單分桶的典型場景為例，我們從實際經驗中總結出如下參數可供參考：

得益于 Apache Doris 的分片架構下，索引參數可穩定在合理的規模區間，不受全表數據總量增長的影響。換言之，索引超參數的設置只需基于單個 Tablet 單次導入的數據行數。即便集群規模擴大，也僅需根據機器與分桶數量相應調整批次大小（batch size）即可。

以 HNSW 索引為例，在單 BE 集群中，針對每批導入 25 萬、50 萬、100 萬行的典型規模，分別選擇 max_degree≈100/120/150、ef_construction≈200/240/300、hnsw_ef_search≈50~200，即可在延遲可控的同時平衡召回與構建成本。

經驗上，召回率隨 hnsw_ef_search 提高而改善，但查詢延遲也會線性增加。max_degree 與 ef_construction 過小會導致圖結構稀疏、查詢不穩定；過大則會顯著增加構建時間與內存占用。因此，建議結合業務對召回和延遲的要求，通過離線壓測確定最佳參數組合。

B. 雙層并行構建

集群層由多臺 BE 并行處理導入批次；單機內再對同一批數據進行多線程距離計算和圖結構更新。配合“內存攢批”（在內存中適度合并小批次），可避免過細分批導致的圖結構稀疏與召回下滑，在固定超參數下獲得更穩定的索引質量與構建速度。

以 768 維、1,000 萬條向量為例：分 10 批構建的召回率約可達 99%，若切成 100 批則可能降至約 95%。適度的內存攢批既不顯著抬高內存峰值，又能提升圖連通性和近鄰覆蓋，從而減少查詢階段的回表與重復計算。

C. SIMD 加速

向量距離計算是典型的 CPU 密集型計算。Doris 在 BE 側采用 C++ 實現距離計算，引入 SIMD（單指令多數據）并行計算。可以更少的指令、更少的訪存，更快完成把同樣的距離，從而顯著提升向量索引構建和重排階段的吞吐能力。具體來講：

• 并行計算多個維度：利用 SSE / AVX / AVX-512 等指令集，同時加載和計算 8～16 個浮點數，而非逐維循環。
• 減少內存訪問：在計算前對向量數據進行批處理和轉置，使數據在內存中連續排列，優化 CPU Cache 訪問模式。
• 合并計算步驟：使用 FMA（乘加融合）指令，把“乘法 + 加法”合并為一步，并通過水平求和快速聚合向量數據。
• 高效處理邊界情況：對維度不對齊的尾部數據，使用掩碼指令統一處理，避免額外分支和判斷。

3.1.3 向量壓縮技術

以 HNSW 為代表的高性能索引數據結構通常將向量與圖結構常駐內存。在 RAG 場景中，文本/圖片/音頻等模態向量維度約為 1,000，若每維使用 FLOAT32 存儲，一百萬行占用 4 GB，千萬行則約 40 GB。考慮到索引結構的額外占用（約 1.3 倍），一千萬行整體接近 52 GB。以 16C64GB 機器為例，單機索引上限約為千萬級，需預留空間以避免 OOM，并保障查詢和構建的并行開銷。

為了顯著降低內存占用、擴展單機承載能力，向量壓縮技術成為關鍵。Apache Doris 在此提供了兩種主流的實現方案：標量量化與乘積量化。

A. 標量量化（Scalar Quantization，SQ）

標量量化通過用低精度類型替換高精度類型來壓縮存儲空間，Doris 支持 INT8 和 INT4 的標量量化，并在導入和構建階段完成編碼。

如若將 FLOAT32（4 字節）替換為 INT8（1 字節）可節省約 75% 存儲，進一步壓縮為 INT4 則節省約 87.5%。如果壓縮后數據的分布形態保持一致，召回率在可控延遲內接近未壓縮效果。

上圖展示了在 128 維和 268 維向量上的測試結果。相比 FLAT（不編碼，用完整 Float32 表示每個浮點數），SQ8 可實現接近 2.5 倍的壓縮，而 SQ4 可實現接近 3.3 倍的壓縮。

值得說明的是，引入 SQ 不可避免的會帶來額外的壓縮計算開銷（索引構建階段），且標量量化更適用于各維度近似均勻分布的數據。如遇分布呈高斯或更復雜形態時，標量量化誤差增大，則可采用乘積量化方式。

B. 乘積量化（Product Quantization， PQ）

RAG 等場景中，由 Transformer 編碼器生成的向量，存在明顯的語義結構、分布不均勻。乘積量化通過子空間劃分 + 子空間學習型量化，能夠更好地適配。

PQ 將高維向量分割為多個子向量，并為每個子空間獨立訓練一個碼本（例如通過 k-means 聚類學習質心）。這使得數據密集區域能用更精細的碼本保持細節，從而在整體上用更短的碼長維持原始的距離關系。查詢時通過查表與累加來估算距離，大幅減少了計算與內存訪問開銷。

我們在 128 維與 268 維上對比 SQ 與 PQ，參數統一設定為 pq_m = dim/2、pq_nbits = 8。

從空間占用看，PQ（m=68/128， nbits=8）的內存占比與 SQ4 大致相當，可實現約 3× 壓縮。

除構建更快外，PQ 還可依賴查表加速解碼，體現在更優的查詢速度上。

關于 PQ 的超參數，實際使用時建議結合數據分布進行針對性適配與調優。根據經驗，將 pq_m 設為原始維度的一半，pq_nbits 設為 8，在多數場景下即可取得良好的效果，可作為初始調優的參考起點。

綜合來看，對于用戶來說， SQ 和 PQ 該如何選擇呢？

• 從使用上來說，SQ 的優點是使用方式簡單，只需要指定數據類型即可，而 PQ 的使用門檻更高，需要對其原理有較為深刻的理解才能在生產環境中發揮其優勢。
• 從性能及開銷上來說，SQ 在解碼階段存在額外計算開銷，且隨維度增加開銷更高；PQ 則能在壓縮的同時保持接近原始向量的查詢性能。
• 從場景上來說，SQ 更適用于各維度近似均勻分布的數據。如遇分布呈高斯或更復雜形態時，標量量化誤差增大，則可采用乘積量化方式。

3.2 查詢執行路徑優化

搜索場景對延遲極為敏感。在千萬級數據量與高并發查詢的場景下，通常需要將 P99 延遲控制在 200 ms 以內。這對 Doris 的優化器、執行引擎以及索引實現都提出了更高要求。Apache Doris 為此做了大量優化，這一章節對其中涉及到的部分能力做介紹。

3.2.1 虛擬列機制

Apache Doris 的向量索引采用外掛方式。外掛索引便于管理與異步構建，但也帶來性能挑戰：如何避免重復計算與多余 IO？

ANN 索引在返回行號時，會同步計算出向量距離。執行引擎在 Scan 算子階段可直接利用該結果進行篩選和排序，無需在讀取數據后重新計算。這一過程通過 “虛擬列” 機制自動實現，最終以 Ann Index Only Scan 的形式運行，完全消除了因距離計算而產生的數據讀取 I/O。

未應用 Index Only Scan：

應用 Index Only Scan 后：

例如 SELECT l2_distance_approximate(embedding, [...]) AS dist FROM tbl ORDER BY dist LIMIT 100;，執行過程將不再觸發數據文件 IO。

該優化不僅適用于 TopK 檢索，也支持 Range Search、復合檢索（Range + TopK）以及與倒排索引結合的混合檢索場景，實現了全路徑的 Index Only Search。

虛擬列機制并不局限于向量距離計算。對于正則抽取、復雜標量函數等 CPU 密集型表達式，若在同一查詢中被多次引用，該機制也能復用中間結果，避免重復計算。以 ClickBench 數據集為例，以下查詢統計從 Google 獲得最多點擊的 20 個網站：

set experimental_enable_virtual_slot_for_cse=true;

SELECT counterid,
       COUNT(*)               AS hit_count,
       COUNT(DISTINCT userid) AS unique_users
FROM   hits
WHERE  ( UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) = 'GOOGLE.COM'
         OR UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) = 'GOOGLE.RU'
         OR UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) LIKE '%GOOGLE%' )
       AND ( LENGTH(regexp_extract(referer, '^https?://([^/]+)', 1)) > 3
              OR regexp_extract(referer, '^https?://([^/]+)', 1) != ''
              OR regexp_extract(referer, '^https?://([^/]+)', 1) IS NOT NULL )
       AND eventdate = '2013-07-15'
GROUP  BY counterid
HAVING hit_count > 100
ORDER  BY hit_count DESC
LIMIT  20;

核心表達式 regexp_extract(referer, '^https?://([^/]+)', 1) 為 CPU 密集型且被多處復用。啟用虛擬列優化（set experimental_enable_virtual_slot_for_cse=true;）后，端到端性能提升約 3 倍。

3.2.2 前過濾與謂詞下推

在 ANN TopN 檢索中，過濾謂詞的應用時機是關鍵的設計權衡：

• 前過濾：在 TopN 之前應用謂詞，能阻止無效行進入候選；但需在候選集維護過程中實時剔除不符合條件的行。
• 后過濾：先按相似度取出 TopN，再執行過濾，可能導致最終結果不足 N 條。雖然可通過擴大 N 來補償，但會額外增加掃描與計算開銷。

Apache Doris 在 Scan 算子內通過 row bitmap 實現自然的前過濾語義。每個謂詞執行后即時更新 row bitmap。當 TopN 下推到 Scan 時，向索引傳遞一個基于 row bitmap 的 IDSelector，僅保留滿足條件的行作為候選，從源頭上避免無效候選進入 TopN。

為進一步提升效率，Doris 還會在掃描前借助分區、分桶、ZoneMap 等輕量元數據進行快速預過濾，并結合倒排索引進行精確的行號定位，多層次縮小候選集，能夠顯著提升查詢性能與資源效率。

3.2.3 全局執行優化

在傳統執行路徑中，Doris 會對每條 SQL 執行完整優化流程（語法解析、語義分析、RBO、CBO）。這在通用 OLAP 場景必不可少，但在搜索等簡單且高度重復的查詢模式中會產生明顯的額外開銷。為此，Doris 進行了全局執行優化，充分發揮索引、過濾等性能。

A. Prepare Statement：

Doris 4.0 擴展了 Prepare Statement，使其不僅支持點查，也適用于包含向量檢索在內的所有 SQL 類型。Prepare Statement 的原理是將 SQL 編譯與執行分離，模板化檢索復用計劃緩存，Execute 階段跳過優化器。查詢計劃按“標準化 SQL + schema 版本”構建指紋進行緩存，執行階段校驗 schema version，變化則自動失效并重建。對頻繁且結構相同僅參數不同的檢索，Prepare 能顯著降低 FE 側 CPU 占用與排隊等待。

B. Scan 并行度優化：

為提升 ANN TopN 檢索性能，Doris 重構了 Scan 并行策略。原策略基于行數劃分任務，在高維向量場景下，單個 Segment 的實際行數常遠低于劃分閾值，導致多個 Segment 被分配至同一任務中串行掃描，制約性能。

為此，Doris 改為嚴格按 Segment 創建 Scan Task，顯著提升了索引檢索階段的并行度。由于 ANN TopN 搜索本身過濾率極高（僅返回 TopN 行），后續回表階段即使串行執行，對整體吞吐與延遲的影響也微乎其微。

以 SIFT 1M 數據集為例，開啟 optimize_index_scan_parallelism=true 后，TopN 查詢耗時從 230ms 降至 50ms，效果顯著。

此外，4.0 引入動態并行度調整：每輪調度前根據 Scan 線程池壓力動態決定可提交的任務數；壓力大則減并行、資源空閑則增并行，以在串行與高并發場景間兼顧資源利用率與調度開銷。

C. TopN 全局延遲物化：

典型的 ANN TopN 查詢可分為兩個關鍵階段：局部檢索與全局歸并。在局部檢索階段，Scan 算子通過索引獲取每個數據分片（Segment）中的局部 TopN 近似距離；隨后在全局歸并階段，由專門的排序節點對所有分片的局部結果進行合并，篩選出最終的全局 TopN。

傳統執行流程存在一個顯著效率問題：若查詢需要返回多列或包含大字段（如長文本），在第一階段就會讀取這些列的全部數據。這不僅會引發大量磁盤 I/O，而且絕大多數被讀取的行會在第二階段的排序競爭中被淘汰，造成計算與 I/O 資源的浪費。

為此，Doris 引入了 “全局 TopN 延遲物化” 優化。該機制將非排序所需列的讀取推遲到最終結果確定之后，大幅減少了不必要的 I/O。

優化執行流程示例：

以 SELECT id, l2_distance_approximate(embedding, [...]) AS dist FROM tbl ORDER BY dist LIMIT 100; 為例：

1. 局部輕量掃描：每個 Segment 利用 Ann Index Only Scan 結合虛擬列技術，僅計算出局部 Top 100 的距離值（dist）及其對應的行標識（rowid），不讀取其他列。
2. 全局排序篩選：系統匯總所有 M 個 Segment 的中間結果（共 100 × M 條候選），對其進行全局排序，從而確定最終的 100 個目標 rowid。
3. 按需延遲物化：最終的 Materialize 算子根據上一步得到的 rowid，精準地到對應的存儲位置讀取所需列（例如 id）的數據。

通過將完整數據的“物化”步驟推遲到最后，該優化確保了查詢前期僅處理輕量的距離與行標識信息，徹底避免了在排序前讀取非必要列所帶來的 I/O 開銷，從而顯著提升了整體查詢效率。

4. 實戰：使用 Apache Doris 搭建企業知識庫

企業級知識庫是 RAG 的典型落地場景。因此，我們基于 LangChain + Apache Doris 搭建了一個以 Doris 官網文檔為語料的最小可用知識庫，用于驗證 Doris 向量檢索的端到端能力。完整示例代碼見 GitHub。

（1）環境準備

• LLM：用于對話與答案生成，這里使用 DeepSeek。先在官網注冊并創建 API Key，妥善保存，后續用于調用 DeepSeek API。
• 嵌入模型：用于生成檢索向量，這里使用 Ollama + bge-m3:latest。bge-m3 是開源的通用檢索向量模型，兼顧中英文檢索效果，默認輸出 1024 維向量，適合知識庫檢索場景。

（2）建庫與建表（方式一：SQL）

CREATE DATABASE doris_rag_test_db;

USE doris_rag_test_db;

CREATE TABLE doris_rag_demo (
  id int NULL,
  content text NULL,
  embedding array<float> NOT NULL,
  INDEX idx_embedding (embedding) USING ANN PROPERTIES("dim" = "1024", "ef_construction" = "40", "index_type" = "hnsw", "max_degree" = "32", "metric_type" = "inner_product")
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"storage_medium" = "hdd",
"storage_format" = "V2",
"inverted_index_storage_format" = "V3",
"light_schema_change" = "true"
);

說明：若計劃使用 SDK 一鍵建表與導入（見 ⑤），本節可省略。

（3）演示語料

示例使用 Apache Doris 官網文檔作為語料來源：https://github.com/apache/doris-website

（4）離線文檔處理

• 切塊（chunking）：采用重疊分割，將長文檔切分為段落片段。

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=400, chunk_overlap=100, length_function=len
)
chunks = text_splitter.split_text(text)

• 生成向量（embedding）：對每個片段生成嵌入向量。

from typing import List, Dict
from langchain_community.embeddings import OllamaEmbeddings

embeddings = OllamaEmbeddings(model='bge-m3:latest', base_url='http://localhost:11434')

docs: List[Dict] = []
cur_id = 1
for chunk in chunks:
    docs.append({"id": cur_id, "content": chunk})
    cur_id += 1

contents = [d["content"] for d in docs]
vectors = embeddings.embed_documents(contents)

（5）導入 Doris（方式二：SDK 一鍵建表與導入）

import pandas as pd
df = pd.DataFrame(
        [
            {
                "id": d["id"],
                "content": d["content"],
                "embedding": vec,
            }
            for d, vec in zip(docs, vectors)
        ])

from doris_vector_search import DorisVectorClient, AuthOptions, IndexOptions

auth = AuthOptions(
    host='localhost',
    query_port=9030,
    http_port=8030,
    user='root',
    password='',
)

client = DorisVectorClient('doris_rag_test_db', auth_options=auth)

index_options = IndexOptions(index_type="hnsw", metric_type="inner_product")
table = client.create_table(
            'doris_rag_demo',
            df,
            index_options=index_options,
        )

說明：若已通過 ② 使用 SQL 創建好表并定義索引，可僅使用 SDK 的導入接口（如 insert/load 等，視 SDK 能力而定）將數據寫入既有表。

（6）在線查詢過程

向量檢索

query = 'Doris 支持哪些存儲模型？'
query_vec = embeddings.embed_query(query)
df = (
    table.search(query_vec)
    .limit(5)
    .select(["id", "content"])
    .to_pandas()
)

答案生成

ctx = "\n".join(f"{r['content']}" for _, r in df.iterrows())
prompt =  "以下是檢索到的 Doris 文檔片段：\n\n{}\n\n請根據上述內容回答：{}".format(ctx, query)

from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
            model='deepseek-v3-1-terminus',
            api_key='xxxx',
            base_url='https://xxx',
            temperature=float(1.0))
resp = llm.invoke(prompt)

返回的內容是：

'根據提供的文檔內容，Apache Doris 支持以下三種存儲模型：\n\n1.  明細模型（Duplicate Key Model）：適用于存儲事實表的明細數據。\n2.  主鍵模型（Unique Key Model）：保證主鍵的唯一性，相同主鍵的數據會被覆蓋，從而實現行級別的數據更新。\n3.  聚合模型（Aggregate Key Model）：相同鍵（Key）的數值列（Value）會被自動合并，通過提前聚合來大幅提升查詢性能。\n\n此外，文檔在“靈活建模”部分還提到，Apache Doris 支持如寬表模型、預聚合模型、星型/雪花模型等建模方式，這些可以看作是建立在上述三種核心存儲模型之上的數據組織方法。'

5. 總結

本文從 AI 時代的數據形態演進出發，系統性地介紹了 Apache Doris 在 4.x 版本中引入的向量檢索能力，并對其底層實現進行了深入剖析。從 ANN 索引的能力邊界，到 FE / BE 架構下的寫入、構建與查詢路徑，再到 SIMD、壓縮編碼與執行引擎層面的工程優化，Doris 的向量搜索并非簡單接入一個索引庫，而是圍繞 性能三角（召回率 / 查詢延遲 / 構建吞吐） 精心設計的系統級方案。未來，我們還會進一步強化，使其成為 AI 時代數據系統智能檢索的基石。