1. 项目概述当AI遇上体检报告一场“幻觉”与“重试”的硬仗最近在做一个挺有意思的项目用大模型来解读体检报告。听起来是不是挺酷理想很丰满用户上传一份PDF或图片格式的体检报告AI就能像资深医生一样快速提炼出关键异常指标、给出健康风险提示甚至生成一份通俗易懂的解读摘要。这玩意儿要是做好了能极大提升健康管理的效率和体验。但现实嘛总是骨感的。从原型验证到工程落地我们团队踩的坑简直比体检报告上的异常箭头还多。其中最核心、最磨人的两个问题就是“AI幻觉”和“重试机制”。这俩词儿一个关乎结果的准确性AI会不会胡说八道一个关乎系统的稳定性服务挂了怎么办任何一个处理不好项目就得黄。所以今天我想抛开那些高大上的概念就从一个一线工程师的视角复盘我们是怎么跟“AI幻觉”和“重试”这两个工程大坑死磕的。这里面没有银弹只有一次次调试、优化、甚至推翻重来的实战经验。如果你也在做类似的AI应用尤其是涉及严肃、结构化数据如医疗、金融、法律文书处理的场景那这篇踩坑实录或许能帮你省下不少折腾的时间。2. 核心挑战拆解为什么体检报告是AI的“试金石”在深入工程细节之前我们得先搞清楚处理体检报告这件事到底难在哪里。这决定了我们后续所有技术方案的设计方向。2.1 数据源的复杂性与非标准化体检报告可不是规规矩矩的JSON或CSV。它的数据来源五花八门格式混杂用户上传的可能是扫描的PDF、手机拍的JPG/PNG图片、甚至是从医院系统导出的结构化PDF。每种格式的解析难度天差地别。版式千奇百怪不同体检机构、不同年份的报告模板完全不同。表格可能横着排、竖着排关键信息如姓名、年龄、异常指标在页面上的位置毫无规律可言。专业术语与缩写报告里充满了“ALT”、“Cr”、“LDL-C”等医学缩写以及“未见明显异常”、“建议随访”等模糊描述。AI需要准确理解这些术语的真实含义。注意我们最初天真地以为用OCR光学字符识别把文字提取出来就万事大吉了。结果发现单纯的文字识别会丢失大量的版面结构信息。比如一个指标“血糖 5.6 mmol/L”和参考范围“3.9-6.1”在报告上是上下行或左右列的关系OCR后可能变成两段毫无关联的文字AI根本无法判断5.6是正常还是异常。2.2 AI幻觉在严肃场景下的致命风险“AI幻觉”指的是大模型生成的内容看似合理实则与输入信息不符或凭空捏造。在闲聊场景下这可能无伤大雅但在体检报告解读中这是绝对的红线。错误类型1指标数值篡改用户报告上明明是“血糖 5.6正常”AI总结时可能说成“血糖 7.8偏高建议复查”。这种错误是灾难性的。错误类型2无中生有的异常报告上所有指标都正常AI却总结出“发现肝功能轻度异常”引发用户不必要的恐慌。错误类型3解读建议过度泛化或错误将“轻度脂肪肝”的建议错误地关联成“需要立即药物治疗”而不是“建议调整饮食、加强运动”。幻觉的产生根源复杂可能源于训练数据偏见、提示词Prompt设计不当、上下文长度限制导致关键信息丢失或者模型本身在推理时的“自信编造”。2.3 服务链路的脆弱性与重试的必要性一个完整的体检报告AI解读链路远不止调用一次大模型API那么简单。它通常是一个微服务管道Pipeline用户上传 - 文件预处理 - OCR/格式解析 - 信息结构化 - 调用大模型API - 后处理与格式化 - 返回结果这个链路上任何一个环节都可能失败第三方服务不稳定大模型API如GPT-4、Claude、国内各类大模型平台可能有速率限制、临时故障、响应超时。网络波动特别是处理图片或PDF上传时网络延迟或中断会导致整个流程卡住。资源耗尽解析复杂PDF时内存溢出或并发请求过高导致服务崩溃。如果没有健全的重试机制一次偶然的API抖动就会导致用户请求失败体验极差。但重试不是简单的“失败就再调一次”里面涉及退避策略、幂等性、故障隔离等一系列工程问题。3. 对抗AI幻觉一套组合拳式的工程实践对抗幻觉我们没有寻找“一招制敌”的魔法而是搭建了一套从数据输入到结果输出的多层防御体系。3.1 第一道防线提升信息提取的准确性预处理与结构化目标是给大模型喂最干净、最结构化的“食材”减少它因“看错”而“说错”的可能。3.1.1 基于视觉的文档理解VDU替代传统OCR我们放弃了纯文本OCR方案转向了像Azure Document Intelligence、Google Document AI或开源方案PaddleOCR结合版面分析这类VDU服务。它们不仅能识别文字还能理解文档的版面结构将文字按区块、表格、键值对Key-Value Pair进行组织。实操示例对于“血糖5.6 mmol/L”和参考范围“3.9-6.1”VDU可以识别出这是一个“键值对”结构甚至能将其归类到“生化检验”表格中。这样我们传递给大模型的就不是两段孤立的文本而是一个结构体{“指标”: “血糖”, “测量值”: “5.6”, “单位”: “mmol/L”, “参考范围”: “3.9-6.1”}。工具选型心得商业API如Azure准确率高、省心但成本敏感。开源方案PaddleOCR需要投入更多精力做后期处理和模型微调但可控性强。我们初期用商业API快速验证后期对核心表格如血常规、生化全项用微调的开源模型进行补充做混合部署。3.1.2 建立医学知识库与标准化映射我们从公开的医学指南、教科书和合作的医疗机构中整理了一个本地的医学知识库包含标准指标名称与别名映射表例如“谷丙转氨酶” “ALT” “GPT”。指标参考范围库根据不同年龄、性别进行区分。当报告本身参考范围缺失或模糊时可以用知识库的默认值作为补充参考。异常等级与建议知识库定义好“轻度偏离”、“中度偏离”、“重度偏离”的数值区间以及对应的标准建议话术如“建议清淡饮食”、“建议专科就诊”。这个知识库有两个作用一是在预处理阶段帮助清洗和标准化从报告中提取的原始数据二是在后处理阶段用于校验大模型输出的合理性。3.2 第二道防线精心设计提示词Prompt Engineering提示词是与大模型对话的“剧本”设计好坏直接决定输出质量。3.2.1 结构化输入与角色设定我们不会把一整页OCR文本扔给模型。而是先将报告信息整理成清晰的JSON结构然后在Prompt中明确AI的角色和任务。{ “patient_info”: {“name”: “张三”, “age”: 35, “gender”: “男”}, “exam_items”: [ {“item_name”: “血糖”, “result”: “5.6”, “unit”: “mmol/L”, “ref_range”: “3.9-6.1”, “flag”: “”}, {“item_name”: “总胆固醇”, “result”: “6.2”, “unit”: “mmol/L”, “ref_range”: “5.2”, “flag”: “H”} ] }对应的Prompt会这样写你是一名专业的体检报告解读助手。请基于以下结构化的体检数据生成一份面向用户的解读报告。 【用户数据】 上面那个JSON 【你的任务】 1. **提炼关键异常**仅列出明确超出参考范围的指标并说明偏离程度如轻度、中度。 2. **生成解读摘要**用通俗易懂的语言总结整体健康状况。对于异常指标解释其可能的常见原因非诊断例如“总胆固醇偏高可能与饮食、缺乏运动有关”。 3. **给出行动建议**提供普适性的、非医疗干预的行动建议如“建议低脂饮食增加燕麦、深海鱼摄入并保持每周150分钟中等强度运动”。 4. **严格遵循规则** - **禁止编造**如果数据中没有的异常绝对不要提及。 - **禁止诊断**不能说“你患有XX病”只能说“该指标异常需关注”。 - **引用数据**提及指标时必须带上其具体数值和参考范围例如“您的总胆固醇为6.2 mmol/L参考值5.2”。 - **不确定时**如果对某些专业术语不确定请明确标注“此部分建议咨询专业医生”。 请以JSON格式输出包含字段key_abnormalities数组 summary字符串 recommendations数组。为什么这样设计结构化输入减少了模型解析的负担明确的角色和规则限制了其“自由发挥”的空间要求输出特定JSON格式便于我们程序化校验和后处理。3.2.2 少样本学习Few-Shot Learning在Prompt中我们会提供1-2个高质量的输入输出示例。这能极大地“校准”模型的行为让它更准确地理解我们想要的格式、语气和边界。示例1 输入一个包含正常和轻度异常血脂的结构化数据 输出{“key_abnormalities”: [{“item”: “低密度脂蛋白胆固醇”, “result”: “3.8”, “note”: “轻度升高”}], “summary”: “您的体检报告总体良好主要需关注血脂情况...” “recommendations”: [“调整饮食结构减少饱和脂肪摄入...“]}模型看过几个例子后生成类似风格和严谨程度内容的概率会大大增加。3.3 第三道防线结果的后处理与校验即使提示词写得再好也不能100%信任模型的原始输出。必须设置“质检岗”。3.3.1 规则校验编写一系列规则对输出JSON进行自动校验数值一致性校验检查AI提到的异常指标和数值是否与输入数据完全一致。比如AI说“血糖 7.8偏高”但输入数据里血糖是5.6则触发告警本次结果标记为不可信。范围校验检查AI给出的“轻度/中度”偏离判断是否与我们知识库中定义的数值区间逻辑相符。禁忌词过滤检查输出文本中是否包含“确诊”、“治疗”、“药物”、“保证治愈”等绝对禁止的医疗术语。3.3.2 基于知识库的二次验证对于AI指出的关键异常可以用本地知识库进行快速比对。例如AI说“尿酸520 umol/L属于中度升高”知识库规则如果定义“540为中度”则系统会记录一个轻微的不匹配日志供人工复核参考不一定直接驳回因为临床判断可能有弹性。3.3.3 置信度评分与人工兜底我们设计了一个简单的置信度评分机制高置信度AI输出格式正确、通过所有规则校验、且异常指标少3个。结果直接返回给用户。中置信度通过校验但异常指标多或涉及重要指标如肿瘤标志物。结果返回但附带醒目提示“解读仅供参考请务必结合临床医生意见”。低置信度任何规则校验失败或模型输出格式混乱。触发人工兜底流程请求进入人工审核队列同时系统通知用户“报告较为复杂解读需要更多时间例如24小时内”。这套组合拳下来我们将核心的“事实性幻觉”篡改数据、无中生有发生率降到了可接受的水平通过抽样评估低于1%。但工程上的挑战才完成了一半。4. 构建健壮的重试机制不仅仅是“再试一次”服务不稳定是常态。一个健壮的重试机制目标不是追求100%成功而是优雅地降级并防止局部故障引发雪崩。4.1 重试策略设计指数退避与抖动最朴素的重试是“立即重试”但这在第三方服务临时过载时会加剧对方压力也浪费自己的资源。4.1.1 指数退避我们为调用大模型API等关键外部服务实现了指数退避重试。例如第一次失败后等待1秒重试第二次失败等待2秒第三次等待4秒以此类推直到达到最大重试次数如3次。import time import random def call_llm_api_with_retry(prompt, max_retries3): for attempt in range(max_retries): try: response llm_client.complete(prompt) return response except (TimeoutError, ServiceUnavailableError) as e: if attempt max_retries - 1: raise # 重试耗尽向上抛出异常 wait_time (2 ** attempt) random.uniform(0, 0.1) # 指数退避抖动 time.sleep(wait_time) logger.warning(f”LLM API调用失败第{attempt1}次重试等待{wait_time:.2f}秒“) # 所有重试失败后的降级处理 return get_fallback_response()为什么是指数退避给服务提供恢复的时间。如果是因为瞬时高负载导致的失败等待时间逐次加倍可以避免在服务恢复过程中继续“狂轰滥炸”。4.1.2 抖动注意上面代码中的random.uniform(0, 0.1)这就是“抖动”。如果多个客户端实例同时失败、同时重试没有抖动的话它们会在1秒、2秒、4秒后同时再次发起请求形成“重试风暴”导致服务端再次被冲垮。加入一个随机的小延迟可以打散这些重试请求避免同步效应。4.2 分级重试与熔断降级不是所有失败都值得重试也不是所有服务都可以无限重试。4.2.1 错误类型分级可重试错误网络超时、连接断开、5xx服务器内部错误。这些通常是暂时的适合重试。不可重试错误4xx客户端错误如无效的API Key、请求格式错误、业务逻辑错误如内容被过滤。这些错误重试多少次都不会成功应立即失败并返回明确的错误信息给用户。4.2.2 熔断器模式我们为每个关键外部服务如OCR服务、大模型API设置了一个熔断器。当失败率超过某个阈值如50%熔断器会“跳闸”在接下来的一段时间内如30秒所有对该服务的请求会立即失败不再真正发起调用。好处1. 快速失败节省资源和时间2. 给下游服务喘息的机会3. 防止因一个服务挂掉导致线程池被占满拖垮整个应用。恢复经过一个休眠期后熔断器会进入“半开”状态允许少量请求通过以测试服务是否恢复。如果成功则关闭熔断器如果仍然失败则继续开启。4.2.3 服务降级当重试耗尽或熔断器开启时不能直接给用户返回一个冷冰冰的“服务错误”。必须有降级方案。对于大模型解读服务降级返回一个预先准备好的通用模板如“系统正在优化解读服务暂为您展示报告原始数据”并将结构化的体检数据表格清晰展示给用户。这比什么都没有要好。对于OCR服务降级如果高级VDU服务失败可以降级到基础的Tesseract OCR虽然效果差些但至少能提取出部分文字信息。4.3 幂等性与状态管理在分布式和重试环境下同一个用户请求可能因为超时重试而被处理多次。必须保证服务的幂等性即同一操作执行多次的结果与执行一次相同。我们的做法生成唯一请求ID用户每次提交报告前端生成一个唯一的request_id并随请求体一起发送。后端幂等检查在处理请求前先以request_id为键检查Redis或数据库中是否已存在处理中的状态或已完成的结果。如果存在已完成结果直接返回该结果。如果存在处理中状态则根据业务决定是返回“处理中”状态还是等待前一个请求完成通过轮询或WebSocket。如果不存在则开始处理并将状态置为“处理中”。关键操作幂等像“保存解读结果到数据库”这样的操作使用INSERT ... ON DUPLICATE KEY UPDATE或类似机制确保同一request_id的结果只保存一份。这套机制保证了即使用户因网络问题多次点击提交或者后端因超时重试最终也只会生成一份解读报告避免重复扣费、重复生成内容等问题。5. 监控、告警与迭代让系统在运行中自我完善工程系统不是一劳永逸的尤其是AI系统其表现会随着数据分布的变化而波动。必须建立完善的监控体系。5.1 核心监控指标我们在系统各个关键点埋设了指标服务健康度各环节上传、解析、AI调用、生成的请求量、成功率、延迟P50, P95, P99。AI质量指标幻觉触发率规则校验失败的请求比例。人工复核率低置信度结果触发人工复核的比例。用户反馈提供“解读是否有帮助”的反馈按钮收集正面/负面比例。成本指标每次请求消耗的Token数、OCR页数折算成API调用成本。5.2 日志与追踪每个request_id贯穿整个处理链路所有的日志、错误信息都关联到这个ID。当用户反馈“解读不对”时我们可以通过request_id快速定位到当时的原始报告、提取的结构化数据、发送给AI的Prompt、AI的原始输出、以及校验日志从而精准复现问题判断是数据提取错误、Prompt问题还是模型本身幻觉。5.3 A/B测试与Prompt迭代对抗幻觉和优化体验是一个持续过程。我们建立了简单的A/B测试框架。新Prompt上线不会全量推送。例如我们优化了关于“结节”描述的Prompt希望它更谨慎。我们会让5%的流量走新PromptB组95%走旧PromptA组。评估对比两组的“幻觉触发率”、“人工复核率”和“用户好评率”。如果B组在质量指标上显著优于A组且成本没有大幅增加再逐步放大流量直至全量替换。数据驱动迭代定期分析人工复核队列里的案例找出高频的幻觉模式或难处理的报告类型反过来指导我们优化预处理规则、知识库和Prompt设计。6. 踩坑心得与避坑指南回顾整个项目有几个“坑”是当时没想到事后看来至关重要的。6.1 不要试图用AI解决所有问题早期我们幻想用一个超级Prompt让AI直接从原始PDF图片中解读报告。结果惨不忍睹。后来才明白好的AI应用是“硅基智能”程序规则和“碳基智能”大模型的有机结合。能用规则正则表达式、查找表、决策树稳定处理的部分坚决不用AI。AI只用来处理需要灵活性、语义理解和生成自然语言的部分。我们的流水线中数据清洗、标准化、校验都是规则只有最后的“综合解读与摘要生成”用了大模型。6.2 成本控制要前置考虑大模型API和高级OCR服务都是按量计费成本可能指数级增长。必须在设计初期就考虑缓存对常见、标准的报告模板其解析后的结构化数据可以缓存。同一用户短时间内重复查询同一份报告直接读缓存。异步处理与队列解读报告不是实时聊天允许有延迟如30秒内。采用消息队列进行异步处理可以平滑请求峰值避免为应对洪峰而过度配置资源。模型选型不是所有任务都需要GPT-4。对于简单的信息提取和格式化性能足够的低成本小模型或专用模型可能是更好选择。我们后来就将一部分任务迁移到了更经济的模型上。6.3 法律与伦理合规是生命线处理健康数据安全与合规是重中之重。所有用户数据必须加密传输和存储严格遵循数据最小化原则解读结果必须包含免责声明并且我们设置了严格的内部审计日志确保数据可追溯。在Prompt设计上反复强调“禁止诊断”、“仅供参考”的边界这不仅是保护用户也是保护我们自己。6.4 拥抱不确定性设计容错系统AI服务本质上是非确定性的。与其追求100%的准确不可能不如坦诚地告知用户系统的局限性。我们的产品界面明确写着“AI解读基于通用医学知识不能替代专业医疗诊断”。在系统设计上为“不确定性”留出通道——即人工复核流程。这反而增加了用户的信任感。从AI幻觉到重试这两个坑本质上考验的是我们如何将一个充满不确定性的智能能力封装成一个稳定、可靠、可信的产品功能。这中间没有魔法靠的是扎实的工程化思维分层处理、防御性设计、持续监控和快速迭代。这个过程虽然痛苦但当看到用户因为清晰的解读而缓解焦虑或根据建议开始改善生活习惯时就觉得这些坑踩得值了。AI工程化的路还很长这些经验希望能成为你路上的一块垫脚石。 1. 项目概述当AI遇上体检报告一场“幻觉”与“重试”的硬仗最近在做一个挺有意思的项目用大模型来解读体检报告。听起来是不是挺酷理想很丰满用户上传一份PDF或图片格式的体检报告AI就能像资深医生一样快速提炼出关键异常指标、给出健康风险提示甚至生成一份通俗易懂的解读摘要。这玩意儿要是做好了能极大提升健康管理的效率和体验。但现实嘛总是骨感的。从原型验证到工程落地我们团队踩的坑简直比体检报告上的异常箭头还多。其中最核心、最磨人的两个问题就是“AI幻觉”和“重试机制”。这俩词儿一个关乎结果的准确性AI会不会胡说八道一个关乎系统的稳定性服务挂了怎么办任何一个处理不好项目就得黄。所以今天我想抛开那些高大上的概念就从一个一线工程师的视角复盘我们是怎么跟“AI幻觉”和“重试”这两个工程大坑死磕的。这里面没有银弹只有一次次调试、优化、甚至推翻重来的实战经验。如果你也在做类似的AI应用尤其是涉及严肃、结构化数据如医疗、金融、法律文书处理的场景那这篇踩坑实录或许能帮你省下不少折腾的时间。2. 核心挑战拆解为什么体检报告是AI的“试金石”在深入工程细节之前我们得先搞清楚处理体检报告这件事到底难在哪里。这决定了我们后续所有技术方案的设计方向。2.1 数据源的复杂性与非标准化体检报告可不是规规矩矩的JSON或CSV。它的数据来源五花八门格式混杂用户上传的可能是扫描的PDF、手机拍的JPG/PNG图片、甚至是从医院系统导出的结构化PDF。每种格式的解析难度天差地别。版式千奇百怪不同体检机构、不同年份的报告模板完全不同。表格可能横着排、竖着排关键信息如姓名、年龄、异常指标在页面上的位置毫无规律可言。专业术语与缩写报告里充满了“ALT”、“Cr”、“LDL-C”等医学缩写以及“未见明显异常”、“建议随访”等模糊描述。AI需要准确理解这些术语的真实含义。注意我们最初天真地以为用OCR光学字符识别把文字提取出来就万事大吉了。结果发现单纯的文字识别会丢失大量的版面结构信息。比如一个指标“血糖 5.6 mmol/L”和参考范围“3.9-6.1”在报告上是上下行或左右列的关系OCR后可能变成两段毫无关联的文字AI根本无法判断5.6是正常还是异常。2.2 AI幻觉在严肃场景下的致命风险“AI幻觉”指的是大模型生成的内容看似合理实则与输入信息不符或凭空捏造。在闲聊场景下这可能无伤大雅但在体检报告解读中这是绝对的红线。错误类型1指标数值篡改用户报告上明明是“血糖 5.6正常”AI总结时可能说成“血糖 7.8偏高建议复查”。这种错误是灾难性的。错误类型2无中生有的异常报告上所有指标都正常AI却总结出“发现肝功能轻度异常”引发用户不必要的恐慌。错误类型3解读建议过度泛化或错误将“轻度脂肪肝”的建议错误地关联成“需要立即药物治疗”而不是“建议调整饮食、加强运动”。幻觉的产生根源复杂可能源于训练数据偏见、提示词Prompt设计不当、上下文长度限制导致关键信息丢失或者模型本身在推理时的“自信编造”。2.3 服务链路的脆弱性与重试的必要性一个完整的体检报告AI解读链路远不止调用一次大模型API那么简单。它通常是一个微服务管道Pipeline用户上传 - 文件预处理 - OCR/格式解析 - 信息结构化 - 调用大模型API - 后处理与格式化 - 返回结果这个链路上任何一个环节都可能失败第三方服务不稳定大模型API如GPT-4、Claude、国内各类大模型平台可能有速率限制、临时故障、响应超时。网络波动特别是处理图片或PDF上传时网络延迟或中断会导致整个流程卡住。资源耗尽解析复杂PDF时内存溢出或并发请求过高导致服务崩溃。如果没有健全的重试机制一次偶然的API抖动就会导致用户请求失败体验极差。但重试不是简单的“失败就再调一次”里面涉及退避策略、幂等性、故障隔离等一系列工程问题。3. 对抗AI幻觉一套组合拳式的工程实践对抗幻觉我们没有寻找“一招制敌”的魔法而是搭建了一套从数据输入到结果输出的多层防御体系。3.1 第一道防线提升信息提取的准确性预处理与结构化目标是给大模型喂最干净、最结构化的“食材”减少它因“看错”而“说错”的可能。3.1.1 基于视觉的文档理解VDU替代传统OCR我们放弃了纯文本OCR方案转向了像Azure Document Intelligence、Google Document AI或开源方案PaddleOCR结合版面分析这类VDU服务。它们不仅能识别文字还能理解文档的版面结构将文字按区块、表格、键值对Key-Value Pair进行组织。实操示例对于“血糖5.6 mmol/L”和参考范围“3.9-6.1”VDU可以识别出这是一个“键值对”结构甚至能将其归类到“生化检验”表格中。这样我们传递给大模型的就不是两段孤立的文本而是一个结构体{“指标”: “血糖”, “测量值”: “5.6”, “单位”: “mmol/L”, “参考范围”: “3.9-6.1”}。工具选型心得商业API如Azure准确率高、省心但成本敏感。开源方案PaddleOCR需要投入更多精力做后期处理和模型微调但可控性强。我们初期用商业API快速验证后期对核心表格如血常规、生化全项用微调的开源模型进行补充做混合部署。3.1.2 建立医学知识库与标准化映射我们从公开的医学指南、教科书和合作的医疗机构中整理了一个本地的医学知识库包含标准指标名称与别名映射表例如“谷丙转氨酶” “ALT” “GPT”。指标参考范围库根据不同年龄、性别进行区分。当报告本身参考范围缺失或模糊时可以用知识库的默认值作为补充参考。异常等级与建议知识库定义好“轻度偏离”、“中度偏离”、“重度偏离”的数值区间以及对应的标准建议话术如“建议清淡饮食”、“建议专科就诊”。这个知识库有两个作用一是在预处理阶段帮助清洗和标准化从报告中提取的原始数据二是在后处理阶段用于校验大模型输出的合理性。3.2 第二道防线精心设计提示词Prompt Engineering提示词是与大模型对话的“剧本”设计好坏直接决定输出质量。3.2.1 结构化输入与角色设定我们不会把一整页OCR文本扔给模型。而是先将报告信息整理成清晰的JSON结构然后在Prompt中明确AI的角色和任务。{ “patient_info”: {“name”: “张三”, “age”: 35, “gender”: “男”}, “exam_items”: [ {“item_name”: “血糖”, “result”: “5.6”, “unit”: “mmol/L”, “ref_range”: “3.9-6.1”, “flag”: “”}, {“item_name”: “总胆固醇”, “result”: “6.2”, “unit”: “mmol/L”, “ref_range”: “5.2”, “flag”: “H”} ] }对应的Prompt会这样写你是一名专业的体检报告解读助手。请基于以下结构化的体检数据生成一份面向用户的解读报告。 【用户数据】 上面那个JSON 【你的任务】 1. **提炼关键异常**仅列出明确超出参考范围的指标并说明偏离程度如轻度、中度。 2. **生成解读摘要**用通俗易懂的语言总结整体健康状况。对于异常指标解释其可能的常见原因非诊断例如“总胆固醇偏高可能与饮食、缺乏运动有关”。 3. **给出行动建议**提供普适性的、非医疗干预的行动建议如“建议低脂饮食增加燕麦、深海鱼摄入并保持每周150分钟中等强度运动”。 4. **严格遵循规则** - **禁止编造**如果数据中没有的异常绝对不要提及。 - **禁止诊断**不能说“你患有XX病”只能说“该指标异常需关注”。 - **引用数据**提及指标时必须带上其具体数值和参考范围例如“您的总胆固醇为6.2 mmol/L参考值5.2”。 - **不确定时**如果对某些专业术语不确定请明确标注“此部分建议咨询专业医生”。 请以JSON格式输出包含字段key_abnormalities数组 summary字符串 recommendations数组。为什么这样设计结构化输入减少了模型解析的负担明确的角色和规则限制了其“自由发挥”的空间要求输出特定JSON格式便于我们程序化校验和后处理。3.2.2 少样本学习Few-Shot Learning在Prompt中我们会提供1-2个高质量的输入输出示例。这能极大地“校准”模型的行为让它更准确地理解我们想要的格式、语气和边界。示例1 输入一个包含正常和轻度异常血脂的结构化数据 输出{“key_abnormalities”: [{“item”: “低密度脂蛋白胆固醇”, “result”: “3.8”, “note”: “轻度升高”}], “summary”: “您的体检报告总体良好主要需关注血脂情况...” “recommendations”: [“调整饮食结构减少饱和脂肪摄入...“]}模型看过几个例子后生成类似风格和严谨程度内容的概率会大大增加。3.3 第三道防线结果的后处理与校验即使提示词写得再好也不能100%信任模型的原始输出。必须设置“质检岗”。3.3.1 规则校验编写一系列规则对输出JSON进行自动校验数值一致性校验检查AI提到的异常指标和数值是否与输入数据完全一致。比如AI说“血糖 7.8偏高”但输入数据里血糖是5.6则触发告警本次结果标记为不可信。范围校验检查AI给出的“轻度/中度”偏离判断是否与我们知识库中定义的数值区间逻辑相符。禁忌词过滤检查输出文本中是否包含“确诊”、“治疗”、“药物”、“保证治愈”等绝对禁止的医疗术语。3.3.2 基于知识库的二次验证对于AI指出的关键异常可以用本地知识库进行快速比对。例如AI说“尿酸520 umol/L属于中度升高”知识库规则如果定义“540为中度”则系统会记录一个轻微的不匹配日志供人工复核参考不一定直接驳回因为临床判断可能有弹性。3.3.3 置信度评分与人工兜底我们设计了一个简单的置信度评分机制高置信度AI输出格式正确、通过所有规则校验、且异常指标少3个。结果直接返回给用户。中置信度通过校验但异常指标多或涉及重要指标如肿瘤标志物。结果返回但附带醒目提示“解读仅供参考请务必结合临床医生意见”。低置信度任何规则校验失败或模型输出格式混乱。触发人工兜底流程请求进入人工审核队列同时系统通知用户“报告较为复杂解读需要更多时间例如24小时内”。这套组合拳下来我们将核心的“事实性幻觉”篡改数据、无中生有发生率降到了可接受的水平通过抽样评估低于1%。但工程上的挑战才完成了一半。4. 构建健壮的重试机制不仅仅是“再试一次”服务不稳定是常态。一个健壮的重试机制目标不是追求100%成功而是优雅地降级并防止局部故障引发雪崩。4.1 重试策略设计指数退避与抖动最朴素的重试是“立即重试”但这在第三方服务临时过载时会加剧对方压力也浪费自己的资源。4.1.1 指数退避我们为调用大模型API等关键外部服务实现了指数退避重试。例如第一次失败后等待1秒重试第二次失败等待2秒第三次等待4秒以此类推直到达到最大重试次数如3次。import time import random def call_llm_api_with_retry(prompt, max_retries3): for attempt in range(max_retries): try: response llm_client.complete(prompt) return response except (TimeoutError, ServiceUnavailableError) as e: if attempt max_retries - 1: raise # 重试耗尽向上抛出异常 wait_time (2 ** attempt) random.uniform(0, 0.1) # 指数退避抖动 time.sleep(wait_time) logger.warning(f”LLM API调用失败第{attempt1}次重试等待{wait_time:.2f}秒“) # 所有重试失败后的降级处理 return get_fallback_response()为什么是指数退避给服务提供恢复的时间。如果是因为瞬时高负载导致的失败等待时间逐次加倍可以避免在服务恢复过程中继续“狂轰滥炸”。4.1.2 抖动注意上面代码中的random.uniform(0, 0.1)这就是“抖动”。如果多个客户端实例同时失败、同时重试没有抖动的话它们会在1秒、2秒、4秒后同时再次发起请求形成“重试风暴”导致服务端再次被冲垮。加入一个随机的小延迟可以打散这些重试请求避免同步效应。4.2 分级重试与熔断降级不是所有失败都值得重试也不是所有服务都可以无限重试。4.2.1 错误类型分级可重试错误网络超时、连接断开、5xx服务器内部错误。这些通常是暂时的适合重试。不可重试错误4xx客户端错误如无效的API Key、请求格式错误、业务逻辑错误如内容被过滤。这些错误重试多少次都不会成功应立即失败并返回明确的错误信息给用户。4.2.2 熔断器模式我们为每个关键外部服务如OCR服务、大模型API设置了一个熔断器。当失败率超过某个阈值如50%熔断器会“跳闸”在接下来的一段时间内如30秒所有对该服务的请求会立即失败不再真正发起调用。好处1. 快速失败节省资源和时间2. 给下游服务喘息的机会3. 防止因一个服务挂掉导致线程池被占满拖垮整个应用。恢复经过一个休眠期后熔断器会进入“半开”状态允许少量请求通过以测试服务是否恢复。如果成功则关闭熔断器如果仍然失败则继续开启。4.2.3 服务降级当重试耗尽或熔断器开启时不能直接给用户返回一个冷冰冰的“服务错误”。必须有降级方案。对于大模型解读服务降级返回一个预先准备好的通用模板如“系统正在优化解读服务暂为您展示报告原始数据”并将结构化的体检数据表格清晰展示给用户。这比什么都没有要好。对于OCR服务降级如果高级VDU服务失败可以降级到基础的Tesseract OCR虽然效果差些但至少能提取出部分文字信息。4.3 幂等性与状态管理在分布式和重试环境下同一个用户请求可能因为超时重试而被处理多次。必须保证服务的幂等性即同一操作执行多次的结果与执行一次相同。我们的做法生成唯一请求ID用户每次提交报告前端生成一个唯一的request_id并随请求体一起发送。后端幂等检查在处理请求前先以request_id为键检查Redis或数据库中是否已存在处理中的状态或已完成的结果。如果存在已完成结果直接返回该结果。如果存在处理中状态则根据业务决定是返回“处理中”状态还是等待前一个请求完成通过轮询或WebSocket。如果不存在则开始处理并将状态置为“处理中”。关键操作幂等像“保存解读结果到数据库”这样的操作使用INSERT ... ON DUPLICATE KEY UPDATE或类似机制确保同一request_id的结果只保存一份。这套机制保证了即使用户因网络问题多次点击提交或者后端因超时重试最终也只会生成一份解读报告避免重复扣费、重复生成内容等问题。5. 监控、告警与迭代让系统在运行中自我完善工程系统不是一劳永逸的尤其是AI系统其表现会随着数据分布的变化而波动。必须建立完善的监控体系。5.1 核心监控指标我们在系统各个关键点埋设了指标服务健康度各环节上传、解析、AI调用、生成的请求量、成功率、延迟P50, P95, P99。AI质量指标幻觉触发率规则校验失败的请求比例。人工复核率低置信度结果触发人工复核的比例。用户反馈提供“解读是否有帮助”的反馈按钮收集正面/负面比例。成本指标每次请求消耗的Token数、OCR页数折算成API调用成本。5.2 日志与追踪每个request_id贯穿整个处理链路所有的日志、错误信息都关联到这个ID。当用户反馈“解读不对”时我们可以通过request_id快速定位到当时的原始报告、提取的结构化数据、发送给AI的Prompt、AI的原始输出、以及校验日志从而精准复现问题判断是数据提取错误、Prompt问题还是模型本身幻觉。5.3 A/B测试与Prompt迭代对抗幻觉和优化体验是一个持续过程。我们建立了简单的A/B测试框架。新Prompt上线不会全量推送。例如我们优化了关于“结节”描述的Prompt希望它更谨慎。我们会让5%的流量走新PromptB组95%走旧PromptA组。评估对比两组的“幻觉触发率”、“人工复核率”和“用户好评率”。如果B组在质量指标上显著优于A组且成本没有大幅增加再逐步放大流量直至全量替换。数据驱动迭代定期分析人工复核队列里的案例找出高频的幻觉模式或难处理的报告类型反过来指导我们优化预处理规则、知识库和Prompt设计。6. 踩坑心得与避坑指南回顾整个项目有几个“坑”是当时没想到事后看来至关重要的。6.1 不要试图用AI解决所有问题早期我们幻想用一个超级Prompt让AI直接从原始PDF图片中解读报告。结果惨不忍睹。后来才明白好的AI应用是“硅基智能”程序规则和“碳基智能”大模型的有机结合。能用规则正则表达式、查找表、决策树稳定处理的部分坚决不用AI。AI只用来处理需要灵活性、语义理解和生成自然语言的部分。我们的流水线中数据清洗、标准化、校验都是规则只有最后的“综合解读与摘要生成”用了大模型。6.2 成本控制要前置考虑大模型API和高级OCR服务都是按量计费成本可能指数级增长。必须在设计初期就考虑缓存对常见、标准的报告模板其解析后的结构化数据可以缓存。同一用户短时间内重复查询同一份报告直接读缓存。异步处理与队列解读报告不是实时聊天允许有延迟如30秒内。采用消息队列进行异步处理可以平滑请求峰值避免为应对洪峰而过度配置资源。模型选型不是所有任务都需要GPT-4。对于简单的信息提取和格式化性能足够的低成本小模型或专用模型可能是更好选择。我们后来就将一部分任务迁移到了更经济的模型上。6.3 法律与伦理合规是生命线处理健康数据安全与合规是重中之重。所有用户数据必须加密传输和存储严格遵循数据最小化原则解读结果必须包含免责声明并且我们设置了严格的内部审计日志确保数据可追溯。在Prompt设计上反复强调“禁止诊断”、“仅供参考”的边界这不仅是保护用户也是保护我们自己。6.4 拥抱不确定性设计容错系统AI服务本质上是非确定性的。与其追求100%的准确不可能不如坦诚地告知用户系统的局限性。我们的产品界面明确写着“AI解读基于通用医学知识不能替代专业医疗诊断”。在系统设计上为“不确定性”留出通道——即人工复核流程。这反而增加了用户的信任感。从AI幻觉到重试这两个坑本质上考验的是我们如何将一个充满不确定性的智能能力封装成一个稳定、可靠、可信的产品功能。这中间没有魔法靠的是扎实的工程化思维分层处理、防御性设计、持续监控和快速迭代。这个过程虽然痛苦但当看到用户因为清晰的解读而缓解焦虑或根据建议开始改善生活习惯时就觉得这些坑踩得值了。AI工程化的路还很长这些经验希望能成为你路上的一块垫脚石。 
