1. 项目概述一个真正能用的医疗知识助手不是玩具我做过三年临床辅助系统开发也带过五届医学信息学方向的研究生见过太多标榜“医疗AI”的Demo——界面炫酷一问“高血压患者能否服用布洛芬”回答里夹杂着“请咨询医生”和一堆维基百科式定义连药品相互作用的基本逻辑都跑不通。这次要做的是一个能真正嵌入工作流的医疗RAGReAct智能体它不生成诊断不替代医生但能在你查房前30秒从最新指南、药品说明书、临床试验摘要中精准捞出关键信息能在写病历时自动关联ICD-10编码与对应诊疗路径甚至能根据你输入的“65岁女性新发房颤CHA₂DS₂-VASc3CrCl45ml/min”实时比对华法林与新型口服抗凝药NOACs在肾功能减退人群中的剂量调整证据等级。核心不是堆砌技术名词而是让LangChain的ReAct框架、ChromaDB的向量检索、OpenAI的推理能力在真实医疗语境下严丝合缝地咬合。关键词里的“Towards AI - Medium”只是原始出处我们彻底剥离平台属性聚焦技术内核RAG如何避免幻觉ReAct的“思考-行动”循环怎样防止医疗建议越界ChromaDB的元数据过滤怎样确保只返回2023年后的ESC心衰指南而非2012年的旧版这篇文章就是我去年在三甲医院信息科落地该项目时的完整复盘所有代码、配置、踩坑记录全部开源你可以直接抄作业也能看清每一步背后的临床逻辑与工程权衡。2. 整体设计与思路拆解为什么是ReActRAG而不是纯微调或Prompt Engineering2.1 医疗场景的三大刚性约束决定了技术选型的唯一性很多同行第一反应是“微调一个医疗大模型”这在工程上是条死路。我试过用Llama-3-8B在本地微调喂了30万条《内科学》教材问答对结果模型在测试集上准确率92%但一遇到“利尿剂抵抗的顽固性心衰患者托伐普坦与呋塞米联用的起始剂量”这种具体问题就开始编造文献编号和不存在的剂量方案。根本原因在于医疗知识具有强时效性、高专业性、严逻辑性。微调模型会把知识“蒸馏”进参数一旦指南更新整个模型就得重训而RAG是把知识库当“外挂硬盘”只在需要时实时加载最新片段知识永远新鲜。更关键的是纯Prompt Engineering比如写个超长system prompt“你是一名资深心内科医生必须严格依据2023年ACC/AHA指南…”在复杂推理链面前必然崩溃——当用户问“该患者是否适合TAVR需满足哪些解剖学条件术前CTA评估要点有哪些”模型需要分步检索瓣环尺寸、升主动脉直径、冠脉开口高度等多维度数据再交叉验证这不是单次Prompt能驾驭的。ReAct框架正是为这种场景而生。它的“Reasoning Acting”本质是强制模型暴露思考过程先判断“这个问题需要查什么”再调用工具如向量检索拿到结果后再基于结果做下一步推理。这就像一位老专家在查房时的口头禅“嗯…这个心电图表现得先看下2024年ESC室速处理流程图行动→ 哦这里明确写了宽QRS波心动过速鉴别要点观察→ 那患者V1导联呈RSR’型R’波时限50ms符合室速特征推理→ 建议立即行同步电复律决策”。整个链条可追溯、可审计、可干预。我们不用相信模型“说对了”而是相信它“按正确步骤做了”。2.2 技术栈选型LangChain、ChromaDB、OpenAI的组合是当前最稳的“铁三角”LangChain被诟病“臃肿”但在医疗领域恰恰是优势。它的模块化设计让安全边界清晰可控我们可以把“检索工具”和“推理引擎”物理隔离。比如检索模块只负责从ChromaDB中拉取文本片段绝不允许它调用任何外部API而推理模块LLM的输入被严格限定为“用户问题检索到的3段文本固定格式的指令模板”。这样即使LLM本身有幻觉倾向它的发挥空间也被锁死在已检索到的证据范围内。我对比过LlamaIndex它检索精度略高但工具链太轻量缺乏LangChain那种企业级的错误熔断机制比如当ChromaDB查询超时LangChain能自动降级为关键词匹配而LlamaIndex直接报错中断。ChromaDB选型是经过血泪教训的。最初用FAISS本地测试飞快但部署到医院内网服务器后一并发10个检索请求内存就爆到95%。ChromaDB的持久化设计和内存管理更成熟尤其它的元数据过滤Metadata Filtering功能是医疗应用的生命线。比如我们给每条知识片段打上{source: guideline, year: 2023, specialty: cardiology}标签当用户问“心衰治疗”系统能自动过滤掉year 2022和specialty ! cardiology的条目避免用2018年旧指南误导当前决策。这个能力SQLite或纯向量库根本做不到。OpenAI的gpt-4-turbo是目前唯一能稳定处理长上下文128K tokens且医疗术语理解准确率超90%的商用模型。我实测过Claude-3-Opus在解读“eGFR30ml/min/1.73m²患者使用二甲双胍的禁忌证”时把FDA黑框警告和EMA建议混为一谈而gpt-4-turbo能精准区分监管机构差异并标注原文出处。当然我们绝不会把原始API key硬编码进前端所有调用都经由自建的代理层强制添加审计日志和速率限制——这是医疗系统的底线。2.3 架构图不是画饼是部署时的真实拓扑------------------- --------------------- --------------------- | Gradio Web UI |----| LangChain Agent Core|----| ChromaDB Vector | | (User Input/Chat) | | - ReAct Orchestrator| | Database | | | | - Tool Router | | - Documents: | | | | - Memory Manager | | * Clinical Guidelines| | | -------------------- | * Drug Monographs | | | | | * Trial Summaries | | | | | - Metadata: source, | | | | | year, specialty, | | | | | evidence_level | | | | -------------------- | | | | | | | | | | v v | | --------------------- --------------------- | |----| OpenAI LLM API |----| Embedding Model | | | | (gpt-4-turbo) | | (text-embedding-3- | | | | - Strict Prompt | | small) | | | | Templating | --------------------- | | | - Output Parsing | | | --------------------- -------------------注意几个关键细节Gradio不是简单套壳我们禁用了默认的“streaming”模式因为医疗建议必须整句输出才可审计同时启用了state参数将对话历史以JSON格式存于浏览器内存避免敏感信息上传服务器。Agent Core的“Memory Manager”是自研模块它不存储原始对话而是提取结构化记忆比如“用户身份心内科主治医师当前关注疾病心力衰竭最近检索主题ARNI类药物”。这样下次提问“沙库巴曲缬沙坦的起始剂量”系统能自动关联到“心衰”上下文无需用户重复说明。Embedding Model必须与检索模型一致我们用text-embedding-3-small而非ada-002因为前者在长文本切片chunk上的语义保真度更高实测在“射血分数保留型心衰HFpEF的诊断标准”这类复合概念检索中召回率提升27%。3. 核心细节解析与实操要点从知识库构建到安全护栏3.1 医疗知识库的构建不是扔PDF进去而是“外科手术式”处理很多人以为RAG就是把PDF丢进向量库。我在协和医院信息科合作时看到过最典型的失败案例某团队把《默克诊疗手册》全书PDF直接切块入库结果用户问“糖尿病足感染的抗生素选择”返回的片段全是“糖尿病定义”“足部解剖图”。问题出在文本切分Chunking策略上。医疗文本有强结构标题、小标题、表格、脚注、参考文献。粗暴按512字符切分会把“表3常见致病菌及首选抗生素”切成两半导致检索失效。我们的解决方案是三级切分法一级按文档结构切分用pdfplumber解析PDF识别h1/h2/h3标题层级。每个h2标题如“2.3 糖尿病足感染”及其下属内容为一个逻辑块。二级按语义完整性切分对每个逻辑块用spaCy识别句子边界确保每个chunk包含完整句子。特别处理表格将整个表格转为Markdown字符串作为独立chunk因为表格是医疗决策的核心依据。三级元数据注入为每个chunk添加{doc_title: 默克手册-感染篇, section: 2.3, table_ref: Table 3, evidence_level: A}。其中evidence_level来自人工标注A级RCT荟萃分析B级队列研究C级专家共识后续可作为排序权重。实操心得绝对禁止OCR质量差的扫描件我们曾用某三甲医院内部扫描的《中国心力衰竭诊断指南》OCR识别把“β受体阻滞剂”错成“β受体阻滞刑”导致所有相关检索失效。必须用原版PDF或高质量扫描。药品说明书要单独处理FDA/EMA官网的说明书含大量法律声明和不良反应列表这些噪声会污染向量空间。我们用正则表达式精准提取“适应症”“用法用量”“禁忌”“药物相互作用”四个核心章节其他一律剔除。临床试验摘要要“去广告化”很多期刊摘要开头就是“本研究由XX药企资助”这种内容必须清洗否则向量相似度会把“资助方”误判为相关性。3.2 ReAct Agent的Prompt工程用“手术刀”刻出安全边界LangChain的create_react_agent模板很强大但开箱即用的prompt在医疗场景下是危险的。默认prompt允许模型调用search工具但没限定搜索范围。我们重构了整个prompt核心是三层安全锁第一锁角色与权限锁定你是一名医疗知识助理由[某三甲医院]信息科开发。你的唯一职责是基于已提供的权威医学资料仅限以下来源回答用户关于疾病、药物、检查、指南的问题。你不得 - 提供任何诊断或治疗建议 - 引用未在知识库中出现的文献或数据 - 对知识库未覆盖的问题进行推测 - 使用“可能”“大概”“建议”等模糊词汇必须引用原文措辞。第二锁工具调用白名单我们禁用了所有LangChain内置工具如wikipedia只保留自定义的medical_rag_search工具并在prompt中明确定义其能力medical_rag_search(query: str, filters: dict) - list[dict] 功能在医疗知识库中检索与query最相关的片段。 filters示例{source: guideline, year: {$gte: 2022}} 注意你只能调用此工具一次且必须指定filters第三锁输出格式强制规范要求模型必须按以下JSON Schema输出任何偏差都会触发重试{ thought: 简短描述你为何需要此信息例如需确认2023年ESC指南对HFrEF患者ARNI使用的推荐等级, action: medical_rag_search, action_input: { query: ESC 2023 HFrEF ARNI recommendation, filters: {source: guideline, year: 2023, specialty: cardiology} } }提示这个JSON Schema不是摆设。我们在LangChain的AgentExecutor中加了output_parser校验如果模型返回{action: search, action_input: ...}少了filters字段系统会自动抛出OutputParserException并重试绝不让不合规的调用流出。3.3 ChromaDB的医疗级配置不只是向量存储更是知识治理中枢ChromaDB的默认配置在医疗场景下会出大问题。比如它默认的hnsw索引算法在高维向量text-embedding-3-small是1536维上ef_construction参数设为100时召回率只有78%。我们通过实测将ef_construction调至200ef_search调至150召回率提升至94%代价是索引时间增加40%但这是可接受的——知识库更新是离线批量操作而检索是高频在线行为。最关键的配置是元数据过滤的性能优化我们为常用过滤字段source,year,specialty建立了复合索引。ChromaDB本身不支持传统数据库索引但我们用where_document配合预计算的倒排索引实现。例如specialty字段我们维护一个字典{cardiology: [id1, id2, ...], oncology: [id3, id4, ...]}查询时先快速定位ID列表再对这些ID做向量检索速度提升3倍。year字段的过滤必须支持范围查询$gte,$lte。我们没有用ChromaDB原生的where而是将year转为整数存入metadata并在检索前用Python预筛选ID再传给collection.query()避免ChromaDB在向量检索后二次过滤的性能损耗。实操心得向量维度必须与Embedding Model严格一致text-embedding-3-small输出1536维若ChromaDB collection创建时设为dimension1536但实际插入时因bug少了一维整个库会不可用。我们写了个validate_embedding_dim()函数在每次插入前校验。删除旧知识要“外科清创”不能简单collection.delete(where{year: {$lt: 2022}})。因为2022年前的指南可能仍有价值如历史对照我们采用“软删除”添加{status: archived}字段检索时默认where{status: active}需要时再手动恢复。备份策略是生命线ChromaDB的persist_directory必须挂载到医院PACS系统的同等级存储且每日增量备份。我们用rsync脚本只同步chroma.sqlite3和index/目录备份耗时控制在2分钟内。4. 实操过程与核心环节实现从零开始搭建可运行系统4.1 环境准备与依赖安装避开Python生态的“医疗雷区”医疗IT环境特殊很多医院内网禁用pip源且要求所有包通过院内镜像站安装。我们用conda而非pip管理环境因为conda能更好处理C依赖如ChromaDB的hnswlib。以下是经过三甲医院信息科审核的environment.ymlname: medical-rag-agent channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ - conda-forge dependencies: - python3.10 - pip - pip: - langchain0.1.18 - chromadb0.4.24 - openai1.35.0 - gradio4.32.0 - pdfplumber0.10.2 - spacy3.7.4 - scikit-learn1.3.2 # 用于后续相似度分析 - sentence-transformers2.6.1 # 备用embedding模型注意openai1.35.0是关键。新版openai1.40.0强制要求httpx0.25.0而httpx在某些医院老旧Linux内核如CentOS 7.6上会触发SSL握手失败。我们锁死版本并在requirements.txt中注明“若遇SSL错误请升级openssl至1.1.1w以上”。4.2 知识库构建全流程代码即文档以下是我们生产环境使用的build_knowledge_base.py核心代码已脱敏并添加详细注释import os import json from pathlib import Path import chromadb from chromadb.utils import embedding_functions from langchain.text_splitter import RecursiveCharacterTextSplitter import pdfplumber import spacy # 1. 初始化ChromaDB客户端使用持久化模式 client chromadb.PersistentClient(path./chroma_db) # 使用text-embedding-3-small必须与OpenAI API一致 ef embedding_functions.OpenAIEmbeddingFunction( model_nametext-embedding-3-small, api_keyos.getenv(OPENAI_API_KEY) # 从环境变量读取绝不硬编码 ) # 2. 创建collection关键指定metadata_schema collection client.create_collection( namemedical_knowledge, embedding_functionef, metadata{ hnsw:space: cosine, # 余弦相似度最适合语义检索 hnsw:construction_ef: 200, hnsw:search_ef: 150 } ) # 3. 加载并解析PDF以《2023 ESC心衰指南》为例 def parse_guideline_pdf(pdf_path: str): chunks [] with pdfplumber.open(pdf_path) as pdf: for page_num, page in enumerate(pdf.pages): text page.extract_text() if not text: continue # 按标题分割匹配3.1.1 诊断标准这样的模式 sections re.split(r(\d\.\d\.\d\s.), text) for i, section in enumerate(sections): if i % 2 0: # 奇数位是内容 continue # 偶数位是标题提取章节号和名称 match re.match(r(\d\.\d\.\d)\s(.), section.strip()) if match: section_id, title match.groups() # 将本节内容与标题合并确保语义完整 content section (sections[i1] if i1 len(sections) else ) # 添加元数据 metadata { source: guideline, year: 2023, specialty: cardiology, section_id: section_id, title: title, page: page_num 1, evidence_level: A # 根据指南原文标注 } chunks.append({content: content.strip(), metadata: metadata}) return chunks # 4. 文本切分使用RecursiveCharacterTextSplitter但设置医疗专用参数 text_splitter RecursiveCharacterTextSplitter( chunk_size512, # 不是越大越好过大导致语义稀释 chunk_overlap128, # 重叠128字符确保句子不被截断 separators[\n\n, \n, 。, , , ] # 中文优先按句号切分 ) # 5. 批量插入关键分批提交避免内存溢出 all_chunks parse_guideline_pdf(./docs/ESC_HF_2023.pdf) for i in range(0, len(all_chunks), 100): # 每100条一批 batch all_chunks[i:i100] documents [chunk[content] for chunk in batch] metadatas [chunk[metadata] for chunk in batch] ids [fguideline_{ij} for j in range(len(batch))] collection.add( documentsdocuments, metadatasmetadatas, idsids ) print(fInserted batch {i//100 1}, total {len(all_chunks)} chunks) print(Knowledge base built successfully!)实操心得chunk_overlap128是黄金值小于100句子常被截断大于150向量空间冗余度飙升检索变慢。我们用spacy对1000个chunk做句法分析验证了128能覆盖99.2%的完整句子。separators顺序至关重要中文必须把。放在第一位否则会按空格切分把“β受体阻滞剂”切成“β受体”和“阻滞剂”语义全毁。ids必须全局唯一我们用guideline_123而非str(uuid.uuid4())因为后者无法追溯来源审计时无法定位原始PDF页码。4.3 ReAct Agent核心代码安全与效率的平衡术以下是medical_agent.py的核心实现重点展示如何将前述Prompt工程与ChromaDB集成from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import tool from langchain_core.messages import HumanMessage, AIMessage import chromadb # 1. 定义医疗专用检索工具 tool def medical_rag_search(query: str, filters: dict) - list[str]: 在医疗知识库中检索相关信息。必须指定filters try: # 连接ChromaDB生产环境应使用连接池 client chromadb.PersistentClient(path./chroma_db) collection client.get_collection(medical_knowledge) # 执行带过滤的查询 results collection.query( query_texts[query], n_results3, # 只取最相关3条避免信息过载 wherefilters # 直接传入dictChromaDB自动转换 ) # 返回纯文本片段不含metadata避免泄露内部结构 return [doc for doc in results[documents][0]] except Exception as e: return [f检索失败{str(e)}。请检查网络或联系管理员。] # 2. 构建ReAct Agent关键定制化Prompt prompt ChatPromptTemplate.from_messages([ (system, 你是一名医疗知识助理由[某三甲医院]信息科开发。你的唯一职责是基于已提供的权威医学资料回答用户问题。你不得提供诊断或治疗建议。 工具 {tools} 工具使用规则 1. 你只能调用medical_rag_search工具一次 2. 调用前必须明确思考需要什么信息从哪个来源获取 3. 必须指定filters例如{source: guideline, year: {$gte: 2022}} 4. 输出必须严格遵循JSON格式{thought: ..., action: medical_rag_search, action_input: {query: ..., filters: {...}}} 请开始。), MessagesPlaceholder(variable_namechat_history), (human, {input}), MessagesPlaceholder(variable_nameagent_scratchpad), ]) # 3. 初始化LLM关键temperature0杜绝随机性 llm ChatOpenAI( modelgpt-4-turbo, temperature0, # 医疗场景绝不允许“创意” max_tokens1024, api_keyos.getenv(OPENAI_API_KEY) ) # 4. 创建Agent Executor关键添加错误处理 agent create_react_agent( llmllm, tools[medical_rag_search], promptprompt ) agent_executor AgentExecutor( agentagent, tools[medical_rag_search], verboseTrue, handle_parsing_errorsTrue, # 自动处理JSON解析失败 max_iterations5 # 防止死循环 ) # 5. 对话管理关键状态保持与审计 def run_agent(user_input: str, chat_history: list None): if chat_history is None: chat_history [] # 将历史消息转换为LangChain格式 formatted_history [] for msg in chat_history: if msg[role] user: formatted_history.append(HumanMessage(contentmsg[content])) else: formatted_history.append(AIMessage(contentmsg[content])) # 执行Agent result agent_executor.invoke({ input: user_input, chat_history: formatted_history }) # 记录审计日志生产环境写入ELK audit_log { timestamp: datetime.now().isoformat(), user_input: user_input, agent_output: result[output], retrieved_docs_count: len(result.get(intermediate_steps, [])) } print(AUDIT:, json.dumps(audit_log, ensure_asciiFalse)) return result[output]提示max_iterations5不是随意定的。我们模拟了1000次复杂查询如“比较达格列净与恩格列净在CKD患者中的肾脏获益证据”发现99.8%的case在3步内完成思考→检索→回答设为5是留足安全余量防止因网络抖动导致的无限重试。4.4 Gradio前端不止是聊天框更是临床工作台Gradio默认UI对医生不友好。我们重写了app.py核心改进import gradio as gr from medical_agent import run_agent # 自定义CSS适配医院内网低分辨率屏幕 custom_css #chatbot { height: 500px; overflow-y: auto; } #input_box { width: 100%; } .gradio-container { font-family: Microsoft YaHei, sans-serif; } # 创建Blocks App非简单Interface with gr.Blocks(csscustom_css) as demo: gr.Markdown(## [某三甲医院] 医疗知识助手 v1.0) gr.Markdown(⚠️ 本系统仅提供知识检索服务不构成医疗建议。所有决策请以最新指南及主治医师意见为准。) # 会话状态管理 chat_state gr.State([]) # 聊天区域 chatbot gr.Chatbot( label对话记录, elem_idchatbot, avatar_images(‍⚕️, ), # 医生和机器人头像 bubble_full_widthFalse ) # 输入框带快捷按钮 with gr.Row(): msg gr.Textbox( label请输入问题, placeholder例如心衰患者使用ARNI类药物的禁忌证有哪些, elem_idinput_box ) submit_btn gr.Button(发送, variantprimary) # 快捷问题按钮降低医生学习成本 with gr.Row(): gr.Examples( examples[ [心衰患者使用ARNI类药物的禁忌证有哪些], [2023年ESC指南对HFrEF患者的ARNI推荐等级是什么], [利尿剂抵抗的顽固性心衰托伐普坦的起始剂量], [eGFR30ml/min/1.73m²患者使用二甲双胍的禁忌证] ], inputsmsg, label常用问题示例 ) # 底部状态栏 status_bar gr.Markdown( 系统就绪 | 知识库2022-2024年心血管指南、药品说明书、临床试验摘要) # 事件绑定 def respond(message, chat_history): bot_message run_agent(message, chat_history) chat_history.append((message, bot_message)) return , chat_history submit_btn.click( respond, inputs[msg, chat_state], outputs[msg, chatbot] ) msg.submit( respond, inputs[msg, chat_state], outputs[msg, chatbot] ) if __name__ __main__: demo.launch( server_name0.0.0.0, # 绑定内网IP server_port7860, shareFalse, # 绝不开启公网分享 auth(doctor, hospital123) # 基础认证生产环境应对接LDAP )实操心得avatar_images用emoji而非图片医院内网常禁用外部图片加载emoji是唯一可靠方案。gr.Examples是医生最爱的功能80%的新用户第一次使用都是点“常用问题示例”而不是自己打字。我们按科室心内、神内、呼吸分类维护了200个高频问题。auth参数必须启用哪怕只是基础用户名密码也要防止实习生误操作。我们把凭证存在/etc/secrets/而非代码中。5. 常见问题与排查技巧实录那些没人告诉你的坑5.1 知识库检索“查不到”90%是这三个原因问题现象根本原因排查命令/方法解决方案用户问“ARNI禁忌证”返回空结果chunk_size过大导致“禁忌证”关键词被切到不同chunkchroma_client.get_collection(medical_knowledge).peek()查看前几条chunk内容将chunk_size从1024降至512重新构建库检索返回2012年旧指南而非2023年新指南filters未生效ChromaDB忽略where参数collection.query(query_texts[ARNI], n_results1, where{year: 2023})单独测试检查where语法{year: 2023}精确匹配 vs{year: {$eq: 2023}}ChromaDB 0.4要求同一问题多次检索结果不一致hnsw:search_ef过低影响近似最近邻搜索稳定性collection.get(where{section_id: 4.2.1})确认文档存在再查query将hnsw:search_ef从100提升至150重启ChromaDB提示我们写了个debug_retrieval.py脚本一键执行上述三步检查医生信息科同事5分钟就能定位问题。5.2 Agent“胡言乱语”其实是Prompt在报警ReAct Agent的“胡言乱语”往往不是模型故障而是安全机制在起作用。典型场景现象用户问“高血压用药”Agent返回{thought: 需确认一线用药, action: medical_rag_search, action_input: {query: hypertension first line drugs}}但后续无响应。原因action_input中的query用了英文而知识库是中文。ChromaDB检索无果Agent卡在“等待结果”状态。解决在medical_rag_search工具内部加日志print(f[DEBUG] Query: {query}, Filters: {filters})确认输入语言。我们强制在Agent层做中英翻译query translate_to_chinese(query)用googletrans库离线版避免调用外部API。现象Agent反复调用medical_rag_searchmax_iterations5后报错“Maximum iteration reached”。原因用户问题太宽泛如“心衰”导致检索返回100条无关内容LLM无法提炼。解决在Prompt中加入“问题澄清”规则当用户问题缺少关键限定词如疾病分期、患者特征请先追问请问您关注的是HFrEF还是HFmrEF患者。我们修改了create_react_agent的output_parser当检测到thought含“请确认”“请问”时跳过工具调用直接输出追问。5.3 性能瓶颈排查从“慢”到“快”的四步法医疗系统对延迟敏感。我们定义SLA95%的查询响应时间3秒。当超时时按此顺序排查第一步测ChromaDB原生性能# 在