业务本体与对象建模
把散落在文件、表格和系统里的人员、账户、合同、项目与评分规则，建立明确的身份、关系和约束。每一次分析都知道自己面对的是哪一个对象。
技术说明
业务本体（Ontology）定义对象类型、关系和业务约束；对象实例记录已核验的事实与当前状态；知识图谱承载跨资料、跨系统发现的关联。三者相辅相成，但不是同义词。
看得懂，不等于办得对
大模型已经能读文档、写摘要、回答问题。但在评标、资金分析、财务审核这类业务里，一个结论必须经得起四个追问：
-
看对对象
这段材料属于哪个项目、哪个人、哪个账户、哪个评分项？
-
找对依据
依据来自哪份原始文件、哪一页、哪条记录、哪个版本？
-
用对规则
口径、阈值、时间顺序和计算公式是否明确，是否适用于这一次判断？
-
做对动作
谁有权决定？是否需要人工确认？系统实际执行并记录了什么？
关键不在于模型能否说得像专家，而在于让它的推理进入业务系统的计算链、判断链和审计链。
三项核心能力
三项能力围绕同一组业务对象协作，按任务组合使用，而不是一条固定的流水线。
复杂材料理解与证据追溯
解析扫描件、多页表格、票据和银行流水，保留每条信息的原文位置。我们区分四件事：找到了，属于它，适用于它，已经成立。
技术说明
多模态解析（OCR、视觉语言模型、表格结构恢复）与检索增强（RAG）负责“找到”；对象关联与条件判断负责“属于”和“适用”；核验状态负责“成立”。溯源能证明引用了什么，却不能自动证明引用是对的。
可控的专业智能体
大模型负责语言理解与开放分析，规则与程序负责精确计算，专业模型处理边界明确的判断，人负责关键决定。状态留在系统里，重要动作有边界。
技术说明
编排层负责任务拆解、工具调用、暂停与恢复；授权与审计记录谁提出请求、用了哪些证据、按什么规则判断、哪个模型版本参与、由谁确认。
重点实践
我们优先投入规则复杂、关系复杂、证据要求高、结果必须复核的领域。
解决方案
纪检监察：资金流水分析
难点多家银行、多种版式的流水散落各处；一人多卡、跨行流转、快进快出，人工逐笔比对既慢又容易遗漏。
做法把原始流水转化为可跨账户查询、可沿链核查的资金关系网络。确定性的查询与规则负责筛选和计算，大模型辅助解释线索，最终由专业人员核查。
- 多源流水标准化：不同银行的 PDF、扫描件、Excel 统一为可查询的交易数据，保留原始记录位置。
- 账户关联与资金路径：识别同一人名下的多个账户，还原跨行流转与资金去向。
- 线索与证据回看：标明触发了哪条规则、引用了哪些原始记录、还缺哪些信息。
边界输出的是待核查线索，不是对违纪违法事实的认定。
提问李某近期有没有大额资金快进快出？重点看与工程公司的往来。
- XX 工程公司
- 10:05转入 60 万元
- 工行账户 A
- 10:20跨行转出 58 万元
- 建行账户 B
- 11:02柜面取现 30 万元
- 现金
- 发现
- 入账至取现间隔 57 分钟待核查线索
- 依据
- 工行转出、建行转入两条原始记录相互印证
演示规则：单笔入账超过 50 万元，2 小时内转出或取现。阈值由业务方配置，并非法定标准。
解决方案
智能辅助评标
难点评分细则复杂，投标文件篇幅长、附件多，资质、业绩合同、技术参数散落在不同章节。逐条查证费时，也容易错配或遗漏。
做法分别建立招标侧与投标侧的业务对象，再为每个评分项建立“要求—响应—证据”的对应关系。
- 评审规则结构化：从招标文件中提取资格条件、评分细则、否决项与分值。
- 要求、响应与证据对应：为每个评分项定位投标原文与证明材料，发现缺失、矛盾与错配。
- AI 初评，专家终审：可计数、可计算的部分交给程序，语义理解由模型辅助，涉及专业裁量的结论由专家确认。
边界辅助专家评审，不替代专家作出评标结论。
评分项近三年同类项目业绩，逐条核查投标响应与证明材料
| 投标响应 | 证明材料 | 核查结果 |
|---|---|---|
| 业绩表第 1 项 | 合同首页与签订页齐全，签订日期在要求范围内 | 已对应 |
| 业绩表第 2 项 | 合同甲方名称与业绩表填写不一致 | 待核实 |
| 逐字复述招标要求 | 未附合同或其他证明 | 建议不计分 |
文字与要求高度相似，不等于满足要求。所有核查结果由评标专家确认。
可复用的能力方向
方案与原型以下方向已形成方案或原型，可按具体业务组合使用。
-
财务审核
报销审核把费用制度、票据与审批规则交叉核验；报表审核用公式引擎精确复算跨表勾稽，不交给模型估算。
-
智能问数
先确认业务口径，再生成并校验 SQL，由数据库完成精确计算。“本月销售额”是下单额、支付额还是净额，要先说清楚。
-
文档与合同比对
确定性的差异比对回答“哪里变了”，大模型解释“变化意味着什么”，两者各司其职、不互相替代。
-
企业知识库
看得清、找得到、答得对、溯得回：解析、检索、回答和来源定位逐一把关。
本页场景示意均使用虚构数据，不对应任何真实案件、项目或客户。
我们的方法
下面是复杂业务智能体的简化架构。它说明各项能力如何围绕业务对象协作，并不意味着每个任务都要逐层经过。
业务材料与事件
文档、表格、银行流水、业务系统、实时数据
按任务组合，可往返
业务对象与语义层
对象身份、关系、规则、状态、指标口径
证据检索与数据计算
检索增强（RAG）、SQL、知识图谱、结构解析、专业模型
可控编排
大模型、规则与工具协同：开放推理、结构化判断、精确校验
核验、人工确认与授权
高风险判断由有权限的人确认或纠正
业务结果
结论、原文溯源、状态写回业务系统
可追溯，分三条链
-
证据链
- 原始材料
- 具体位置或字段
- 所属对象与条件
- 核验状态
-
判断链
- 规则或模型版本
- 判断与计算
- 适用条件与交叉检查
- 结论与分歧
-
动作链
- 权限与审批
- 实际执行
- 状态变化
- 人工确认或纠正
我们区分三类事实：资料中声称的、系统已验证的、系统已执行的。
按任务选择最小充分能力
| 任务 | 能力组合 |
|---|---|
| 制度问答、知识查找 | 检索增强（RAG）：解析、检索、引用、版本 |
| 材料核验、报销与合同审核 | RAG + 规则 + 模型理解 + 人工复核 |
| 智能问数 | 语义层与指标口径 + SQL 生成与校验 + 数据库精确计算 + 权限 |
| 评标、资金分析等多对象高风险判断 | 业务本体 + 证据链 + 确定性规则 + 模型 + 状态管理 + 人工把关 |
不为“先进”而堆叠能力。
几个基本判断
流程描述“怎么做”，对象描述“对谁做”
路径可以随情况变化，但业务对象及其约束不能临场编造。这是复杂业务智能体需要本体的原因。
找到 ≠ 属于 ≠ 适用 ≠ 成立
检索能找到相关材料，溯源能证明引用了什么，但都不能自动证明这条依据适用于当前对象、版本和条件。
正确执行的 SQL，不等于正确的口径
“本月销售额”可以是下单额、支付额或扣除退款后的净额。先对齐业务语义，再让数据库精确计算。
动态路径，稳定的业务世界
已知步骤按流程走，未知部分允许模型在明确边界内探索；状态保存在业务对象里，而不是一次对话的上下文里。
关于深潜智力
北京深潜智力科技有限公司专注企业级大模型应用与复杂业务智能体的研究和落地。我们以业务本体为语义基础，把大模型、文档理解、证据检索、确定性规则与可控工作流连接起来，优先投入纪检监察分析、辅助评标、财务与合规审核等规则复杂、证据要求高、结果必须复核的领域。
我们重视把复杂业务需求、企业架构、数据与 AI 技术连接起来，强调从问题定义、原型验证到系统集成与迭代交付的工程闭环。
名字里的“深潜”，是我们选择的方向：不停留在水面上的回答，而是深入业务对象、证据与规则所在的地方。
我们的工作原则
-
先理解业务，再选择技术
从业务对象、规则和责任边界出发，而不是从模型出发。
-
确定性优先
能用规则和程序算准的，不交给模型猜；模型用在真正需要理解和判断的地方。
-
人在关键位置
高风险判断保留人工复核与授权，过程可追溯、可纠正。
从一个具体问题开始
如果您的业务规则复杂、材料繁多、结论需要经得起复核，欢迎与我们交流。我们通常从一个具体问题谈起：它涉及哪些对象，依据在哪里，规则如何适用，最终由谁确认。
- 合作邮箱
- 待确认
- 公司地址
- 待确认（可选）