写在前面：这段时间以来产生了很多的AI智能体应用，也有很多使用AI相关技术为自身所在垂直领域"赋能"的应用产生。我非常想知道，“第一批"产生的AI助力垂直领域的应用在技术方面都"做对了什么”，所以产出了下面这篇AI产出框架的讨论。

叠甲：写作过程中大量使用了AI帮助以及搜索引擎、CSDN信息查阅。

---

卷首一句话：垂直领域 AI 助力的核心工程框架

---

1. 为什么需要 RICE 中间层

通用大模型在专业领域面临的几个问题：

问题	表现
幻觉（Hallucination）	编造法规条文、错写公式、虚构数据
实时性缺失	训练数据有截止期
合规不可控	可能输出投资建议、医疗诊断、法律定性等违规表述

RICE 中间层不是替代大模型，而是围绕大模型构建一个可控、专业、可审计的工程框架。

---

2. RICE 整体架构

RICE 更适合被理解为一个可编排的中间层能力集合，而不是一条固定的线性流水线。真实业务里，解析、检索、计算、生成、校验之间经常会多轮循环：模型可能先判断意图，再触发检索；检索结果不足时再查数据库；涉及精确结果时调用计算工具；输出前再做合规和事实一致性校验。

架构要点

• 编排层是核心：负责判断当前问题该走 OCR、检索、数据库查询、规则引擎、计算器还是大模型生成。
• Retrieval 和 Computation 不是 LLM 的前置固定步骤：它们更像工具箱，按任务动态调用。
• 输出治理层可以反向影响生成链路：如果发现违规、无引用、事实不一致，可以要求重新检索、重新计算或重新生成。
• RICE 不等于所有组件都必须上齐：不同阶段可以只实现其中一部分能力。

---

3. Interpretation（解析层）

把混沌的非结构化输入（PDF、图片、语音、传感器信号）转换为模型可理解的结构化语义。

场景	技术组件举例	选型建议与 Trade-off
文档/图片解析	PaddleOCR / Marker / unstructured.io / LayoutLMv3	Marker 对论文 PDF 效果极好但慢；LayoutLM 适合表单；unstructured.io 通用性强但成本高
语音输入	Whisper / FunASR / 讯飞 ASR	Whisper 开源免费但金融术语识别弱，需加领域微调；讯飞中文场景更准但按量计费
信息抽取（NER）	spaCy / HanLP / LLM+JSON Schema	规则 NER 快但泛化差；LLM 抽取准但贵。金融场景建议"规则兜底 + LLM 覆盖长尾"
结构化校验	Pydantic / JSON Schema / 正则管线	必须做：模型输出常 hallucination 字段类型，Pydantic 强校验后重试
时序/传感器数据	Pandas / TDengine / InfluxDB 预处理	工业场景先做滑动窗口特征工程，再进模型

架构要点

• 这一层通常是异步流水线（Kafka / Celery），因为 OCR 和 ASR 都是慢 IO。
• 例如用户上传财报 PDF，先扔队列，解析完再回调 LLM 层。

---

4. Retrieval（检索层）

给模型喂对的数据，解决"模型不知道内部知识"和"实时数据"问题。

组件	技术栈	关键决策
Embedding 模型	BGE-M3 / e5-mistral / GTE / 自研领域模型	通用文本用 BGE 足够；金融/法律建议用领域内继续预训练的模型（如 BloombergGPT 抽向量）
向量数据库	Milvus / Weaviate / PGVector / Qdrant	PGVector 适合已有 PG 生态的团队，省去运维；Milvus 十亿级性能更好但组件重
稀疏检索（关键词）	Elasticsearch / OpenSearch / BM25	纯向量检索对专有名词（股票代码、法条编号）召回差，必要时须混合 BM25
知识图谱	Neo4j / NebulaGraph / JanusGraph	金融风控的"企业关联图谱"、医疗的"病症-药品-禁忌"关系，图遍历比向量语义检索更精准
重排序（Rerank）	BGE-Reranker / Cross-Encoder / Cohere Rerank	先向量召回 Top-50，再用 Cross-Encoder 精排取 Top-5，性价比最优
实时数据接入	Flink / Kafka + 向量库增量更新	财报、行情、新闻需要分钟级入向量库，不能等离线批处理

