惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

N
News and Events Feed by Topic
S
Security @ Cisco Blogs
S
Secure Thoughts
Attack and Defense Labs
Attack and Defense Labs
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Hacker News - Newest:
Hacker News - Newest: "LLM"
Recent Commits to openclaw:main
Recent Commits to openclaw:main
H
Hacker News: Front Page
博客园 - 叶小钗
H
Heimdal Security Blog
Microsoft Security Blog
Microsoft Security Blog
Forbes - Security
Forbes - Security
AI
AI
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
T
Troy Hunt's Blog
罗磊的独立博客
Application and Cybersecurity Blog
Application and Cybersecurity Blog
爱范儿
爱范儿
GbyAI
GbyAI
The Last Watchdog
The Last Watchdog
TaoSecurity Blog
TaoSecurity Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
D
DataBreaches.Net
Recent Announcements
Recent Announcements
Schneier on Security
Schneier on Security
C
Cisco Blogs
美团技术团队
D
Docker
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
WordPress大学
WordPress大学
月光博客
月光博客
雷峰网
雷峰网
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
H
Hackread – Cybersecurity News, Data Breaches, AI and More
A
Arctic Wolf
B
Blog RSS Feed
Cisco Talos Blog
Cisco Talos Blog
C
Cybersecurity and Infrastructure Security Agency CISA
V
Vulnerabilities – Threatpost
V2EX - 技术
V2EX - 技术
Y
Y Combinator Blog
N
News and Events Feed by Topic
www.infosecurity-magazine.com
www.infosecurity-magazine.com
W
WeLiveSecurity
Security Archives - TechRepublic
Security Archives - TechRepublic
G
GRAHAM CLULEY
Jina AI
Jina AI
Hugging Face - Blog
Hugging Face - Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
The Hacker News
The Hacker News

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
5人团队,1700万融资,现金流为正,继Reducto获Benchmark 2450万投资后,文档处理赛道又迎来重量级玩家
深思圈 · 2025-07-01 · via 人人都是产品经理

在数字化转型浪潮中,文档处理一直是企业面临的痛点。尽管技术不断进步,但如何高效、准确地处理海量非结构化文档,依然是许多企业难以攻克的难题。本文将介绍一家名为 Extend 的初创公司,他们在文档处理领域取得了令人瞩目的成就。

你有没有想过,为什么在这个云计算和AI横行的时代,PDF文档处理依然是企业最大的痛点之一?

想象一下这样的场景:一份包含数百页的贷款申请文档躺在银行系统里,等待人工审核,而申请人只能苦苦等待几天甚至几周才能知道结果。

与此同时,医院里的医疗记录还在用打印机输出,然后手工传递给下一个医生。这些看似平常的场景,实际上暴露了现代企业面临的一个巨大问题:80%的企业数据被困在非结构化文档中,无法被有效利用。

当我深入研究这个市场时,发现了一个有趣的现象:就在我之前分析过Reducto这家获得Benchmark 2450万美元投资的文档处理公司后不久,另一家名为Extend的公司也在这个赛道取得了突破性进展。

这家专注于文档处理的AI初创公司刚刚完成了1700万美元的种子轮和A轮融资,由Innovation Endeavors领投,Y Combinator、Homebrew、Character等知名投资机构参与,还包括前Adobe首席战略官Scott Belsky和Vercel CEO Guillermo Rauch等重量级天使投资人。

更让我惊讶的是,他们在团队规模只有5人、融资不到200万美元的情况下,就已经实现了超过融资总额的年度经常性收入,并且现金流为正。这样的成绩让我不得不深入了解他们到底在做什么,以及与市场上其他玩家相比,Extend的独特之处在哪里。

从他们的融资情况来看,这轮1700万美元的种子轮和A轮由Innovation Endeavors领投,Y Combinator、Homebrew、Character等现有投资者参与其中。

这些投资者的参与本身就说明了市场对文档处理AI技术的高度认可。而让我更感兴趣的是,Extend的创始团队并非初出茅庐的新人。

创始人Kushal Byatnal和Rahul Bhattacharya此前曾共同创立过Slintel,那是一个销售智能平台,曾获得2500万美元融资,拥有超过300家客户和100多名员工,最终在2021年被6sense收购。

