REMATIQ  ·  RESEARCH AGENT  ·  PRODUCT CASE

信任,就是产品。

TRUST IS THE PRODUCT

FAITHFUL [真实] + RELEVANT [相关] + SUPPORTIVE [支撑]
主线:把可验证的引用做成产品。这份 deck 自己也守这条规则,每个论点和数据都带可见来源。常规部分(真实+相关)回答案例;延展部分(支撑性+意图 Agent)是新解法。
RECAP · 案例

WHAT WE WERE ASKED

把研究 Agent 从原型,做到每天可信赖

REMATIQ 是 MedTech 合规平台,分三层:合规图谱、工作流、通用研究 Agent。本案例只管第三层:承接长尾问答和一次性文档的那一层。

  • 五个领域:法规问答、内部数据问答、文档生成、生命周期、引用来源
  • 两条硬约束:答案必须有可验证来源;Agent 在互联的图谱上工作
  • 周一四交付:① 重排 user story ② 与 Stefan 对齐 ③ 与 Anton 对齐 ④ 原型
本 DECK 目录
01案例重述(本页)
02REMATIQ 架构
03论证路线 Overview
04常规:可验证引用是底线
05生产解法 · reduce-hallucination
06前沿:支撑性
07解法:意图 Agent + 案例
08交付一 · 重排 story
09交付二 · 与 Stefan(需求 / ML+数据)
10交付三 · 与 Anton(成本 / 迭代+风险)
11原型 + UI 设计说明(可点 demo)
12结尾
先把发来的内容复述清楚,确认大家在回答同一个问题。原型(第四交付)这一轮先不做,等概念定稿后再做。
CONTEXT · 架构

WHERE THE RESEARCH AGENT SITS

研究 Agent 在 REMATIQ 的位置:在图谱上面读写

COMPLIANCE EXECUTION · 合规执行
Verifiable Workflows · 可验证工作流
Documentation Agents · 研究 Agent 本案例
▲   读 / 写   ▲
TRACEABILITY ENGINE · 可追溯引擎
RegulationsProductsRequirementsDesignTestsRisk ManagementMitigationsManufacturingSOPsWork InstructionsRecords → Submissions · Documentation · Records
Life Science Data Ontology 可验证引用 = 这里的 typed link
Audit Graph 审计签名留在这里
▲   拉取 / 回写   ▲
DATA SOURCES · 数据源
Laws & Regulations·Quality & QMS·Engineering & ALM·Regulatory & RIM·Files & APIs

取自 REMATIQ 官网。研究 Agent 就是顶层的 Documentation Agents,在 Ontology 和 Audit Graph 上读写。 REMATIQ.COM

REMATIQ 真实架构。研究 Agent = 顶层 Documentation Agents,在中层的可追溯引擎(Life Science Data Ontology + Audit Graph)上读写。可验证引用就落在 ontology 的 typed link 和 audit graph 上,用他们自己的话,不必再借 Palantir。
OVERVIEW

THE ARGUMENT, IN ONE BREATH

引用是后端要兑现的契约。

先确认行业常规,再讲生产里验证过的解法,然后指出前沿,最后给出解法和交付。常规和延展,分得很清楚。

回答案例 · 常规
  • 可验证引用是行业底线,真实性和相关性已经基本解决
  • reduce-hallucination 在生产里落地了这两层
延展 · EXTENSION
  • 真正的前沿是支撑性,而它取决于用户的意图
  • 用意图 Agent 和"陈而不断"来解决
better-doc:先给一句总论点,再给路线。常规(回答问题)和延展(新想法)分开,避免过度延伸模糊焦点。
CASE · 常规

THE FLOOR, ALREADY SOLVED

没有来源的答案,几乎没用。

这是受监管行业的底线。医疗和法律的 AI 早就把"带可点来源的回答"做成了标配:答案逐句锚定原文,能悬停预览,能跳转核对。

OpenEvidence

临床问答,逐句引用同行评审来源,没有依据就不答 OPENEVIDENCE

Harvey

法律,引用到法条和合同的具体段落,点击回原文核对 HARVEY

NotebookLM

RAG 加内联引用,响应级幻觉约 13%(没有 grounding 约 40%) NOTEBOOKLM

所以"显示引用"只是入场券;真正的壁垒是后端的验证。它解决的是前两支柱:真实性(引文属实)和相关性(切题)。

先承认这是常规,别把入场券当创新卖。这一页同时引入三支柱的前两支。
CASE · 常规

PRODUCTION CANON

reduce-hallucination:把前两支柱落到生产

它借用审讯科学里"让知情者说真话"的成熟做法 PEACE · SUE:把每个 LLM 节点当作一名证人,做成五道关卡,并在生产里验证过 2,818 TASKS。到这一步,真实性和相关性都能解决。