架构模式：Hybrid RAG（混合检索）

用户Query → 并行路由 → [向量检索 Top-K] + [ES 关键词 Top-K] + [图谱子图查询]
                    ↓
              重排序模型合并去重 → Top-N 上下文 → 注入 Prompt

---

5. Computation（计算层）

精确的事屏蔽模型发散的可能性，用专业工具做专业计算。

计算类型	技术栈	典型场景
符号计算	SymPy / WolframAlpha API / SageMath	教育解题、工程公式推导
金融量化计算	QuantLib / Pandas/NumPy / 自研 C++ 库	期权定价、VaR 风险值、久期计算
规则引擎	Drools / EasyRules / 自研规则树	信贷审批规则（收入>月供×2）、合规话术拦截
仿真求解	MATLAB / Aspen / ANSYS / CFD	化工工艺参数优化、建筑风荷载仿真
图算法	NetworkX / Neo4j GDS / GraphX	反洗钱资金流向环路检测、供应链核心企业识别
时序分析	Prophet / Statsmodels / 自研 LSTM	设备故障预测、库存需求预测
数据库查询生成	Text-to-SQL（Vanna / 自研 Schema-linking）	自然语言问"上个月华东地区销售额Top10"，先转 SQL 查数，再让模型总结

架构模式：LLM 作为调度器（Tool Use / Function Calling）

{
  "thought": "用户问的是这只股票的PE是否被高估，需要计算当前PE和同业对比",
  "tool": "financial_calculator",
  "arguments": {"ticker": "600519.SH", "metric": "PE_TTM"}
}

模型只决定调什么工具、传什么参，计算本身在沙箱里执行，结果再喂回模型做自然语言包装。

关键工程决策

1. 计算层必须和模型层物理隔离（容器/沙箱），防止 Prompt Injection 导致执行恶意代码。
2. 金融计算结果需版本锁定：QuantLib 版本不同结果可能差几位小数，必须固定镜像。

---

6. Explanation / Governance（可信输出治理层）

这一层不只是“解释”，更准确地说是可信输出治理层：让回答可解释、可追溯、可审计、可管控。它解决的是“模型说出来的话能不能被业务、用户和监管接受”的问题。

功能	技术栈	说明
溯源（Attribution）	RAG 上下文标记 / 引文抽取模型	输出中的关键事实应映射到源文档页码、段落、数据库记录或计算结果，不是“我感觉”
护栏（Guardrails）	Guardrails AI / Lakera / 自研规则管线	金融：拦截“保证收益”“稳赚”；医疗：拦截“停药”“确诊”；法律：拦截“构成犯罪”
事实一致性校验	引文比对 / NLI 模型 / 规则校验 / 人工抽检	检查模型回答是否被检索材料、计算结果或业务规则支持，降低幻觉和断章取义
输出模板化	Jinja2 / Mustache / 领域 DSL	把模型输出放进固定格式，如风险提示、免责声明、审批意见模板，避免每次让模型自由生成合规话术
审计日志	ClickHouse / Elasticsearch / 对象存储	记录完整调用链：用户 Query → 解析结果 → 召回文档 → 计算工具 → 模型原始输出 → 后处理结果，保存 5-10 年
A/B 测试与评估	LangSmith / Langfuse / 自研标注平台	持续监控回答准确率、幻觉率、引用覆盖率、用户满意度和成本

架构模式：输出治理管线（Response Governance Pipeline）

模型原始输出
  → 安全与合规护栏检查
  → 事实一致性校验（和检索文档/数据库/计算结果比对）
  → 引用与溯源补全
  → 模板渲染与话术规范化
  → 审计落盘
  → 返回用户

如果输出治理不通过，不应简单返回错误，而应根据原因进入不同分支：