加上首席AI官Anirudh Badam从微软西雅图总部带来的十多年AI/ML专业知识,这样的创业和技术经验让人对他们的新项目充满信心。

文档处理为什么这么难

在我看来,文档处理问题之所以一直没有得到很好的解决,主要是因为大多数人低估了它的复杂性。

很多人以为只要有了OCR技术,就能轻松从PDF中提取数据,但现实远比想象复杂。

我曾经亲身经历过这种痛苦:在一个项目中,我们需要处理大量的发票和收据,起初以为几个API调用就能搞定,结果发现现实中的文档千奇百怪——有的倒着扫描、有的模糊不清、有的被咖啡渍覆盖、有的还有手写的小费金额。

对于那些需要99%以上准确率的关键业务场景,比如金融机构处理贷款申请或医疗机构处理患者记录,即使是微小的错误都可能导致严重后果。

家庭无法按时搬进新家,因为运营团队需要审查100多页的PDF贷款申请;患者在医疗记录被打印出来并从一个提供者传递到另一个提供者时无法得到所需的护理;小企业因为发票详细信息需要手动审查和输入而无法按时收到付款。

Extend的创始人Kushal Byatnal在Brex的经历完美说明了这个问题的本质。当时他们想为用户创造一个神奇的体验,通过解析收据自动匹配费用报销。

听起来很简单对吧?

但现实是,用户上传的收据有无数种边缘情况需要考虑。

除了数百万种不同的商家格式,收据还可能颠倒、模糊、皱巴巴、被咖啡弄脏、有手写的小费金额等等。

他们测试了市场上几乎所有的解决方案,从传统OCR供应商到专门的机器学习方案,虽然在少数几个例子上看起来有希望,但团队有足够的经验知道,虽然演示很容易构建并且能够快速激发灵感,但真正的问题在生产规模中等待着他们。

尽管他们尽最大努力,团队的多名成员费力地标注了数百个复杂示例和他们在生产中预期的边缘情况,但他们从未达到可以向客户展示的准确性水平。

作为一家雄心勃勃的公司,从头开始构建现代软件(他们甚至自主构建了整个卡处理基础设施!),他们意识到需要对最终用户体验进行完全控制和灵活性。

他们的许多要求,如低延迟、多语言支持和自定义数据字段,根本无法通过现成解决方案的”一刀切”方法满足。

最终,他们不得不自己构建大部分功能,这迅速成为他们最复杂的工程项目之一,花费了数月的实施、迭代和维护时间。

他们使用了各种技巧,结合机器学习模型与定制代码,甚至建立了内部的正则表达式规则和启发式评分系统来构建必要的基础数据架构。只有在适当的回归测试和性能监控到位后,他们才能开始在此基础上构建用户体验。

虽然最终他们确实发布了那个设想中的神奇功能,并且多年来一直是客户给Brex打10/10 NPS评分的主要原因之一,但六年后,他们必须编写和维护的代码量仍然让Kushal心有余悸。

这种痛苦的经历让他们添加新模型以跟上不断增长的数据流,在每次出现边缘情况时调整启发式方法,并在工程师根本没有带宽时取消新功能请求的优先级。

这个例子完美地揭示了文档处理的真正挑战:虽然transformer模型大大提高了文档处理可能性的下限,但构建生产级文档工作流仍然需要对”文档处理基础设施”进行巨大的投资。

如果你与那些有这些关键任务、产品内文档用例的公司交谈,你会听到一个一致的故事:他们为这个问题分配了5-10名工程师的团队,工作了一年以上,并围绕VLM和OCR模型构建了大量工具。

这包括为内部主题专家提供的标注工具、处理奇怪文档边缘情况的人工干预工作流、从用户行为中学习和适应的强化学习和微调工作流、确保达到99%以上准确率的评估工作流、协调复杂有向无环图的工作流编排,将不同模型结合在一起,包括光学字符识别、文档分割、文档提取、文档分类等等,以及处理文档中无数边缘情况的逻辑——如手写、签名、删除线和庞大的表格。

让我深有感触的是,基础模型实际上暴露了问题而不是解决了问题。它们给了团队”像编程API一样编程文档”的体验,直到他们最终意识到模型层只是冰山一角,高质量的文档处理实际上是一个系统工程问题。

