LangExtract 架構分析

发布于 2026-02-15 23:57:44（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 2611 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）

originalwex7ce EI V1ajero 2026年2月15日 23:58 中国台海 花了點時問把Google開源的LangExtract代磷麟了一遍。就實話,这束西跟 现在市面上大火的LangChain或者LlamaIndex 思路很不一様。它没有整那些 花胡哨的Agent概念,就是踏踏實實解决一個間题:怎百真的合同、财報 裡,把数據招出来,而且遗能精確告我這数據在哪一行。下面是我整理的一些架横 思考和源碼筆記,適合大家做類似系统設計時参考。

APtonny trmrg

它的架楷本質:一個“带記性的Map-Reduce" 看代碼的時候,覺得这不就是個RAG喝?後来發现不封。RAG是“搜->端 <<·<< LangExtract 其震是一個Stateful Map-Reduce(带狀懋的 Map-Reduce)系 统。它不做向量检索(因爲检索意味著會漏束西),而是暴力描全文。这礁起来很 笨,但對於法律合約塞查运種場景,Recal1(召回率)就是命,漏掉一条条款可能就 是百剪的损失,所以全量操描反而是最優解。 畫了個草图来理解它的数據流: Map 随段(带狀感! 切刀: Chunkiterator 输入:一本300真的 PDF 把上一塊的尾巴黏束 切一 記憶缓存: ContextAwarePromptBuilder

Process 降段(兹行) 综程池

LLM 推理

Reduce陷段(硬核處理) 解析器:FormatHandler 找坐檬:WordAligner

生成报表:Visualization 结化数據+字符级坐標

關於“上下文注入”的一點细 在chunking-py和prompting-py理,我看到了一很單但很實用的設計,事門用 来解决“指代消解”間题。 同”。如果直接切開,LLM看到第二页的“他”,根本不知道是旅。 LangExtract的做法是,在處理第二块的時候,强制把第一瑰的最後506個字符塞 到Prompt 的最前面(棵記為[Previouscontext])。這個“默注入”楼 制,原本獨立的Chunk之開有了聊絮。 履存状息 PromstEullder 笔1线(文本:“集三是洁人....) 8人 Churk.1 适是第一境·正常提原 提胞结果:(Nene|张三] 除前把 Ohurk 1 的尾巨存起案 第2埃(文本:“能强了合周.) 提人 Churk 2 .张三是活人”

[三] 众号 播存状息 文楼育 Promstullder 这代磅寫得挺克制,没有引入向量数擦库,就用一個内存字典解决,工程性俱比高。 工廠模式:怎磨侵雅地適配一堆LLM? 它的factory·Py得很標弹,把 Google 自家的 Gemini、OpenAI 還有本地的 0lLama封装得挺好。运裡有個投計很有橙:的定侵於配置。 它富自勤去滞跟境量。你的Docker径只要有GEMINI_API_KEY或者 OPENAI_API_KEY代确锂什磨都不用配,直接create_model(“gemini3")就行 了。 期用 create_model

措環境蔓量 据猫境费量 操OPENAI_KEY 绿现GEMNI_KEY 循 Gemini 配置 准餐 OpenAI 配置

匹配模型ID

度例 GeminiProvider 宽例化 OpenAIProvider 以後如果我們自己要接個内部的Llama 3,照著寫因Provider 继承 BaseLanguageModel就行,展性問题。 怎磨跟“人工智障”门智门勇? 做遇LLM開發的都知道,模型输出格式是最頭疼的。你要JSON,它給你 Markdown;你要文本,它给你加段“Here is your answer”。特别是那個 DeepSeek-R1,翰出前退非要加一段標,把JSON解析器搞扇清, LangExtract不相信模型,它在FormatHandler提察了個状懋機来做“防性编 程”。

清洗脑段 原始输出 針對推理模型 解析段 乾掉Think標筑 去掉Markdown NOS辉 JSON排了?越YAML 携救隋段 试试YAML Nice! 微底排了 成功 用正则硬握 Key-Values 宽容模式 能救多少救多少

代碼狸那個_THINK_TAG_RE正察得挺靈性,直接把推理遇程切掉,無缝適配了現在 最新的推理模型。這就是工程经啊。 核心算法:怎度在原文理找到那個? 這是我覺得整個项目最硬核的地方:WordAligner。提取出“果公司”很容易, 但在50真的文楼理,它具體出现在第真、第行?这叫Grounding(溯源)。 LangExtract用了個"快慢路径"的策略,既保證速度又保證精度。 快路径(FastPath):直接字符串匹配。如果LLM很乖,製粘貼原文,那時 間就找到了。 取了“Apple"),这時候就要上difflib做模期匹配。 但difflib很慢,怎度游?它加了個预剪枝(Pre-pruning): Stage 1: 货径

就调 图口

折算 省了大E CFU 黄黑

组分量高的 這裡没有用Embedding做語義匹配是對的。信息提取要的是字面精確,不是語羲相 似。"iPhone13”和“iPhone14”向量很像,但提取錯了就完蛋了。 玩LangExtract的個小建 看了這多,給想用這個库的兄弟們個實建: 能用geminischema就一定要用。Schema 定羲好了, 别省那點,用Schema: 别省那點,用Schema:能用gemini_schema就一定要用。Schema定義好了, 模型輸出不准,而且話少,省Token就是省。 Buffer設大點:現在的模型ContextWindow都很大(Gemini1.5Pro都 有1M-2M了)。max_char_buffer不要用默的1000,直接幹到50,000甚至更 多。切分越少,語義越完整,提取效果越好。 多輪提取是個好東西:如果你的数據很密集(比如财報裡的表格數據),開雨輪提取 (extraction_passes=2)。第一輪提取大頭,第二輪查漏補缺,親測召回率能提 20%左右。 可視化很有用:它自带的那個visualization模塊生成的HTML很直觀,左原文 右結果,還带高亮跳轉。做演示或者人工複核的時候非常實用。

總結:Google這人寫代碼還是挺講究的。LangExtract没有過度封装,每個 模瑰(Chunking,Prompting,ALignment)都拆得很清楚。如果要做垂直领域 的長文檔提取,别自己頭造輪子了,拿這個改改,對比自己寫的穗。

原始排版图