• 缺少依据：回到 Retrieval 层重新检索或扩大召回范围。
• 计算不一致：回到 Computation 层重新计算或触发人工复核。
• 合规风险：改写为合规表达，或返回预设安全话术。
• 高风险场景：升级人工审核，不直接给最终结论。

---

7. 典型金融场景技术选型示例

智能投研助手：

RICE 层	具体技术
Interpretation	unstructured.io 解析 PDF 财报 + LayoutLM 识别表格 + Pydantic 校验结构化字段
Retrieval	BGE-M3 Embedding + Milvus/PGVector + Neo4j（企业关联图谱，按需引入）+ ES（公告关键词检索）+ BGE-Reranker
Computation	自研 Python 量化库（Pandas/NumPy）计算财务比率 + QuantLib 做衍生品估值 + Drools 做估值合理性规则校验
Governance	自研护栏（拦截投资建议表述）+ 溯源标记（每个数据点标注来源财报页码）+ ClickHouse/ES 审计日志

---

8. 部署架构建议

RICE 不要求一开始就部署一整套重型基础设施。更合理的方式是按业务阶段逐步演进，先验证价值，再补齐能力。

8.1 参考服务划分

┌─────────────────────────────────────────────┐
│              API Gateway (Kong/Spring)      │
├─────────────────────────────────────────────┤
│  Orchestrator / Workflow Service            │
│  - 意图识别 + 任务编排 + 工具路由 + 降级策略      │
├─────────────────────────────────────────────┤
│  Interpretation Service (Python/FastAPI)    │
│  - OCR/ASR/NER 异步任务队列 (Celery + Redis)  │
├─────────────────────────────────────────────┤
│  Retrieval Service (Go/Java/Python)         │
│  - 混合检索协调 + Rerank + 缓存 (Redis)        │
├─────────────────────────────────────────────┤
│  Computation Service (Python/Java/C++)      │
│  - 规则、计算、数据库查询、必要时沙箱执行          │
├─────────────────────────────────────────────┤
│  LLM Proxy Service (Python/Go)              │
│  - 负载均衡 + 流控 + 模型路由 (GPT-4/Claude)    │
├─────────────────────────────────────────────┤
│  Governance Service (Java/Python)           │
│  - 护栏 + 事实校验 + 模板 + 审计                │
└─────────────────────────────────────────────┘

8.2 分阶段落地建议

阶段	适用情况	建议能力	暂缓能力
MVP 阶段	验证场景价值、用户需求和基础效果	LLM Proxy、基础 Prompt、简单文档解析、PG/ES 检索、基础日志、人工反馈入口	知识图谱、Flink 实时流、复杂沙箱、全量审计平台
增长阶段	已有稳定用户和明确高频场景，需要提升准确率	Hybrid RAG、Rerank、结构化知识库、结果缓存、内容安全、自动评测集、A/B 测试	复杂多 Agent、自研大模型、重型图计算
成熟阶段	强合规、高并发、多业务线、可审计要求高	独立向量库、知识图谱、实时数据接入、沙箱计算、全链路审计、多模型路由、人工审核工作台	无业务价值的过度组件化

8.3 核心原则

每层都应能独立扩缩容、独立降级：

• 计算层挂了，检索层还能返原文摘要。
• LLM 限流了，规则引擎或模板系统能直接走兜底回复。
• 治理层护栏触发，可以阻断输出、改写输出或升级人工审核。
• 检索层不可用时，可以降级到缓存答案、FAQ 或明确提示“当前无法查询实时资料”。

同时要避免“架构先行”的误区：

• 不要为了 RAG 而 RAG，先确认知识召回确实能提升业务指标。
• 不要为了图谱而图谱，只有强关系推理场景才值得引入。
• 不要为了实时而实时，很多行业知识库每天或每小时更新已经足够。
• 不要一开始就上过多语言和过多中间件，团队能稳定运维比技术名词更重要。

---

9. 各行业 RICE 适用速查(个人知识局限，纯AI产出)