实际上,我发现对于许多公司——包括一些知名的投资组合公司——文档处理是其产品路线图和收入增长目标的最大瓶颈。这正是为什么Extend这样的解决方案如此有价值的原因。

Extend的创新之处

我深入研究Extend后发现,他们的聪明之处在于认识到文档处理实际上是一个系统工程问题,而不仅仅是一个模型问题。

原始OCR或基础模型并不能完全解决问题,你需要的是一个统一的基础设施和工具集,能够让尖端团队在一个地方处理所有混乱的文档。

Extend不仅仅是另一个文档API,它是一个完整的端到端平台,建立在尖端的大语言模型基础上,结合了可靠处理复杂文档所需的所有其他开发者原语。

让我印象深刻的是Extend处理这个问题的全栈方法。

他们提供了一个先进的解析引擎来处理混乱的手写字体和表格,提供确保可靠性的评估工具,以及部署生产就绪管道的编排功能。

这意味着团队避免了数月的研发来解决边缘情况和准确性差距,可以快速从原始PDF转换为结构化、验证过的、生产就绪的数据——在从干净文档到降级扫描的所有内容上都能达到95%以上的准确率。

更重要的是,Extend的产品设计理念体现了对企业实际需求的深刻理解。他们不试图成为”黑盒解决方案”或以任何方式限制软件工程师。

实际上,Extend提供的很多价值在于允许软件工程师尝试、测试和评估不同的AI模型或处理策略。

Extend加速和增强你的内部构建,而不是限制它,这对于服务最复杂的公司和团队来说是绝对必须的。

从他们的客户反馈来看,这种方法确实解决了实际问题。

Brex的CEO Pedro Franceschi表示:”Extend在我们测试的每个解决方案中表现最佳——包括其他供应商、开源甚至基础模型。它现在为我们30,000个客户的关键文档工作流提供支持,帮助我们构建最智能和最现代的金融平台。”这种反馈在我看来代表了客户对技术解决方案的最高认可:不仅解决了问题,还成为了竞争优势。

我特别欣赏Extend在产品设计上的两个关键决策。

第一,他们专注于为构建基于文档的工作流的复杂软件团队服务,而不是后台劳动自动化或RPA。想想Brex的账单支付或Flatiron Health的电子健康记录数据摄取。这些工作流如果做对了价值极高,但它们也是最难做对的。

第二,Extend允许软件工程师尝试、测试和评估不同的AI模型或处理策略,这种灵活性对于服务最复杂的公司和团队来说至关重要。正如Innovation Endeavors的Davis Treybig所说:”Extend用全栈方法重新构想文档智能,将尖端LLM与可靠处理复杂文档所需的所有其他开发者原语相结合。产品如此强大,以至于许多Extend的客户不仅能够自动化现有工作流,还能推出推动竞争差异化的全新功能。”

我特别注意到Extend在工程和产品团队授权方面的独特之处。

他们推出的自服务版本平台让团队能够立即开始使用,这对于那些想要快速验证用例或在真实示例上验证准确性的企业来说非常有价值。沙盒模式提供了一种快速、无摩擦的方式来体验Extend的全部功能,如果需要帮助,团队可以在产品中快速发送消息寻求支持。

这种产品体验设计体现了他们对开发者友好性的重视,这与许多传统文档处理供应商形成了鲜明对比。

Extend vs Reducto:文档处理赛道的两种路径

有趣的是,当我对比Extend和我之前深度分析过的Reducto时,发现了两家公司在解决同一问题上的不同策略。

这种对比很有启发性,展现了文档处理市场的复杂性和多样化需求。

Reducto由MIT校友创立,获得了Benchmark领投的2450万美元A轮融资,他们的方法更侧重于打造”魔法般”的解析精度,强调单一传递就能达到极高的准确率。

而Extend则采用了更加全栈和系统化的方法,专注于为开发者提供完整的文档处理云基础设施。

从技术路径上看,Reducto的Agent OCR框架采用多次传递方法,通过基于代理的系统自动审查输出,捕捉错误并进行修正,类似于人在循环中的过程。

这种方法在处理复杂文档时能实现近乎完美的解析准确性。

而Extend的方法更注重工作流编排和端到端的生产就绪解决方案,他们不仅解决解析问题,还提供了分类、分割、验证、人工审核等完整的工具链。