1Schema 留一个弃权出口:不确定就输出 null,不要猜
2{值 · 来源 · 逐字引文} 三件套
3在出口用代码核对引文是否逐字存在(零 LLM 成本)
4标注来源:stated · inferred · absent
5验证必须真做:只要求引用却不核对,模型会编出更逼真的假引用

"要求引用 + 真核对"效应 g≈0.80;同一个 prompt 里,带弃权出口的字段零纠错。 VERIFIABILITY STUDY PRODUCTION A/B 开源 · GITHUB

这是相对其他候选人的不公平优势:不是设想引用,而是在生产里真送过这套机制(presenter 可用第一人称口述)。讲清"借审讯科学 → 五道关卡 → 生产验证 → 解决真实+相关"。
EXTENSION · 延展

THE FRONTIER · 第三支柱

支撑性:被引的那一段,真的支撑这句话吗?

真实又相关,不一定支撑。一条能跳转、却不支撑主张的引用(misgrounding),比没有引用更糟,因为它制造虚假信任。支撑还是反驳,取决于用户想论证哪个方向。

支撑性 = 立场 × 意图
0%

链接有效 / 相关 · 表面合格

39–77%

真正支撑主张 · 实质失守

SOURCES CITED BUT NOT VERIFIED · 2026 STANFORD REGLAB · MISGROUNDING SCITE.AI ALCE · 部分支撑局限
这是延展,所以标 EXTENSION,并把来源摆上台面,正是"可验证"理念在自己答案里的体现。94% 对 39–77% 是关键数据。
EXTENSION · 延展

TWO AGENTS · PROACTIVENESS

回答之外,再设一个推断意图的 Agent

意图 ①②③④⑤
EXECUTION [回答] INTENT [读环]

执行 Agent 负责接地作答;意图 Agent 从当前问题出发,一层层把上下文纳进来,推断用户真正想论证什么。

① 问题 · 当前所问
② 会话 · 答案 / 草稿 / 修订
③ 历史 · 用户过去的选择
④ 团队和产品 · 别人怎么写 / 已有内容
⑤ 场景 · 更大的上下文

把各层合起来,得出意图,再决定引用哪一条,用正反两向解决支撑性。意图不确定时就给两向,由人来选。设计参考 KeyCite:方向只作复核标记,不下定论。 WESTLAW KEYCITE

两个 Agent:执行(回答)和意图(读环)。意图 Agent 的 input 是一圈圈向外的上下文:问题→会话→历史→团队/产品→场景。合起来得出意图,决定引哪条、怎么解支撑性。
EXTENSION · 一个案例

WORKED EXAMPLE · 不做 UI,只走流程

草稿 · 血压计风险管理文件

「SOP-042 已满足 ISO 14971 对剩余风险的要求。」

① 真实 + 相关 · reduce-hallucination

检索 ISO 14971 §8 和 SOP-042 §6,命中切题。
五道关卡:
✓ 三件套(值 · 来源 · 逐字引文)
✓ 逐字核对「residual risk shall be evaluated」在 §8 确实存在
✓ 来源 = stated
✓ 真核对通过
→ 真实性 + 相关性 已解

② 纳入上下文 · 意图 Agent

读会话和草稿:这段在「差距评估」章节,语气在自评。
再纳入历史和场景 →
意图不确定:是要自证合规,还是要找缺口?

→ 不确定,不替人决定

③ 支撑性 · 正反两引,由人选

▲ 支撑 ISO 14971 §6「风险控制」→ 支持「已满足」
▼ 反驳 §8 要求上市后做剩余风险监测;SOP-042 §6 没有这一步 → 暴露 gap

→ 选哪条就锚定交付,并回流成意图信号

同一句草稿,真实又相关;但支撑哪个方向,取决于意图。找反方证据,就是缺口分析。(条款编号是示例,以真实 UDM 段落为准) ISO 14971 · 示例 SOP-042 · 示例

端到端的例子:先用 reduce-hallucination 五道关卡解决真实+相关(逐项打勾),再由意图 Agent 纳入更多上下文,最后给正反两处引用让用户选。不做 UI,只走流程。条款号是示例,提醒不杜撰。
DELIVERABLE · 交付一

REPRIORITIZED USER STORIES

引用本是脊柱,PRD 却把它放进 NICE;现在提到 P0

P0 · 脊柱引用可点查看源 · 跳到 section/paragraph · 逐字引文校验 · 弃权裁决(库里没有 / 越权)
P1渐进披露答案(短主张 + chip + 展开,化解"答案太长") · 交付物独立成文档,PDF 导出
降级 / 缓图片支持 · DOCX · 多文档会话 · 完整存库(但引用从现在起就带版本戳)

