再保险行业的文档处理痛点被量化到 40% 时间浪费和 14% 预算浪费，做保险科技或金融文档自动化的团队可以直接参考这个端到端方案，尤其是人机协同闭环的设计思路值得借鉴。
Re-Ink 是 LandingAI 金融 AI Hackathon 冠军项目，针对再保险承保流程中文档处理耗时严重的痛点，构建了从 PDF/DOCX 条约文档到可审核合同记录的端到端自动化方案。行业数据显示，再保险承保人约 40% 时间用于行政工作，手动提取错误率超 6%，运营预算中约 14% 用于修复此类错误。Re-Ink 使用 LandingAI 的 Agentic Document Extraction (ADE) 作为文档智能核心，结合 FastAPI + React + PostgreSQL + LangGraph 栈，实现上下文感知的字段提取，无需正则或模板。关键设计是人机协同闭环：提取后人工审核，所有数据在 reviewer 确认前不持久化，审批后以单事务创建记录，任何校验失败均回滚。项目还包含两个 LangGraph Agent 用于入库前引导和审批后分析，支持 offline 模式便于自动化测试。
Re-Ink：再保险合约智能提取与审核参考实现 @LandingAI 金融 AI Hackathon 冠军之一，针对再保险承保流程中耗时严重的文档处理痛点，构建从 PDF/DOCX 条约文档到可审核...
Re-Ink：再保险合约智能提取与审核参考实现 @LandingAI 金融 AI Hackathon 冠军之一，针对再保险承保流程中耗时严重的文档处理痛点，构建从 PDF/DOCX 条约文档到可审核合同记录的端到端自动化方案。 行业痛点量化 再保险承保人约 40% 时间用于行政工作，主要为手动将条约数据（日期、保费、留存限额、参与方名称等）重新录入合同管理系统。Accenture P&C Underwriting Survey 数据显示： · 实际承保工作仅占 30%； · 行政任务占 40%； · 谈判与销售支持占 30%。 手动提取存在系统性风险：日期格式多变、参与方名称不一致、金融术语表述差异大，即使在规范环境下错误率仍超 6%（Reisch et al., 2024）。保险公司运营预算中约 14% 用于修复此类手动错误。 Re-Ink 核心方案 Re-Ink 使用 LandingAI 的 Agentic Document Extraction (ADE) 作为文档智能核心，结合 FastAPI + React + PostgreSQL + LangGraph 栈，实现： 1. 上传与结构解析：ADE 自动识别 PDF/DOCX 的章节、表格、标题、段落及嵌入数据。 2. 字段提取：基于预定义 schema（合同标识、日期、金融条款、覆盖细节、参与方信息）进行上下文感知提取，无需正则、模板或格式特定逻辑。 · 优势：能处理“Net Retention”“Ceding Company Retention”等不同表述，或嵌入段落中的留存金额。 · Hackathon 测试（SEC EDGAR 文件）显示，在提取 cedent（分出公司）和 reinsurer（再保险公司）名称时特别可靠，即使出现在叙述性文本中。 关键设计：人机协同闭环 · 提取后人工审核：所有数据在 reviewer 确认前不持久化。ReviewForm 展示提取字段，支持编辑、补充或拒绝。 · 事务保障：审批后以单事务创建 Contract 和 Party 记录，任何校验失败均回滚。 · 业务理由：再保险合同涉及数百万美元义务，监管要求人工基于业务上下文验证原文档，AI 输出不可作为合规唯一依据。 · 反馈优化： reviewer 反复修正的模式可指导 schema 或 prompt 迭代。 Agent 层增强 Re-Ink 使用两个 LangGraph Agent（均不负责提取，仅封装业务逻辑）： · 入库前引导 Agent：检查缺失必填字段、日期逻辑矛盾等，并生成建议审核 payload。 · 审批后分析 Agent：StateGraph 包含 validate（完整性检查）和 analyse（LLM 风险与合规标记）节点。 两者均支持 offline 模式（确定性 mock），便于端到端自动化测试。 LandingAI @LandingAI x.com/i/article/2065… 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 0 👀 228 ⚡