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–09交付一 · 二 · 三
10结尾
先把发来的内容复述清楚,确认大家在回答同一个问题。原型(第四交付)这一轮先不做,等概念定稿后再做。
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 FAVORITE CASE
这是相对其他候选人的不公平优势:不是设想引用,而是在生产里真送过这套机制(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 · 交付二 + 三
ALIGNMENT · 每个问题都问"验证哪个机制"
交付二 · 与 STEFAN(客户 / ML / 数据)
- 需求:"答案太长",想要的是更少,还是能一键验证再展开?
- ML:UDM 段落能不能做确定性逐字匹配?OCR 容差到哪一步需要模糊匹配?立场分类器可行吗?
- 数据:段落有稳定、带版本的锚点吗?typed link 答题时能查吗?修订记录留存吗?
交付三 · 与 ANTON(工程成本)
便宜三件套 · 来源标注 · 弃权(改 schema/prompt)
便宜–中UDM 逐字匹配(零 LLM;唯一要钉:OCR 归一化)
中 · +1 LLM立场 / 交叉质询,只挂高风险答案
贵 · 不确定意图 Agent(异步跑会话日志,走后台执行层)
迭代:v1 真实+相关+双向种子 → v2 立场分类+意图 → v3 完整 loop。脊柱大部分便宜,贵的那两块正是差异化。
两份对齐合一页。Stefan 验证数据和 ML 撑不撑得住引用契约;Anton 用成本不对称便宜拿下脊柱,贵的按 v1/v2/v3 排进迭代。
THE ONE TAKEAWAY
可验证的来源,就是信任的地基。
常规部分已经在生产里落地;前沿的支撑性,用意图 Agent 来解。近处做扎实,其余按 v1 → v2 → v3 推进。
收束。这份 deck 自己就践行了它的主张:每个论点都带可见来源。