从客户群体来看,两家公司都服务于高端企业客户,但侧重点有所不同。

Reducto的客户包括Airtable、Scale AI和多家FAANG企业,他们更看重的是超高精度的文档解析能力。而Extend的客户如Brex、Square、Checkr、Flatiron Health等,更需要的是能够快速部署到生产环境的完整解决方案。

这反映了市场上两种不同的需求:一种是对精度要求极高的专业应用,另一种是需要快速集成和部署的企业级应用。

在商业模式上,Reducto专注于按页计费的API服务,并且为简单页面提供成本优化,在零准确性损失的情况下将处理简单页面的成本降低了一半。而Extend则提供了更多样化的服务模式,包括自服务平台、定制化配置生成、以及完整的人工干预工作流。

这种差异体现了两家公司对市场定位的不同理解:Reducto更像是文档处理的”高精度引擎”,而Extend更像是”文档处理的完整操作系统”。

我认为这两种方法都有其价值,也反映了文档处理市场的成熟度。对于那些已有技术团队、主要需要解决准确性问题的企业,Reducto的高精度解析可能是更好的选择。而对于那些希望快速构建端到端文档处理能力、减少工程投入的企业,Extend的全栈方案更有吸引力。从投资者的角度看,Benchmark押注Reducto的精度优势,而Innovation Endeavors投资Extend的平台化能力,都体现了对文档处理这个巨大市场不同发展路径的认可。

AI时代的文档处理新范式

我认为我们正处在文档处理领域的一个转折点。过去几年中,大语言模型的进步终于在这个领域产生了真正的影响。

我们现在生活在这样一个世界里:你可以直接调用OpenAI API,对相当复杂的文档进行非常复杂的分类和提取。这些改进如此显著,以至于许多人现在认为文档处理已经成为一种商品。

但仔细观察后,事情实际上并不那么简单。

如果你只是在构建文档搜索或某种基于RAG的文档系统,你可能不需要比基础模型提供的更多功能,因为这些是80-90%准确率通常就足够的用例。

然而,对于许多最有价值的文档用例来说,这种准确率水平是不够的。

想象一下,你正在向金融科技服务上传工资单,该服务使用提取的数据来批准或拒绝你的贷款申请——在这种情况下,准确性和可靠性真的很重要。

错误的代价很高,但能够自动化这种工作流的价值是巨大的,而不是必须等待人工审核并要求用户等待24-48小时才能得到答案。LLM可以让你在这里起步,但它们无法单独让你达到所需的可靠性。

换句话说,虽然transformer模型大大提高了文档处理可能性的下限,但构建生产级文档工作流仍然需要对”文档处理基础设施”进行巨大投资。

这就是为什么Extend的方法如此有价值。

他们认识到,基础模型实际上暴露了问题而不是解决了问题。它们给了团队”像编程API一样编程文档”的体验,直到他们最终意识到模型层只是冰山一角,高质量的文档处理实际上是一个系统工程问题。正如Extend在其自动配置生成功能中展示的那样,文档处理中最大的瓶颈之一是团队花费在调整架构、制作提示和调试边缘情况以提高准确性上的手动时间。

只需上传几个样本文档,Extend就会生成一个针对文档结构优化的定制架构。

很快,Extend将把这种体验与评估集集成,并部署一个在后台持续运行优化循环的agent,这样即使在你睡觉时,你的准确率也会提高。

从Extend推出的新功能来看,他们正在朝着更智能、更自主、更具代理性的方向发展——持续优化文档流的准确性、速度和可靠性。他们的北极星很简单:消除阻碍团队与其非结构化数据之间的每一个瓶颈,这样他们就可以专注于使其业务独特的东西(而不是与PDF格斗)。

世界已经有了用于存储、计算和协作的云平台,但直到现在,还没有人构建过真正的文档处理云——一个专门构建的全栈系统,用于处理规模化现实世界文档的复杂性、混乱性和细微差别。

