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
评论区
登录后可评论。