IBM Granite Embedding Multilingual R2：ModernBERT 架構、32K 上下文、200+ 語言，Apache 2.0
huggingface.co · 2026-05-14
IBM Granite 團隊於 2026-05-14 發布 granite-embedding-97m-multilingual-r2 與 granite-embedding-311m-multilingual-r2 兩個嵌入模型，以 Apache 2.0 授權開放，同時支援 200 多種語言與 9 種程式語言。97M 參數版在 MTEB 多語言檢索基準上以三分之一的參數量，超越 gte-multilingual-base 等 300M 量級競爭者。
架構設計
兩個模型均建立在 ModernBERT 架構上，採用交錯注意力（alternating attention）與 Flash Attention 2.0，相較於 R1 版本的 XLM-RoBERTa，在長文件理解上有根本性改進。上下文視窗從 R1 的 512 tokens 擴展至 32K tokens（64 倍），對法律合約、學術論文、長篇代碼檔案等場景意義重大。
311M 版本支援 Matryoshka 表示學習（Matryoshka Representation Learning），允許在推理時從 768 維度截斷至 512/384/256/128 維，品質損失可控。訓練資料採用 IBM 策管的 GneissWeb 資料集，刻意排除 MS-MARCO 及非商業授權資料集，確保企業部署的授權合規性。
效能數據
| 基準 | 97M R2 | 311M R2 | vs R1 提升 |
|---|---|---|---|
| MTEB 多語言檢索 | 60.3 | 65.2 | +12~13 分 |
| 程式碼檢索 | 60.4 | 63.8 | +15~20 分 |
| 長文件（LongEmbed） | 65.6 | 71.7 | +31~34 分 |
長文件基準的提升幅度最顯著（+31~34 分），直接來自 32K 上下文的架構改動。程式碼檢索的大幅進步則得益於新版 tokenizer 對程式碼詞彙的更好覆蓋。
影響範圍
模型可作為 sentence-transformers、LangChain、LlamaIndex、Haystack 的直接替換——一行模型名稱更換即可讓現有 RAG pipeline 獲得多語言支援與 32K 上下文。arXiv:2605.13521 提供完整技術報告，OpenVINO 與 ONNX 格式亦已同步發布，支援邊緣部署場景。
Postgres FDW 下推協商：pg_clickhouse 如何決定哪些 SQL 在 ClickHouse 端執行
clickhouse.com · 2026-05-14
ClickHouse 工程師 Kaushik Iska、David Wheeler、Philip Dubé 詳細說明了 pg_clickhouse Foreign Data Wrapper（FDW）的查詢下推（pushdown）決策邏輯，展示「哪些 SQL 透過網路送至 ClickHouse 執行、哪些在 PostgreSQL 本地執行」對效能的決定性影響。
下推的重要性
文章以一個現實查詢為例：完全下推時約 80ms 完成；若任一條款無法下推，需從 ClickHouse 傳回數千萬列在 PostgreSQL 本地過濾，耗時可達 4 分鐘。查詢下推並非「有沒有效」的問題，而是「能不能用」的生死線。
規格細節
pg_clickhouse 在查詢計劃階段透過五個 FDW planning callback 決定可下推範圍。問題的核心在於兩個 SQL 語言語義的協商：PostgreSQL 與 ClickHouse 的 SQL 並不完全等價，即使看似相同的語法，在邊界行為（NULL 處理、浮點精度、時間函數語義）上可能存在差異。FDW 必須以保守的方式決定——有任何不確定性就不下推，確保語義完全等價。
文章按功能演進描述六個實作階段：基本掃描與簡單 WHERE → JOIN → GROUP BY 與聚合 → 百分位函數 → JSON 欄位存取 → 視窗函數。關鍵原則是任何一個子表達式無法翻譯，整個上層語句就不下推——即使是在大型 GROUP BY 語句中的一個百分位函數不支援，整個聚合操作都必須拉回本地執行。
影響範圍
對使用 pg_clickhouse FDW 或正在設計異構資料庫互連層的工程師而言，本文提供了判斷下推能力的系統性框架。文章最後強調：效能最佳化永遠讓步於語義正確性——下推是否安全的判斷比下推帶來的效能收益更為優先，錯誤的下推比未下推更危險。
原始來源：clickhouse.com
DuckDB Delta 擴充新增寫入、Unity Catalog 整合與時間旅行
duckdb.org · 2026-05-07
DuckDB 的 Delta Lake 擴充在近期更新中增加三項主要能力：直接寫入 Delta 格式（不再只讀）、Databricks Unity Catalog 整合（可直接查詢 UC 管理的資料表），以及時間旅行（time travel）查詢，使 DuckDB 從 Delta 的唯讀消費者晉升為可讀可寫的完整 Lakehouse 客戶端。
核心改動
寫入支援讓 DuckDB 可執行 COPY t TO 'delta://...' 或 INSERT INTO delta_table 等語句，在本地分析工作流結束後將結果直接持久化至 Delta Lake，無需外部 Spark 叢集中介。時間旅行語法採用 AT (VERSION => 42) 或 AT (TIMESTAMP => '2026-01-01')，對應 Delta Log 的事務版本。
Unity Catalog 整合允許 DuckDB 使用標準 UC 認證（PAT token 或 OAuth）直接讀取 Databricks 工作區中的受管資料表，查詢計劃在 DuckDB 本地執行，資料透過 Presigned URL 拉取至本地，UC 的存取控制與血緣追蹤仍在 Databricks 側生效。
影響範圍
這組更新的受益者是需要在 Spark/Databricks 生態與本地分析環境之間橋接的工程師。DuckDB 在小批次互動式分析上的效能優勢（毫秒級查詢啟動）與 Delta Lake 的大規模資料治理能力因此可以組合使用，而不需在兩個生態之間維護獨立的資料副本。
原始來源：duckdb.org