行业	Interpretation	Retrieval	Computation	Explanation
金融投研	财报 PDF 结构化	公告/研报/行情向量库	QuantLib 估值引擎	合规话术拦截 + 数据溯源
银行信贷	征信报告 OCR	企业关联图谱	规则引擎（收入比、反欺诈）	审批链留痕
证券合规	聊天记录解析	监管法规库	违规模式匹配	审计日志 10 年保存
医疗诊断	病历结构化（FHIR）	临床指南/药品库	禁忌症规则校验	证据等级标注 + 风险提示
法律合同	版式分析抽条款	判例库/法条库	条款风险规则	修改 diff 溯源 + 依据标注
工业制造	传感器信号滤波	设备知识库	MATLAB/Simulink 仿真	物理极限边界校验
政务咨询	申请表单 OCR	政策图谱	资格规则匹配	办事流程模板化 + 政策依据

---

10. 总结

RICE 不是替代大模型，而是把大模型从"样样通"变成"有专业团队支持的专家"：

• Interpretation：让专家能看懂你给的原始材料
• Retrieval：给专家准备好参考资料和实时情报
• Computation：让专家用计算器而不是心算
• Governance：让专家的每句话都有据可查、合规安全、可审计可追责

大模型从"裸奔的天才"变成"持证上岗的专业顾问"。

---

11. RICE 各层技术实现语言举例(程序员参考)

RICE 各层不是单一语言，而是按场景选语言。Python 在 AI/数据侧统治，Java 在企业级/规则侧统治，Go 抢中间件，C++/Rust 打底性能。

11.1 Interpretation（解析层）

技术点	主流实现语言	原因
PaddleOCR / LayoutLM	Python	模型推理全是 PyTorch/PaddlePaddle
Whisper / FunASR	Python	语音模型生态就是 Python
spaCy / HanLP NER	Python（spaCy）/ Java（HanLP）	NLP 研究用 Python，工程化中文分词有 Java 版
JSON Schema / Pydantic 校验	Python（Pydantic）/ Java（Bean Validation）/ Go（go-playground/validator）	取决于主服务语言
传感器信号预处理	Python（Pandas/SciPy）/ Java/Scala（Spark Streaming）	数据科学用 Python，实时流处理用 JVM 生态

结论：这层 80% 是 Python，因为 OCR、ASR、NLP 模型推理全绑在 Python 生态上。只有和企业主系统对接的校验环节，才会用 Java/Go 重写一遍。

11.2 Retrieval（检索层）

技术点	主流实现语言	原因
Embedding 服务（BGE/e5）	Python（FastAPI/TorchServe）	模型推理必须是 Python
向量数据库（Milvus/Qdrant）	服务端 C++/Go/Rust，客户端多语言	底层要性能，所以用系统语言写；对外提供 Python/Java/Go SDK
Elasticsearch / OpenSearch	Java	底层就是 Lucene（Java），服务端纯 Java
知识图谱（Neo4j）	Java（服务端），Python（py2neo 客户端）	Neo4j 本身是 Java 写的；图查询用 Cypher，但业务层用 Python/Java 封装
Flink 实时接入	Java / Scala	Apache Flink 是 JVM 生态
Rerank 模型（Cross-Encoder）	Python	同样是 PyTorch/Transformers 推理

结论：检索层是 Python + Java 双主。模型端（Embedding、Rerank）用 Python；工程端（ES、Neo4j、Flink）用 Java。

11.3 Computation（计算层）

技术点	主流实现语言	原因
SymPy / NumPy / Pandas	Python	科学计算标准语言
QuantLib	C++（核心库），Python（PyQuantLib 封装）/ Java（QuantLib-JNI）	金融量化内核用 C++ 保性能，业务层包一层 Python/Java
Drools 规则引擎	Java	RedHat 家的，纯 Java 生态
MATLAB / Aspen 仿真	MATLAB 专有语言 / C++（MATLAB 编译）	工业仿真工具链封闭，MATLAB 脚本或生成 C++
图算法（Neo4j GDS / GraphX）	Java/Scala（GraphX）/ C++（GDS 底层）	Spark GraphX 是 Scala；Neo4j GDS 插件是 Java
Text-to-SQL（Vanna）	Python	Vanna 是 Python 库
时序预测（Prophet）	Python / R	Facebook Prophet 是 Python/R

