<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Reranking on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/reranking/</link><description>Recent content in Reranking on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 08 Jun 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/reranking/feed.xml" rel="self" type="application/rss+xml"/><item><title>FDE core topic - Re-ranking &amp; Cross-Encoder：向量粗召回後的精準重排序機制</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-5-reranking-cross-encoder-zh/</link><pubDate>Mon, 08 Jun 2026 10:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-5-reranking-cross-encoder-zh/</guid><description>核心定義：Re-ranking 是「先用 Bi-Encoder 快速縮小候選集，再用 Cross-Encoder 精準評分」的兩階段架構——用 10ms 的粗召回換取可接受的候選集，再用 150ms 的深度交互換取 LLM 真正需要的高品質上下文。
一、為什麼面試官問這個 面試官實際測試的能力：
你知道「快」和「準」之間的工程取捨嗎？ Bi-Encoder 可預計算、延遲低，Cross-Encoder 不可預計算但精準——能不能說清楚這兩者的差異，是區分背了課文還是真正理解原理的關鍵。 你能把數字說出來嗎？ 弱答：「Re-ranking 可以提升準確率。」強答：「ANN-only MRR@5 約 0.61，加上 Cross-Encoder 重排後升至 0.79，提升約 30%，幻覺率同步下降約 40%。」 你知道什麼時候不該用嗎？ 盲目加 Cross-Encoder 在延遲 SLA &amp;lt; 200ms 的場景會直接違反 SLA。強答必須包含 skip 條件。 弱答 vs 強答對比：
維度 弱答 強答 定義 「對搜索結果重新排序」 解釋 Bi-Encoder 獨立編碼 vs Cross-Encoder 聯合編碼的機制差異 數字 無 MRR@5 +30%、幻覺 -40%、延遲 +150ms、成本 +$0.002/query 取捨 「有點慢」 說明延遲預算分配：ANN 10ms + CE 150ms + LLM 800ms ≈ 960ms 跳過條件 未提及 明確指出 &amp;lt;200ms SLA 應改用 ColBERT 或接受 ANN 品質 二、核心原理與技術深度 Bi-Encoder 與 Cross-Encoder 的本質差異 兩種模型架構解決同一個問題（語意相關性），但用完全不同的方式：</description></item><item><title>FDE 面試準備指南（五）：RAG 深度技術——Chunking、Embedding、向量資料庫與混合搜尋</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part5-rag-deep-dive-zh/</link><pubDate>Sun, 31 May 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part5-rag-deep-dive-zh/</guid><description>第一篇講了 RAG 是什麼。
這篇講你在面試中被追問到第三層時，你能不能答上來。
面試官最喜歡的問法是：「那你為什麼這樣設計？有沒有考慮過別的方案？」
面試情境 面試官：「你的 RAG 系統 Chunking 怎麼設計的？為什麼？你的 Embedding 模型怎麼選的？如果純向量搜尋找不到正確答案，你怎麼改善？Context Window 滿了怎麼辦？」
這四個問題是 RAG 系統設計的完整追問鏈。每一層都要能說清楚選擇背後的 trade-off。
一、Chunking 策略：不是切越小越好 Chunking 是 RAG 最常被輕描淡寫的環節，但它直接決定你的檢索品質。
面試官問法通常是：
「你的 RAG 系統 Chunking 怎麼設計的？為什麼？」
Fixed-Size Chunking（固定大小切分） 最簡單的做法：每 N 個 token 切一塊，加上一點 overlap。
chunk_size = 512 chunk_overlap = 50 優點：
實作簡單 預測性高，每塊大小一致 Embedding 成本可控 缺點：
完全不管語意邊界 一個句子可能被切成兩半 段落邏輯可能斷裂 適用場景：
文件格式高度結構化（例如：財報、合約） 快速原型，先跑起來再優化 Semantic Chunking（語意切分） 根據語意相似度決定切分點。計算相鄰句子的 embedding 距離，距離突然變大的地方就是自然的段落邊界。
優點：
保留語意完整性 每塊的內聚度更高，向量品質更好 特別適合長文、報告、文章 缺點：
計算成本更高（每個句子都要先 embed） Chunk 大小不固定，向量 DB 設計要考慮 實作複雜度較高 工具： LangChain 的 SemanticChunker、llmsherpa</description></item></channel></rss>