依据:两条引用 story 在 PRD 里是 NICE 且没做,而定位和战略都把"可验证"当核心。试点反馈"答案太长",症结在结构,用渐进披露就能化解。 PRD PILOT FEEDBACK

回答他们问题的交付物之一。重排逻辑:把被错放成 NICE 的脊柱提到 P0,顺手用渐进披露解决头号抱怨。
DELIVERABLE · 交付二 / A

ALIGN WITH STEFAN · CUSTOMER NEED

与 Stefan 对齐(一):先验证客户需求的假设

对齐 = 带着判断去确认或推翻,不是开放式提问。每个问题都框成"它替我验证哪个产品决定"。

需求 · 长度"答案太长",真实需求是更少信息,还是能一键验证再展开?
验证:走渐进披露还是粗暴截断 · 证据回看 Marcel / Paul 的 langfuse trace
需求 · 代价自信错答 vs 诚实弃权,对 RA 的代价差多少?
验证:弃权该多激进 · 错结论进了提交材料,代价远高于一句"库里没有"
需求 · 双向给"正反两向证据",用户觉得强大,还是觉得工具没把握?
验证:支撑性这个核心功能值不值得做,以及怎么呈现
需求 · 优先级试点客户实际最往哪个领域使劲(法规问答 / 生成 / gap)?
验证:我的领域优先级排序对不对

我带去的不是问题清单,是判断 + 一份"等 Stefan 确认或推翻"的假设。

客户需求侧。把"答案太长"等模糊反馈,翻译成可被 Stefan 确认/推翻的具体产品决定。这页讲清"我去对齐什么、为什么、拿什么证据"。
DELIVERABLE · 交付二 / B

ALIGN WITH STEFAN · ML & DATA

与 Stefan 对齐(二):引用契约,数据和 ML 撑得住吗?

ML 可行性
  • 检索粒度:能可靠检索到 UDM 段落 / span 级吗?
  • 逐字验证:对 UDM 做确定性 string-match;OCR 归一化到哪一步需要有界模糊匹配?(成本分叉点)
  • 立场分类器:有没有 / 能不能建 claim-evidence entailment?在法规"有条件"语言上准吗?
  • 意图 Agent:是 ML(对 session 做 embedding / 聚类)还是 prompt?
  • 弃权阈值怎么标定?什么信号触发?
数据结构
  • 每个 UDM 段落有稳定、可解析、带版本戳的锚点吗?
  • typed link 在答题时可查询吗?(让 inferred 显示真实关系链,而非向量瞎猜)
  • 修订 / 草稿历史有记录、可访问吗?(意图 Agent 的命根子)
  • org / project scope 在数据层强制了吗?

一句话:这些撑得住,脊柱就能 v1 落地;撑不住,先补数据,别先做花活。

ML + 数据侧。本质:我们"可验证 + 有支撑 + 懂意图"的引用契约,数据和 ML 撑不撑得住。OCR 归一化是唯一要重点确认的成本分叉。
DELIVERABLE · 交付三 / A

ALIGN WITH ANTON · COST

与 Anton 对齐(一):逐条要真实成本,用成本不对称开场

便宜三件套 · provenance 徽章 · 弃权裁决(只改 schema / prompt)
"模型本来就检索了段落,这只是输出格式约束,不要新基建"
便宜–中按锚点对 UDM 做逐字 string-match,确定性、零 LLM
中等只在于:OCR 文本归一化要不要上有界模糊匹配,这是唯一要和 Anton 钉死的估算
中 · +1 LLM立场 / 交叉质询节点
只挂需要签字的高风险答案,不是每次查找都跑
贵 · 不确定意图 Agent
要 Anton 重点 scope:异步跑 session 日志?走已有后台执行层?延迟 / 成本 / 数据依赖?

对 Anton 的论点:脊柱大半便宜;贵的那半(验证器)正是 demo 和可信工具的分水岭。跳过它,产品更危险,不只是不够惊艳。

工程成本侧,逐条。用成本不对称说服:便宜地拿下脊柱,把贵的部分诚实框定。OCR 归一化是要钉死的那一个估算。
DELIVERABLE · 交付三 / B

ALIGN WITH ANTON · ITERATION & RISK

与 Anton 对齐(二):按成本排 v1 / v2 / v3,并摆出风险