结论：计算层最分裂。金融/科学计算内核是 C++（QuantLib、MATLAB），业务封装用 Python；规则引擎和大数据图计算是 Java/Scala；轻量计算脚本用 Python。

11.4 Explanation / Governance（可信输出治理层）

技术点	主流实现语言	原因
Guardrails AI	Python	纯 Python 库
自研合规规则管线	Java（Drools）/ Python	重规则用 Drools（Java），轻量用 Python
Jinja2 / Mustache 模板	Python（Jinja2）/ Java（Mustache.java）/ Go（html/template）	随主服务语言走
ClickHouse / ES 审计日志	服务端 C++（ClickHouse）/ Java（ES），客户端多语言	和 Retrieval 层一样，底层系统语言，上层业务语言
LangSmith / Langfuse	Python/TypeScript（SDK）/ Go（Langfuse 服务端）	APM 类工具，服务端 Go，客户端 Python

结论：可信输出治理层语言跟着公司技术栈走。如果是 Java 系企业，护栏、模板、审计和规则校验可以主要用 Java 写；如果是 AI 原生团队，事实校验、引文抽取和评测工具可能更多使用 Python。

11.5 各语言在 RICE 中的定位总结(个人知识局限，纯AI产出)

语言	统治领域	典型场景
Python	AI 模型推理、数据科学、原型快速验证	OCR、ASR、Embedding、Rerank、Pandas、Vanna、Guardrails
Java	企业级服务、规则引擎、大数据基建	Drools、Spring Boot 服务、Flink、ES、Neo4j、复杂业务中台
Go	网关、中间件、高并发代理	API Gateway、LLM Proxy（流控/路由）、向量库客户端代理
C++ / Rust	性能密集型底层	向量数据库内核（Milvus C++/Qdrant Rust）、QuantLib 核心、仿真求解器
Scala	大数据流处理	Flink 实时计算、Spark GraphX

11.6 实际企业里的常见分法(个人知识局限，纯AI产出)

团队类型	语言配比	原因
AI 原生创业公司	Python 70% + Go 20% + JavaScript 10%	全栈 Python，网关用 Go，前端用 JS
传统金融机构（银行/证券）	Java 60% + Python 30% + Go 10%	核心系统 Java，AI 模块外包成 Python 微服务，网关 Go
量化对冲基金	Python 50% + C++ 40% + Rust 10%	策略研究 Python，高频交易 C++/Rust
工业制造	MATLAB/C++ 50% + Python 40% + Java 10%	仿真和 PLC 对接 MATLAB，AI 视觉 Python

一句话总结

Python 负责"聪明"（模型+数据），Java 负责"可靠"（企业规则+服务），Go 负责"快"（网关+代理），C++/Rust 负责"硬"（底层性能）。

RICE 架构本质上是多语言异构系统，不是选一门语言通吃，而是按每层的性能、生态、团队能力做最优组合。

---

12. 补充：流式输出下的 Explanation / Governance 方式

大模型应用通常采用 SSE 或 WebSocket 做流式输出，但可信输出治理层不能简单理解成“模型输出完之后再做后处理”。在严肃业务里，模型可以流式生成，但系统不一定逐 token 透传给用户。更合理的做法是在模型和前端之间增加一层 Streaming Governance Proxy（流式治理代理）。

LLM Streaming
  ↓
Token Buffer
  ↓
Sentence / Paragraph / Section Segmenter
  ↓
Guardrails Checker
  ↓
Attribution Validator
  ↓
Fact Consistency Checker
  ↓
Template Renderer
  ↓
SSE / WebSocket Response

12.1 流式治理的三段式策略

阶段	主要能力	说明
生成前治理	Prompt 约束、资料编号、模板规划、风险分级	在生成前明确引用格式、禁止话术、输出结构和校验策略
生成中治理	分句/分段缓存、敏感表达检测、引用格式检查、结构检查	服务端先缓存一小段，校验通过后再释放给前端
生成后治理	全文事实一致性校验、引用完整性检查、审计落盘、必要时重生成	对最终答案做兜底校验，保留完整调用链