想想这种技术对不同行业的影响。

  • 在房地产行业,Extend正在帮助企业让家庭更快地搬进新家,通过fleet agent自动化所有50个州的房地产交易。
  • 在金融科技领域,它们使客户能够通过嵌入式agent实时解析金融文档,更快地支付和收款。
  • 在人力资源和薪资平台中,它们通过验证教育和就业文档的agent,让员工能够更快地入职和获得工作批准。
  • 在采购平台中,它们通过agent摄取销售文档来浮现数据洞察,在竞争中领先。
  • 在医疗保健领域,它们通过由专业护士训练的agent来浮现医疗洞察,推动更好的患者结果。

这些用例显示了文档处理技术的广泛适用性和巨大潜力。

我特别感兴趣的是Extend的工作流程和人工干预功能,这体现了他们对生产环境复杂性的深刻理解。

在实际的生产环境中,100%的准确率并不能保证。模糊的视觉效果、模糊的数据和模型错误可能导致错误的输出——以及严重的下游后果。

Extend包含内置的人工干预工具来捕获和纠正这些问题。

你可以在任何步骤配置审查触发器:

  • 置信度阈值(比如如果total_amount < 0.95置信度就标记)
  • 验证失败(比如行项目总计不相加)、外部系统检查(比如在你的数据库中找不到客户ID)
  • 意外文档类型(比如客户上传了无效的文档类型)。

被标记的文档会被路由到Extend的内置审查UI,团队成员可以编辑任何提取的值、重新分类文档、批准或拒绝运行、将更正反馈到评估集中。

这不仅仅是一个安全网——它是一个紧密的反馈循环,随着时间的推移改进你的模型。

这种从人工审查到完全自动化的进化路径特别有意思,展现了AI系统逐步成熟的过程。

以HomeLight为例,他们最初几乎审查每个文档。但在一个月的近乎完美的准确率和零更正后,他们完全移除了人工干预。

这表明,随着模型和配置的改进,审查需求会急剧下降,最终达到完全自动化的状态。

当启动关键任务用例时,团队启用人工审查来捕获早期问题并加速迭代。

随着时间的推移,随着模型和配置的改进,审查需求急剧下降。

这种渐进式的自动化方法比一开始就追求完全自动化更加务实和可靠。

文档处理云的技术深度

深入了解Extend的技术架构后,我发现他们的”文档处理云”概念远比表面看起来复杂。

他们构建的不仅仅是一个API,而是一个完整的生态系统,包括:

  • VLM解析引擎来处理复杂的边缘情况——跨图像、表格、手写、签名等等;
  • LLM上下文管理技术,如语义分块或表格标题延续;
  • 数据标记和评估工具,用于测量性能并改进它;
  • 编排分类、分割和提取以更好地实现准确性的管道;
  • 为其领域专家提供的标注工具;
  • 强化学习和反馈循环,以更多数据改进系统;
  • 以及人工干预工具来标记和升级低置信度边缘情况。

让我印象深刻的是Extend团队的技术背景和经验。

首席AI官Anirudh Badam从微软西雅图总部带来了十多年的AI/ML专业知识,而创始AI工程师Vijay Sagar在谷歌硅谷办公室度过了十年时间,开发机器学习模型。这种深厚的技术背景让他们能够构建真正的全栈解决方案,而不是简单地封装现有的API。

正如团队成员的背景所展示的,Ishaan曾短暂保持蒙眼魔方的世界纪录,尽管是自学成才的软件工程师,却是顶级竞技程序员。

Gus创建了世界上最大的表格数据基准集之一,并且是AWS SageMaker的创始工程师之一。

这些技术深度使得Extend能够解决其他公司无法解决的复杂问题。

从工程角度看,Extend解决的问题本质上是一个数据和系统工程问题,而原始OCR或基础模型并不能完全解决这个问题。

就像Kushal Byatnal所说:”OCR已死。问题不再是’我们能从PDF中提取文本吗?’这是基本要求。

相反,问题变成了:’我们如何有效地教授具有博士级智能的AI模型我们文档、业务和工作流程的复杂性,使它们能够推动业务影响?'”这种对问题本质的深刻理解,让Extend能够提供真正解决根本问题的解决方案。

我特别注意到Extend在处理文档复杂性方面的创新。

文档是复杂的、多样的,充满歧义。给团队提供正确的工具集并赋能非技术领域专家与工程师一起工作,是如何快速推动影响的方法,而不是花费数月迭代和处理边缘情况。

AI系统是不确定的,可能以意想不到的方式失败。适当的防护措施、可解释性和人工监督对于自信地部署到生产环境是必要的。

