从 PoC 到生产：用 Amazon Bedrock 扩展医疗内容审核系统

预计阅读时间：10 分钟

Flo Health 的工程团队将 AWS 生成式 AI 创新中心交付的概念验证，推进为基于 Amazon Bedrock 的生产级医疗内容审核与生成系统。真正困难的部分并不是让大模型“读懂一篇文章”，而是把模型接入可追踪、可评估、可降级，并且始终保留医学专家最终决定权的工程流程。

PoC 能回答效果问题，生产系统要回答风险问题

概念验证通常关注几个直接问题：模型能否发现内容中的医学风险，能否给出修改建议，能否生成符合要求的初稿。这些结果可以证明方案值得继续投入，却不足以支撑真实的医疗内容工作流。

进入生产环境后，系统还需要处理另一组问题：

同一篇内容重复审核时，输出是否足够稳定；
模型、提示词或知识库升级后，审核标准是否发生漂移；
输入是否包含个人健康信息或其他敏感数据；
模型超时、限流或返回无效格式时，任务如何恢复；
医学编辑接受或拒绝了哪些建议，能否完整追溯；
自动生成的文本是否会被误当作已经获得医学批准的内容。

因此，生产化的关键不是简单增加一次 Bedrock API 调用，而是把生成式 AI 放进一个受约束的审核管道。模型负责筛查、归类和提出建议，医学专家负责确认事实、评估语境并作出最终发布决定。

把一次模型调用拆成可治理的审核任务

基于摘要中描述的技术方向，可以这样实践一套参考流程。以下架构是可改造的工程示例，并不表示 Flo Health 使用了完全相同的组件组合：

内容系统提交待审核文本，并附带语言、受众、内容类型和版本号。
预处理服务清除不必要的个人信息，对输入做长度和格式校验。
任务队列异步触发审核，避免编辑页面被长时间的模型调用阻塞。
Bedrock 返回结构化风险项，而不是无法稳定解析的自由文本。
后处理程序校验 JSON、风险等级和引用位置，并保存模型与提示词版本。
医学专家在审核界面中接受、修改或拒绝建议。
系统记录最终决策，用于质量评估，而不是未经筛选地直接回流训练。

这里有三个重要的边界。

结构化输出不是事实保证。 JSON Schema 可以约束字段，却不能证明医学结论正确。每一项高风险判断仍需专家复核。

引用位置必须可验证。 如果模型指出原文中的问题，应保存原始片段或字符区间。后处理程序需要确认该片段确实存在，避免界面展示模型虚构的引用。

生成与批准必须分离。 模型生成的初稿、模型审核后的版本和专家批准的版本，应拥有不同状态，不能依赖一个含义模糊的 completed 字段。

可以这样实践：调用 Bedrock 并校验结构化结果

下面是一个最小 Python 示例。它要求本机已经配置 AWS 凭证，并且当前区域和账号可以访问指定的 Bedrock 模型。运行前把 BEDROCK_MODEL_ID 改成账号中已启用、支持 Converse API 的模型 ID。

python -m venv .venv
source .venv/bin/activate
pip install boto3
export AWS_REGION=us-east-1
export BEDROCK_MODEL_ID='replace-with-an-enabled-model-id'

创建 review.py：

import json
import os
import sys

import boto3

region = os.getenv("AWS_REGION", "us-east-1")
model_id = os.environ["BEDROCK_MODEL_ID"]
client = boto3.client("bedrock-runtime", region_name=region)

SYSTEM_PROMPT = """You assist qualified medical reviewers.
Identify claims that require human review. Do not diagnose, prescribe, or mark
content as medically approved. Return JSON only, using this shape:
{
  "summary": "string",
  "findings": [
    {
      "severity": "low|medium|high",
      "quote": "exact text from the input",
      "reason": "string",
      "suggested_action": "string"
    }
  ]
}
If no issue is found, return an empty findings array.
"""

text = " ".join(sys.argv[1:]).strip()
if not text:
    raise SystemExit('Usage: python review.py "content to review"')

response = client.converse(
    modelId=model_id,
    system=[{"text": SYSTEM_PROMPT}],
    messages=[{"role": "user", "content": [{"text": text}]}],
    inferenceConfig={"temperature": 0, "maxTokens": 1200},
)

raw = response["output"]["message"]["content"][0]["text"]
result = json.loads(raw)

allowed_severities = {"low", "medium", "high"}
for finding in result.get("findings", []):
    if finding.get("severity") not in allowed_severities:
        raise ValueError("Unexpected severity")
    quote = finding.get("quote", "")
    if quote and quote not in text:
        raise ValueError(f"Model returned a quote absent from input: {quote!r}")

print(json.dumps(result, ensure_ascii=False, indent=2))

执行示例：

python review.py "This supplement permanently cures every hormonal disorder."

这段代码刻意不自动改写或发布内容。它只生成待人工处理的发现列表，并对严重级别和原文引用做最低限度的校验。生产环境还应使用正式的 Schema 校验库，对超时、限流和无效 JSON 设置重试与死信队列，并把原始响应保存到访问受控的审计存储中。

评估不能只看“回答得像不像专家”

医疗内容系统需要一组固定、经过专家标注的评估集。评估样本应覆盖不同语言、内容类型和风险等级，也应包含“没有问题”的文本，防止模型为了显得有用而过度报警。

可以重点跟踪以下指标：

高风险问题召回率：真正危险的陈述有多少被模型发现；
误报率：多少正常内容被不必要地送去返工；
专家接受率：建议被直接接受、修改后接受或拒绝的比例；
审核耗时：从任务创建到专家完成审核的时间；
无效输出率：JSON 解析失败、缺失字段或引用不存在的比例；
分组质量：不同语言、主题与受众之间是否存在明显性能差距。

每次更换模型、调整系统提示词、修改检索数据或改变推理参数，都应运行回归评估。发布时记录 model_id、提示词版本、评估集版本和阈值，才能在质量下降时定位原因并回滚。

上线前的工程检查表

采用这类系统时，可以用下面的清单控制风险：

明确哪些任务允许模型辅助，哪些内容必须完全由专家处理；
在调用模型前删除非必要的个人和健康敏感信息；
使用最小权限 IAM 策略，隔离开发、评估和生产环境；
为请求设置幂等键、超时、退避重试和并发上限；
保存内容版本、模型版本、提示词版本和人工决策记录；
对高风险发现强制人工复核，禁止模型直接触发发布；
准备模型不可用时的人工队列或规则审核降级路径；
持续监测成本、延迟、误报率和分组质量，而不只统计调用成功率。

从 PoC 走向生产，意味着团队的关注点从“模型能否完成任务”转向“整个系统能否在出错时保持可控”。Amazon Bedrock 提供了模型访问层，但医疗内容质量仍取决于数据边界、结构化验证、持续评估、审计记录和专家审核共同组成的工程闭环。