低风险场景可以短 buffer 后快速输出；高风险场景应按句子、段落或 section 校验后再输出；强合规场景可以牺牲部分流式体验，采用“完整生成 → 校验 → 模板渲染 → 输出”。

12.2 Attribution：流式输出下的引用溯源

Attribution 不适合逐 token 做，通常按句子、段落或 claim 做。

推荐做法：

1. 生成前给检索材料编号：例如 [DOC-1]、[DOC-2]，并在 Prompt 中要求模型输出关键事实时附带引用。
2. 生成中按句子或段落检查引用：服务端攒到一句话或一段话后，检查引用 ID 是否存在、引用是否和内容匹配。
3. 必要时延迟补引用：前端可以先展示正文，再补充脚注、气泡卡片或来源列表。

示例：

[DOC-1]
来源：2023 年年度报告，第 12 页
内容：公司 2023 年营收为 120 亿元，同比增长 8%。

模型输出：
公司 2023 年营收为 120 亿元，同比增长 8% [DOC-1]。

服务端在释放这句话前检查：

• 是否包含引用标记；
• 引用 ID 是否存在；
• 句子里的关键事实是否能被 [DOC-1] 支持；
• 是否存在引用张冠李戴。

12.3 Guardrails：流式输出中的护栏

Guardrails 应分为输入前、输出中、输出后三层。

类型	实现方式	说明
输入护栏	意图识别、风险分类、敏感请求拦截	用户请求本身违规时，不进入生成链路
输出中护栏	短窗口 buffer、敏感词/规则/分类器检测	检测最近若干 token、句子或段落，命中后暂停释放
输出后护栏	全文检测、审计、必要时撤回或修正	作为最终兜底，不替代生成中治理

输出中护栏的关键原则是：尽量不要让违规内容到达前端。

LLM token
  ↓
服务端 buffer
  ↓
敏感表达 / 合规规则检测
  ↓
通过后释放给前端

如果 buffer 中命中“保证收益”“稳赚不赔”“停药”“确诊”等高风险表达，服务端应丢弃当前 buffer，回到最近的安全检查点重新生成，而不是继续透传。

12.4 事实一致性校验：不要逐 token 校验

事实一致性校验通常需要上下文，不适合逐 token 做。常见粒度有四种：

粒度	适用场景	特点
Claim 级	指标、金额、日期、法规条款等关键事实	准确但实现复杂，需要抽取结构化事实
句子级	简单事实陈述	延迟较低，适合 RAG 问答
段落级	分析性、解释性内容	更稳，但等待时间更长
全文级	低风险场景或最终兜底	用户体验好，但可能已展示错误内容

高风险行业不建议只做全文级事后校验，因为用户可能已经看到错误内容。更推荐“句子/段落级缓存 + 校验通过后释放”。

12.5 模板化：先定结构，再流式填槽

流式输出下的模板化，不应依赖“模型自由写完后再套模板”，而应采用服务端固定模板，模型只填内容的方式。

例如金融投研模板：

【结论摘要】
{{summary}}

【核心依据】
{{evidence}}

【风险提示】
{{risk}}

【引用来源】
{{citations}}

【免责声明】
本内容仅供参考，不构成投资建议。

推荐实现：

1. 先生成结构计划，确定有哪些 section；
2. 每个 section 独立生成、独立校验；
3. 服务端负责标题、免责声明、固定合规话术等模板渲染；
4. 模型只生成 summary、evidence、risk 等槽位内容；
5. 某个 section 违规时，只重写该 section，不影响已通过的 section。

12.6 检测到敏感内容后如何重新生成

现有工程里一般不会告诉模型“从第 N 个 token 重新开始”。更常见的是：服务端维护安全检查点 safe checkpoint，检测到风险后，丢弃未放行内容，从最近一个安全语义边界重新生成。

安全检查点通常选择：

