夜雨聆风
导语
今天聊个法律科技圈正在传的工具——GitHub 上一个叫ContextGem 的开源项目，半年冲到 1800+ Star，专给中小律所和法务做"长合同结构化抽取"。它不聊天、不 RAG，打法相当另类：直接让 LLM 把整份合同读一遍，按你定义的 Schema 把关键条款吐成结构化数据。我们扒了一下源码和官方文档，发现这事比标题更有嚼头。
它到底是啥，不是啥
ContextGem 是独立开发者shcherbak-ai 2025 年 4 月底开源的 Python LLM 框架，Apache-2.0 协议，PyPI 最新 0.25.x。
先把边界划清，免得又被"AI 取代律师"的标题带偏：
❌不是 又一个 LLM 聊天壳子——它不陪你对话
❌不是 普通 RAG 检索引擎——它不把文档切碎存向量库
✅是 一个"长文档 → 结构化字段"的抽取器，专治合同、发票、CV、财报这类"几十页起跳、要按字段摘信息"的场景
官方文档自己说的很直白：
Unlike RAG approaches that often struggle with complex concepts and nuanced insights, ContextGem is betting on LLM long context windows.
翻译过来就是：RAG 搞不定的跨段、跨条款引用，我靠长上下文整篇吞。
为什么不切片，反而是对的
法律文档的坑，做过合同审查的都懂：
跨段引用："违约金按第 3.2 条计算"——你把第 3.2 条切到另一个 chunk 里，检索就断了
上下文截断：NDA 里"本条款不适用于……"那一段，前面半句在 chunk N，后半句在 chunk N+1
异常条款要全局判断："排他范围"是不是被某个附录偷偷放大了——孤立段落看不出来
RAG 在通用 QA 上没问题，但合同审查是要"通读 + 比对 + 溯源"的活，检索召回这一步本身就丢信息。
ContextGem 的解法是：
整篇喂给长上下文模型（GPT-4o / Claude / 本地 Ollama 都行，通过 LiteLLM 接）
用 Pydantic 定义抽取字段——比如
GoverningLaw(StringConcept)、TerminationNotice(NumericalConcept)、Indemnification(JsonObjectConcept)Aspect / Concept 两级结构：Aspect 是"主题层"（付款条款、违约责任、管辖法院），Concept 是"字段层"（具体值），支持嵌套子 Aspect
SaT 神经分割做引用映射——抽出来的每个值，自动标回原文段落/句子级位置，附"抽取理由"
💡 关键点：Pydantic 不只是定义字段，它还管JSON Schema 生成 + 抽取结果校验。LLM 吐出来的 JSON 会走
fastjsonschema二次验，非法值直接拦掉。这是很多自己拼 prompt 的项目没做的。
速度到底多少，诚实说
原稿那个"80 页 NDA 8 分钟"——我们复核一下口径：
官方没给标准 benchmark，但按 80 页英文合同 ~2.5 万 token 估算，GPT-4o 一次过 + 并发开关
use_concurrency=True，8 分钟这个量级是合理的（含多次 aspect 调用，不是单次 completion）中文合同需要微调提示词（框架本身 prompt 是英文原生），召回/准确率那批 91.3%/87.6%全网只有原稿在传，没独立信源，建议当"开发者 demo 级数据"看，不要当生产环境承诺
"伦敦 12 人律所 240→620 份"那批客户案例，GitHub 没公开客户名单，属于开发者侧自述，未第三方核验
更诚实的口径是：ContextGem 把"初稿抽取"从几小时压到几分钟，但人工复核这道关撤不掉——LLM 对"异常条款""隐含冲突"的判断目前还到不了 100%，资深律师的谈判/出庭价值反而被放大。这和原稿结论方向一致，但把"零漏审"这种绝对词收回来了。
谁真的适合用
按官方示例和同类项目对标，几类人值得试：
中小律所：上不起 Harvey（那玩意儿 enterprise 报价）、也不想按小时给助理付"条款摘抄费"的，ContextGem + 自己 OpenAI Key，80 页合同跑一次成本几块钱
跨境电商 / SaaS 法务：中英双语合同量大、条款模板相对固定，把 Aspect 定义好以后可以复用
乙方咨询 / 审计：财报、发票、CV 批量过——框架本身不绑法律场景，Invoice / CV / Report 都给示例了
不合适的场景也得说一句：超高合规要求的红圈所并购尽调（那个容错率是 0，AI 目前扛不住）、纯手写非标合同（模板定义成本 > 收益）。
