39,000颗星背后:Google LangExtract 把「从文本里抽东西」做成了正经的工程问题

39,000 颗星背后:Google LangExtract 把「从文本里抽东西」做成了正经的工程问题


做信息抽取的团队,大概率踩过同一个坑:正则表达式一遇到边缘 case 就崩;LLM 输出 JSON 看着很对,但不知道数据具体从原文哪个位置来的,审核的时候根本没法查。

Google 出的 LangExtract(github.com/google/langextract)就是想解决这个问题的。38,873 颗星、Apache 2.0 许可、最新版本 v1.7.0(2026 年 9 月中刚发),它不是又一个大模型,而是一个专门给「带来源的结构化抽取」建的编排层。

它到底在做什么

LangExtract 的核心逻辑很简单:你定义一个 Pydantic schema,给几个 few-shot 示例,然后扔一段文本进去,模型按你的 schema 抽结构化数据——同时告诉你每个字段对应原文哪个字符区间。

这个「字符区间」就是它和普通 LLM API 调用的本质差别。输出里的 char_interval 字段精确到字符级别,如果模型「自由发挥」了一个原文里没有的值,char_interval 就是 None——直接暴露幻觉,而不是让它静悄悄混进结果。

一个最基础的例子:

import langextract as lx

examples = [
    lx.data.ExampleData(
        text="合同签订日期:2023-01-15",
        extractions=[
            lx.data.Extraction(
                extraction_class="date",
                extraction_text="2023-01-15",
            )
        ]
    )
]

extractor = lx.Extractor(examples=examples)
result = lx.extract(
    text_or_documents="本协议自2023-03-20起生效",
    prompt_description="Extract contract dates",
    examples=examples,
)
print(result.extractions[0].char_interval)  # 知道数据在原文哪个位置

为什么值得认真看

这个项目真正解决的是三个真实痛点:

第一,长文档不用自己分块。超过 token 限制的文本,LangExtract 自动 chunk、并行处理(最多 20 个 worker)、多轮提取再融合。官方测试跑过完整版《罗密欧与朱丽叶》(147,843 字符),并行 + 多轮之后召回率能从单轮的 82% 拉到 96%。

第二,输出格式是强制的。Schema 通过 Pydantic 定义,模型跑出来的 JSON 格式永远是你期望的样子,不用再头疼后处理。

第三,内置可视化审查。一行命令生成交互式 HTML,左右分栏:左侧原文高亮,右侧实体列表可搜索、可过滤、可点击定位。医疗、法律、金融场景里,这个「人肉审核」环节省不掉,能在同个界面里点一下就核对来源,价值明显。

实际跑一遍要花多少钱

搜索结果里有人算过一笔账:用 Gemini Flash 处理一份 150k 字符的文档,大约 $0.03;处理 10-K 财务报告(6 类实体、含属性),45 秒出结果。如果是 Ollama 本地跑,API 成本为零,但模型质量要自己承担。

对比几个同类工具的定位差异:

LangExtract Instructor LlamaExtract spaCy NER
字符级来源定位 ✅ 原生 ❌ 无 ✅ via LlamaParse ✅ token 级
Schema 灵活性 Few-shot Pydantic Pydantic 推断 schema 需重训
长文档处理 分块+并行+多轮 token 限制 服务端处理 上下文限制
可视化审查 内置 HTML 无 Web UI 无
本地模型 Ollama 自接 托管服务 自托管
典型场景 医疗/法律/报告 API 响应 RAG 管线 通用 NER

它不适合什么

LangExtract 明确说了三件事不适合:

  • 确定性要求极高的场景:它本质上还是 LLM 调用,没有规则引擎的硬保证。如果你要的是「这条规则匹配就一定输出」,fine-tuned 模型或规则引擎更合适。
  • 需要 OCR 或文档解析的流程:它只处理干净的文本。PDF 和扫描件要先把文字抽出来,可以用 Docling 做这一步,再把结果喂给 LangExtract——两者是互补关系,不是竞争关系。
  • 需要商业 SLA 的生产环境:Google 明确说了这不是官方支持产品,没有服务等级协议,Gemini 模型版本有退役日期要自己跟踪。

社区现状

目前已有:Ollama 集成(v1.0.4)、OpenAI 支持(v1.0.3)、Vertex AI Batch API(v1.0.6),以及社区维护的 TypeScript 移植。v1.6.0(2026 年 7 月)还带来了自定义 Provider 插件系统,可以往里插任何 LLM 提供者。

RadExtract 是一个基于 LangExtract 构建的放射科报告结构化演示,放在 Hugging Face Spaces 上可以免部署直接试。

下一步建议

如果你是数据工程师或 AI 应用开发者,想把非结构化文本变成可查询的数据库,LangExtract 是目前这个赛道里来源追踪做得最完整的开源方案。建议从官方 examples 里的 financial_extraction.py 或 RadExtract demo 跑起,5 分钟能跑出一个可运行的原型,再判断是否值得进生产。

GitHub:https://github.com/google/langextract
PyPI:https://pypi.org/project/langextract
RadExtract Demo:https://huggingface.co/spaces

评论区

0 条评论

登录后可评论。

拾光·开源拾遗 390 阅读