• 消息开始；
• 小节开始；
• 段落开始；
• 句子结束；
• 工具调用结果后；
• 引用校验通过后；
• 模板 slot 完成后。

示例：

{
  "checkpoints": [
    {"id": "cp_summary_done", "offset": 38, "desc": "结论摘要已通过校验"},
    {"id": "cp_risk_start", "offset": 45, "desc": "风险提示小节开始"}
  ]
}

当模型生成：

【风险提示】
这款产品可以保证收益，适合所有投资者。

服务端命中违规表达后：

1. 选择最近安全检查点，例如 cp_risk_start；
2. 丢弃当前未通过审核的 buffer；
3. 构造重写 Prompt，把安全前文、违规原因和重写要求发给模型；
4. 让模型从该 section 重新生成；
5. 重新经过护栏检查后再释放给前端。

重写 Prompt 示例：

以下内容已经安全输出，不要重复生成：
【结论摘要】
公司 2023 年营收保持增长，主要受益于主营业务扩张。[DOC-1]

现在请从【风险提示】小节继续生成。

上一版输出触发了合规规则：
- 违规片段：“可以保证收益”
- 违规原因：金融产品说明不得承诺保本、保收益或使用确定性收益表达。

要求：
1. 不得使用“保证收益”“稳赚不赔”“无风险”等表述；
2. 使用审慎、合规表达；
3. 明确说明投资存在风险；
4. 不要重复已经输出过的内容。

如果多次重试仍不通过，应降级为预设合规模板或升级人工审核。

12.7 前端如何配合修改展示

前端不应只接收纯文本流，最好接收带事件类型的流式协议。推荐事件类型：

start
append
checkpoint
truncate
replace
warning
done
error

正常追加：

{
  "type": "append",
  "messageId": "msg_001",
  "chunk": "公司 2023 年营收保持增长，"
}

注册检查点：

{
  "type": "checkpoint",
  "messageId": "msg_001",
  "checkpointId": "cp_summary_done",
  "offset": 38
}

回滚到检查点：

{
  "type": "truncate",
  "messageId": "msg_001",
  "checkpointId": "cp_summary_done",
  "reason": "guardrail_violation"
}

局部替换：

{
  "type": "replace",
  "messageId": "msg_001",
  "range": {"start": 80, "end": 120},
  "text": "投资存在不确定性，需结合自身风险承受能力审慎判断。"
}

如果服务端采用“先 buffer 校验，后释放”的方式，违规内容通常不会到达前端，前端就不需要执行回滚。只有在低风险或特殊交互场景中，才需要 truncate 或 replace。

12.8 四种流式输出治理模式

模式	流程	优点	缺点	适用场景
裸流式	LLM token → 用户	最快	几乎没有治理能力	娱乐、低风险聊天
短 buffer 流式	LLM token → 10~50 token buffer → 轻量检查 → 用户	延迟低，有基础安全检测	事实一致性能力弱	普通客服、轻量问答
句子/段落级治理流式	LLM token → 句子/段落 buffer → 护栏 + 引用校验 → 用户	兼顾体验和可信度	比裸流式慢	教育、金融、政务、企业知识库问答
先校验后输出	完整生成 → 全量校验 → 模板渲染 → 用户	最稳	基本没有真正流式体验	医疗、法律、审批、风控、高风险金融建议

12.9 核心原则

• 不要 token 级裸放行：高风险业务中，至少应做短 buffer 或句子级审核。
• 检查点使用语义边界：优先使用 section、paragraph、sentence、slot，而不是纯 token offset。
• 模板化场景按 section 生成：某个 section 违规时，只重写该 section。
• 多次违规后走兜底模板：不要无限重试模型。
• 前端支持可变流：除了 append，最好支持 checkpoint、truncate、replace、warning 等事件。
• 完整审计：记录原始 token 流、实际释放内容、拦截原因、引用材料、校验结果和重写次数。

一句话总结：

流式输出和 Explanation / Governance 不冲突。关键是不要把 LLM 的 token 流直接透传给用户，而是在中间加流式治理代理；按句子、段落或模板 section 缓冲，校验通过后再释放。