跨国深谈← 返回←每天100万份协议：DocuSign 携手 NVIDIA 把合同表格变成可用数据

每天100万份协议：DocuSign 携手 NVIDIA 把合同表格变成可用数据

关联

人物 Hiral Shah · Sean Sodha

公司 DocuSign · NVIDIA

概念 Nemotron · 表格提取 · 智能体 · OCR · 量化 · VLM · 开源模型

这一集聊的是一个几乎所有企业都被困住的问题：协议数据。每天签的合同、订单表、价格表里埋着大量关键信息，但它们锁在 PDF 这类非结构化格式里，没人能查、能用。说这件事的两个人，一位是 DocuSign 的产品高级总监 Haral,另一位是 NVIDIA 的产品经理 Sean,他们来讲两家公司怎么合作解决这个问题。

先说规模有多大。DocuSign 有 190 万付费客户、10 亿用户，每天处理 100 万份协议。

他们和德勤做过一项研究：有 2 万亿美元锁在协议谈判达成的价值里，没有人去利用、没有人回头把这些数据挖出来。为什么挖不出来？

因为靠人工阅读和审查、系统彼此割裂、流程大量靠手工。法务、采购、销售团队经常花几个小时翻文档，就为了定位一个基本信息。

难点：表格是传统工具的死穴

企业合同里最值钱的东西——价格层级、SKU、SLA、费率卡——几乎全是表格。而传统文档提取工具和通用大模型在这里完全失败，他们试过了。原因是这些工具逐行读取文本，把表格里的概念结构全破坏了：合并单元格、没有清晰边界的内容都处理不了。

还有一个容易被忽略的复杂性：协议不是平面的，而是分层的——一份协议管辖另一份协议，你回答一个问题往往需要综合多份文档。比如问「我们和 Claude 签的合同里 total tokens 是多少？」,没人答得上来，因为答案以不同形式埋在合同里。

解决方案：一个小而专的提取模型

这就是 NVIDIA Nemotron Retriever 计划登场的地方。Nemotron 是 NVIDIA 构建世界级开源模型的项目，连数据集、量化、蒸馏、剪枝方法和配套蓝图全部开源发布。其下的 Nemotron Parse 模型专为表格提取打造——这件事的排列组合极其庞大：嵌套表格、合并单元格、合并列、合并行，是一个非常棘手的问题。

这个模型的关键取舍在于「小」：它是 VLM(视觉语言模型)，但参数量远小于通常数十亿参数的重型模型。它是一个单次推理的一体化模型：输入一份文档，直接输出语义版面、文本、阅读顺序、保留结构的表格，不再需要 YOLOX 那类分别做表格或页面元素提取的小模型拼装。

可以用 NVIDIA NIM 或 vLLM(一种高性能推理服务框架)部署。注意它的定位：它不是生成器，说到底是一个提取器。

演示：几秒钟把合同变成数据

在 Agreement Manager(一个组织签过的所有协议的中央存储库)里上传一份订单表，几秒钟之内就提取出一整套丰富的元数据：关键条款、商业细节自动结构化并高亮，可以点击直接跳到原文位置。NVIDIA 模型负责的部分是定价数据：把复杂表格分解成结构化的订单细节，可以下载成 CSV 给财务、采购团队用，也可以通过 API 获取。他们的客户从有 1000 份协议到有几百万份协议的都有。

学到的三件事

第一，为你要做的具体工作构建专用模型，是他们能把东西更快推向市场的关键。第二，模型效率：更小的模型意味着更低延迟、更低成本，才能撑住他们所说的百万级规模。

第三，速度：对比很多其他开源模型，Nemotron 每秒能提取的表格数量快了 20 倍。结论：对企业来说，更小的专用模型才是正确的路。

坑与边界：OCR 还要不要、性能怎么榨

观众问了一个尖锐的问题：OCR 一直是整个流程的刺，为什么不干脆从一开始就用智能体方式？Sean 的回答是把计算花在刀刃上：如果你有 PB 级文档要让它们日后可查询，就把大量计算花在前期 OCR 上，之后就不操心了；而如果只是上传一份合同做问答，那是极低延迟的用例——高吞吐和低延迟两类场景，批大小、并发度、处理技术都该不一样。Haral 补充：他们是混合架构，表格走版面理解加提取，其他字段、元数据、条款仍然走 OCR,流水线分两条路径。

性能方面，模型目前跑在 FP16,接下来有通往 FP8 和 FP4 的量化(用更低的数字精度压缩模型以提速)路径。Sean 还提到几个优化方向：多 token 生成(一次生成多个 token 而不是一个)、VLM 编码器-解码器架构的进一步优化——现在这个模型一次只生成一个 token。

不过当下的重点是准确性：先确认是否真的在为系统增加价值，再把帕累托曲线往性能端推。下一步的合作计划，是从「从页面里尽可能多提取信息」扩展到「先找到那个页面」，再走向生产规模的智能体。

本集带走

• 合同数据的最大痛点是表格：定价、SLA、费率卡都在表格里，逐行读取的传统工具和通用大模型处理不了合并单元格和嵌套结构，需要保版面的专用模型。
• 专用小模型优于通用大模型：约 9 亿参数的单次推理提取模型，比通用方案快 20 倍、成本低、延迟低，才能撑住每天百万份协议的规模。
• 计算花在哪取决于用例：海量文档要日后可查询就把算力砸在前期处理；单份合同的即时问答则是低延迟场景——批大小、并发、技术选型全不同。
• 量化和多 token 生成是性能余量：FP16 起步，量化到 FP8/FP4、多 token 生成都是后续提速路径；但顺序应是先把准确性做对，再推性能。

【背景】Coupa 是一款企业采购与支出管理软件，文中采购团队想把提取出的价格表导入 Coupa 以确保付款对账。

这些钱锁在协议谈判达成的价值里，没有人加以利用，没有人回头去把这些数据挖出来。
Captured in this agreement negotiated value that no one capitalizes, no one goes back and gets that data back.
—— Hiral Shah · [02:19]

它不是生成器。说到底它更像一个提取器。
It’s not a generator. It’s more of an extractor at the end of the day.
—— Sean Sodha · [07:54]

为你想要做的工作构建专用模型，是我们思考方式中很大很大的一部分，这也正是我们能够加速、更快地把东西推向市场的地方。
So a purpose-built model for the job you’re trying to do is a big, big part of how we’ve been thinking about, and that’s kind of where we’ve been able to accelerate, bring things to market much faster.
—— Hiral Shah · [11:36]