数据复杂性,由客户需求和不断增长的数据流驱动,只会随着时间的推移而增加。持续学习和适应的自我改进系统是跟上步伐的唯一方法。

在自动化配置生成方面,Extend展现了对用户痛点的深刻理解。

文档处理中最大的瓶颈之一是团队花费在调整架构、制作提示和调试边缘情况以提高准确性上的手动时间。

他们发布了自动配置生成的测试版来减少这种负担。只需上传几个样本文档,Extend就会生成一个针对文档结构优化的定制架构。

很快,Extend将把这种体验与评估集集成,并部署一个在后台持续运行优化循环的agent,这样即使在你睡觉时,你的准确率也会提高。这种持续优化的理念体现了AI时代软件应该具备的自我进化能力。

企业数字化转型的催化剂

在我看来,Extend代表的不仅仅是文档处理技术的进步,更是企业数字化转型的一个重要里程碑。被困在文档中的非结构化数据是未开发数据的最后一个重大前沿——也是最痛苦的一个。

Extend的使命就是让这些数据变得可访问、准确和可操作。

当企业能够有效地处理这些数据时,它将释放巨大的价值。正如他们所说,他们的使命很简单:消除阻碍团队与其非结构化数据之间的每一个瓶颈,这样他们就可以专注于使其业务独特的东西(而不是与PDF格斗)。

从商业角度来看,Extend的成功也说明了一个重要趋势:最好的基础设施公司不仅解决工程问题,还使他们的客户能够提供他们原本无法构建的新颖产品体验。

正如Innovation Endeavors的合伙人Davis Treybig所说:”产品如此强大,以至于许多Extend的客户不仅能够自动化现有工作流,还能推出推动竞争差异化的全新功能。”这种反馈在我看来代表了对基础设施公司的最高认可:不仅解决了问题,还创造了新的可能性。

值得注意的是,Extend在非常精简的团队规模下实现了惊人的商业成绩。他们快速达到了数百万美元的年度经常性收入,超过了种子轮的总融资金额,同时还实现了现金流正增长。

在与Zillow、Flatiron Health、Brex、Opendoor、Square等客户合作的过程中,所有这些都是在团队规模直到最近还只有约5人、融资不到200万美元的情况下实现的。

实际上,当他们进行A轮融资时,Extend的ARR实际上超过了融资金额!这种效率体现了他们对产品市场契合度的精准把握和技术解决方案的有效性。

从客户反馈来看,Extend确实解决了实际的业务痛点。

他们的客户包括Brex、Square、Checkr、Flatiron Health和多家财富500强公司——这些团队依靠Extend的平台精确可靠地处理数百万份文档。正如我之前提到的一些客户反馈所显示的,他们收到的关于Extend的反馈是他们在A轮公司中收到的最好的反馈之一。

相当多的客户表示,他们将Extend视为极大的竞争优势。”这些家伙到现在还不是C轮或D轮公司,这让我感到困惑”是一个代表性的反馈。这种客户满意度水平说明了Extend解决方案的实际价值。

我相信,随着大语言模型继续改进,它们将开始以甚至人类都无法做到的方式理解最复杂的非结构化数据。

组织将有数百(或数千)个专业agent查看每个非结构化数据片段,连接点,并浮现我们甚至不知道要寻找的洞察。这将彻底改变企业处理信息的方式,从被动的数据存储转变为主动的智能分析。

随着越来越多的公司寻求使用AI加速工作的方法,Extend团队期待推出一个用户友好的界面,任何人都可以使用它来自动化数据处理和管道构建。

最终,我认为像Extend这样的公司正在构建的不仅仅是文档处理工具,而是企业智能的基础设施。

他们正在创建一个世界,在这个世界里,编程文档与调用API没有什么不同。这种转变将使企业能够充分利用其所有数据资产,而不仅仅是那些已经结构化的数据。对于那些能够率先采用这种技术的企业来说,这将成为巨大的竞争优势。

正如Extend所展示的,未来已经到来,而且它充满了可能性。在这个新的文档处理云时代,成功的企业将是那些能够将混乱的PDF转化为有价值洞察的企业。

本文由人人都是产品经理作者【深思圈】,微信公众号:【深思圈】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。