迭代路线(按成本)
v1 · 便宜真实 + 相关 + 双向种子。逐字 match + 弃权 + 正反两向(先记录,不回流)
v2 · 中蒸馏一个微调 NLI 模型(成本 / 延迟大降)+ 意图 Agent + 闭合学习回路(护反驳类,防确认偏见)
v3 · 贵自检 + 渐进自治 + GxP 验证 / 审计轨迹(主要是治理,不是模型活)
主动抛出的工程风险
  • 脏 OCR 文档上的确定性(→ 模糊匹配阈值)
  • 意图 Agent 的数据依赖(有没有记录修订)
  • proactivity × 访问控制的交叉
  • 版本正确性:源改了,旧引用怎么办

一句话成本故事:v1 是一个 prompt 加一个 schema;v2 是一个便宜的蒸馏模型加一个贵的意图 Agent;v3 主要是治理。

迭代 + 风险。让 Anton 帮我按成本排序,并主动暴露我考虑过的工程风险,显得不是空谈。一句话成本故事便于他记住。
PROTOTYPE · 原型

A CURSOR FOR COMPLIANCE DOCS · 可点 DEMO

合规文档版的 Cursor:Agent 在左,文档在右,验证在中间

左 AGENTS · 会话

多个合规任务并行(像 Cursor 的 sessions)· 左下常驻意图 Agent:一直运转,显示读了什么、input 加了什么、当前意图

中 运行日志 + 对话

接地轨迹:读取 → 逐字验证 ✓ → 判立场 → 正反两向 · 证据化进可审计日志 · 点引用弹源文

右 文档编辑器

生成的合规文档,可编辑、带版本历史 · 修订回流给意图 Agent · 签认 = attestation

无后端,写死一个案例(血压计 / SOP-042 / ISO 14971)。验证是真实的 JS 逐字 string-match。 ▶ 现场 DEMO · /demo 高光帧 · #go

合规文档版的 Cursor / Claude Desktop。左 Agent 会话 + 常驻意图;中 运行日志(验证化进审计轨迹);右 版本化文档编辑器。一个案例演全部。现场用 /demo,#go 直接进高光帧。
FEATURE WALKTHROUGH · 功能走查

6 个能力 · 对应 6 个需求(截自可点 demo)

来源库 · 法规蓝/内部金 · 多会话 · 常驻意图
需求:答案可溯源 · 内部/法规边界 · 意图可见
接地运行 · 逐字验证 ✓ · 正反两向你选
需求:真实性 + 相关性 + 支撑性
点引用 → 源段高亮验证 / 右侧分栏开全文
需求:点击回源核对(法规到段落)
纸张式文档编辑器 · 版本历史 · 语义化按钮
需求:可编辑交付物 + 生命周期
版本 diff(绿加红删)
需求:修订可追溯 · 回流意图 Agent
派给 Workflow · 新建结构化会话
需求:三层联动(研究 Agent = 平台入口)
功能走查:6 张截自可点 demo,每张「功能 → 需求」。给评审一个静态、可读的能力总览,无需现场驱动复杂 demo。细节看 /demo 或导览。
UI RATIONALE · 设计说明

WHY THIS LAYOUT · 站在 AGENT-IDE 范式上

为什么这么设计:借 Cursor / Claude 的范式,加一层合规独有的东西

借鉴 · agent-IDE 范式
  • 三栏:左 Agent 会话 / 中 对话运行 / 右 产物编辑 CURSOR · CLAUDE DESKTOP
  • 多会话并行 + 模型选择器 + @ 提及文档 CURSOR · CLAUDE
  • 引用到具体段落,点击核对 HARVEY
  • 原子主张、逐条出处 HEBBIA
  • 逐块 accept + 版本 / diff GEMINI IN DOCS · CURSOR
我们加的合规独有层
  • 每条主张后端逐字验证,不接地就弃权(Cursor 只验代码,不验事实)
  • 常驻意图 Agent:一直推断你要论证什么,主动给正反两向(Cursor / Claude 没有)
  • 一切可审计:运行日志 + 版本历史 + 签认 → Audit Graph

Cursor / Claude Desktop 证明了 agent-IDE 这套交互可行;把它搬到合规,再加上"可验证 + 懂意图 + 可审计"。这就是合规文档版的 Cursor。

回答"为什么这么设计":站在 Cursor / Claude 的 agent-IDE 范式上(左 Agent / 中对话 / 右产物),加三样合规独有的:后端验证、常驻意图 Agent、全程可审计。不再以 NotebookLM 为主参照。

THE ONE TAKEAWAY

可验证的来源,就是信任的地基。

常规部分已经在生产里落地;前沿的支撑性,用意图 Agent 来解。近处做扎实,其余按 v1 → v2 → v3 推进。

▶ 打开可点 DEMO · rematiq-case.pages.dev/demo

收束。这份 deck 自己就践行了它的主张:每个论点都带可见来源。最后给一个可点 demo 链接。