https://yennj12.js.org/yennj12_blog_V4/tags/elasticsearch/Recent content in Elasticsearch on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 10 Sep 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ragflow-intro-part1-overview-architecture-zh/Thu, 10 Sep 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ragflow-intro-part1-overview-architecture-zh/大多數人讀 RAG 開源專案的方式，是打開 README，跑 docker compose up，上傳一份 PDF，看到答案出來就說「我懂了」。 真正的答案是：一個生產級 RAG 引擎有 80% 的複雜度不在「呼叫 LLM」那一行，而在資料怎麼被解析、怎麼被切、怎麼被編碼、怎麼被存、怎麼被取回、以及取回之後怎麼證明它沒有胡說。 Demo 只需要 200 行。引擎需要一整套子系統。 這個系列拆解的是後者。 前言：這個系列要做什麼 RAGFlow （InfiniFlow，Apache-2.0，2023-12-12 開源）是目前最受關注的開源 RAG 引擎之一：GitHub 上約 9.0 萬顆星、1.06 萬 fork，官方定位是「a leading open-source RAG engine that fuses cutting-edge RAG with Agent capabilities to create a superior context layer for LLMs」。 它值得逐層讀完，理由不是星星數，而是：它把 RAG 每一個環節都實作成可替換的元件，而且每個選擇背後都有明確的理由。 讀它等於讀一份「RAG 系統設計的參考答案」。 這個系列分成五篇： Part 主題 對應原始碼 Part 1（本篇） 全景架構、資料的兩條路徑、部署形態 docker/、conf/、整體 Part 2 資料進場：DeepDoc 解析與 Chunking 策略 deepdoc/、rag/app/、rag/nlp/ Part 3 Encode 與 Save：向量化、索引 Schema、雙引擎抽象 conf/mapping.https://yennj12.js.org/yennj12_blog_V4/posts/ragflow-intro-part3-embedding-indexing-zh/Thu, 10 Sep 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ragflow-intro-part3-embedding-indexing-zh/大多數人處理 RAG 的儲存，是 collection.add(documents=chunks, embeddings=vecs)，然後就不再想這件事。 真正的答案是：索引的 schema 決定了你三個月後能做什麼查詢；相似度函式決定了你的關鍵字檢索是有效還是裝飾；欄位命名決定了你換 embedding 模型要不要重建整個索引。 這些決定在寫入的那一刻就凍結了。 這篇文章拆的是 RAGFlow 在那一刻做的每一個選擇。 前言 Part 2 結束時，我們手上有一組 chunk：純文字、可能帶版面座標、可能帶人工或 LLM 產生的關鍵字與問句。 本篇處理接下來兩步： chunks ──▶ ① Encode（向量化） ──▶ ② Save（寫進 doc engine + 物件儲存） rag/svr/task_executor.py conf/mapping.json rag/llm/embedding_model.py rag/utils/*_conn.py 這兩步看起來機械，實際上藏了 RAGFlow 最有辨識度的幾個設計。我們從最反直覺的一個開始。 一、Encode：為什麼向量是「檔名 × 0.1 + 內容 × 0.9」 task_executor.py 的 embedding() 函式，核心只有幾行： 1async def embedding(docs, mdl, parser_config=None, callback=None): 2 tts, cnts = [], [] 3 for d in docs: 4 tts.