1、能不能简单的介绍一下做模型训练的话整一个流程是什么样子以及我们需要注意的点是什么标准流程5个核心阶段定义问题与收集数据做什么明确模型的任务目标分类、回归、生成→ 收集原始数据公开数据集、自己爬取、甲方提供→ 初步清洗去重、处理缺失值。注意点数据质量直接决定模型上限。遇到过打标签错误的问题导致模型训练后效果不好。数据预处理与探索做什么统一格式、处理异常值、特征工程提取/组合有用信息、数据划分——训练集、验证集、测试集。常用比例 622 或 811。注意点严禁在划分前做全局归一化会泄露测试集信息。选择模型与定义损失做什么选算法图像用CNN、序列用RNN/Transformer、表格用XGBoost/MLP→ 定义损失函数衡量预测和真实值的差距如均方误差、交叉熵→ 选优化器如Adam、SGD。训练与验证做什么模型在训练集上学习每轮epoch后在验证集上评估。反复调整超参数学习率、批大小、网络层数直到验证集性能不再提升。注意点防止模型过拟合训练集loss一直降验证集loss上升。用早停法、正则化、Dropout对抗过拟合。最终评估与部署做什么用从未见过的测试集做一次最终评估得到泛化性能。如果满意导出模型部署到生产环境云端、边缘设备、App内。注意点如果模型上线后用到了数据集以外的数据格式模型效果可能会大打折扣。遇到过医疗单识别模型在上线后识别精读不高。原因训练的数据是一期医疗单实际使用的是二期医疗单不仅字段不一样表格内容也有变化。解决方案重新训练模型使用二期医疗单再训练一边模型精读大幅度提升。局限性模型泛化能力差只能识别出与训练集格式类似的医疗单。总结实际项目中80%的时间花在数据上模型本身通常只占20%。数据质量比模型结构更重要。2、那你训练过程当中有没有看到过一些失败的案例失败的case有吗当时是怎么发现的怎么解决的Case 1数字0和字母O分不清现象发现训练时准确率95%看起来不错但验证集上包含0或O的样本错误率特别高模型把所有圆形都识别成O根本原因训练数据中字体文件导致0和O在低分辨率下几乎一样数据增强过度模糊处理后无法区分解决方案训练层面 # 1. 增加高分辨率样本 # 2. 对这类易混淆字符对做特殊处理 confusing_pairs [(0, O), (1, l, I), (5, S)] 数据层面 # 1. 人工标注更多包含数字0的样本 后处理层面兜底: # 1. 在医疗ocr的场景下体重和血压这种数值指标一定都是0 因此可以把识别出来的内容做一个强制转换字母O全部转为数字0 # 2. 在发票ocr的场景下发票号码以及发票金额也一定出现的是0或者5 不会出现字母O和S这种场景也可以做一个强转Case 2识别失败的case现象发现100个错误样本中大多数都来自手写体根本原因训练数据和真实分布不一致训练集全是印刷体生产环境遇到手写体解决方案# 1. 数据增强加入更多字体变体 # 2. 使用风格迁移Style Transfer生成多样化数据 # 3. 如果特定字体数据太少做few-shot learning3、介绍一下过拟合这个问题它产生的原因是什么有什么样的手段能去避免或者优化这个问题一、什么是过拟合过拟合模型在训练数据上表现太好但在未见过的测试数据上表现很差。二、产生原因1.模型太复杂最常见的原因例用Transformer去做文字识别文字识别这个场景不需要那么复杂的模型去做。稍微换个字体、字号、轻微倾斜就大量识别错误。模型记住了像素细节太细致没学到 “字符结构”这种通用特征。2.训练数据太少模型没有见过足够多的样本模型能轻松把所有样本 “背下来” → 过拟合3.训练时间太长模型在后期开始拟合噪声而非信号解决加入早停机制4. 数据泄露验证集信息无意中混入训练例归一化时用全局均值而非训练集均值三、解决方案增加训练数据# 1. 收集更多真实数据 # 2. 数据增强Data Augmentation augmentation transforms.Compose([ transforms.RandomRotation(10), # 旋转 transforms.RandomAffine(0, shear10), # 仿射变换 transforms.ColorJitter(0.2, 0.2), # 颜色抖动 transforms.GaussianBlur(3), # 模糊 ])降低模型复杂度# 1. 减少网络层数 # 2. 使用更简单的模型架构 # 不要一上来就用ResNet先用浅层CNN试试正则化技术# L1/L2正则化权重衰减 # Dropout随机丢弃神经元L2 正则化让所有权重都变小、趋近于 0但不会变成 0L1 正则化会让很多权重直接变成 0实现特征稀疏化相当于自动筛选重要特征不重要的直接去掉。早停法Early Stopping4、Agent项目能不能简单的描述一下一个用户请求从他的输入到输出完整的执行的链路大概的核心环节介绍一下。核心执行链路输入解析 → 路由分发 → 多模态分析 → RAG检索 → LLM生成 → 安全校验 → 格式化输出第一阶段输入解析当用户发起一个请求首先进入input_parser节点。这个节点的核心任务是多模态输入的识别与结构化理解。用户的输入可能同时包含自然语言文本、上传的医疗报告图片。节点的具体工作包括意图识别判断用户是想进行健康问答、上传数据解读还是紧急求助。比如用户说“我头疼”是健康问答而“我胸口很疼”可能会被标记为潜在紧急情况。实体抽取从文本中提取关键医学实体如症状“头痛”、时间“最近三天”、部位“左胸”、数值“血压140”。这部分我们使用了轻量级的NER模型结合医疗词典进行增强。模态分类判断本次请求携带了哪些数据模态——纯文本、医疗报告图片。这个分类结果直接决定了后续要调用哪些工具。对话上下文整合如果是多轮对话还会结合messages历史状态补全用户省略的信息。这个节点完成后进入路由分发阶段。第二阶段条件路由分发路由分发不是独立的节点而是一个条件边。这个条件边会根据第一阶段解析出的内容动态决定下一步进入哪个处理分支这里的关键设计是多个模态分析器可以并行执行。LangGraph支持分支节点的并发如果一个请求同时包含生理数据和图片两个模态的数据系统会同时进入两个分析节点最后通过同步机制等待所有分支完成后再聚合起来。这种设计显著降低了多模态场景下的端到端延迟。第三阶段多模态数据分析根据路由结果系统会调用对应的分析器节点。生理数据分析器处理心率、血压、血氧等数值型数据基于临床参考范围进行阈值判定如心率100为心动过速输出结构化分析信息JSON格式医疗报告提取器对上传的图片或PDF进行OCR识别提取关键字段如检查项目、结果值、参考范围输出结构化医学信息JSON格式每个分析器完成后都会将结果写入状态中对应的字段然后所有分支汇聚到RAG 节点。第四阶段RAG知识检索RAG 节点负责从医疗知识库中检索与当前问题最相关的内容用于增强大模型的回答准确性减少幻觉。具体流程查询构建将用户的原始问题、抽取的实体、以及多模态分析结果如“焦虑水平0.75”拼接成一个检索查询。例如“头痛 焦虑 心率偏高 缓解方法”。向量化使用 text2vec 模型将查询转换为768维的向量表示。相似度检索在 Chroma 向量数据库中进行检索计算查询向量与知识库文档片段的余弦相似度。阈值过滤我们采用了分级阈值策略常规健康问答相似度阈值 0.65Top-K 取5药品查询阈值提高到 0.80确保准确性结合多模态数据的场景阈值放宽到 0.55因为其他模态信息可以补充降级机制如果检索结果为空或全部低于阈值系统会使用宽松阈值0.45重新检索多轮降低阈值后仍然为空标记该回答 “置信度较低建议补充内容或者咨询医生”检索完成后拼接好 Prompt 送进LLM。第五阶段LLM生成回答llm_generator是核心生成节点它需要融合多个来源的信息并受医疗伦理约束。输入信息融合RAG检索到的医疗知识片段多模态分析结果EEG状态、心率异常标记等对话历史messages系统提示词System PromptPrompt设计要点我们设计了医疗级Prompt包含以下关键约束角色设定“你是一位专业的医疗健康助手具备解读脑电、心率等数据的能力。”输出格式约束要求输出结构化的JSON包含回答正文、置信度、是否需要追问等字段。伦理护栏“禁止给出确诊建议。对于不确定的情况明确建议用户线下就医。”不确定性表达鼓励使用“可能”、“建议进一步检查”等谨慎措辞。输出内容进入校验环节。第六阶段安全与伦理校验医疗场景下安全是最高优先级。safety_checker节点负责对LLM的输出进行二次校验。校验维度紧急情况识别如果LLM判断用户可能处于紧急状态如心梗症状、严重过敏或者用户输入中包含“想自杀”、“胸痛剧烈”等关键词safety_flag会被标记为emergency最终输出会强制包含“请立即就医或拨打急救电话”的提示。伦理合规检查检测模型是否试图给出明确诊断如“你得了高血压”。如果检测到会触发ethics_violation True并根据条件边的配置将流程重新路由回llm_generator要求模型重新生成更谨慎的回答。免责声明补充对于所有非紧急的健康建议自动追加标准免责声明“本回答仅供参考不能替代专业医生的诊断和治疗建议。”敏感信息过滤检查是否有患者隐私数据如身份证号被意外泄露到输出中。第七阶段格式化输出最后一个节点response_formatter负责将最终回答包装成统一的、可追溯的格式。输出结构JSON格式{ answer: 根据您提供的EEG分析和症状描述您的焦虑水平偏高0.75可能与近期的睡眠不佳有关。建议您1. 睡前减少电子设备使用..., confidence: 0.87, need_followup: false, sources: [ {title: 焦虑障碍诊疗指南2024, chunk: 焦虑的生理指标识别..., similarity: 0.72}, {title: 脑电与情绪研究综述, chunk: 额叶alpha不对称性与焦虑..., similarity: 0.68} ], disclaimer: 本回答仅供参考..., trace_id: req_20260115_001234, timestamp: 2026-01-15T10:30:00Z }同时这个节点还会注入链路追踪ID便于后续问题排查和性能分析记录整个链路的耗时统计每个节点的执行时间将最终回答追加到messages历史中供多轮对话使用异常处理与重试机制整个链路中我们设计了统一的error_handler节点和重试逻辑任何一个节点抛出异常如模型超时、数据格式错误会被捕获并转入error_handlererror_handler根据retry_count决定如果重试次数小于3则重新执行失败节点否则返回友好的错误提示并结束流程关键操作如LLM调用还实现了超时控制60秒超时和熔断降级连续失败5次后返回缓存答案--模型繁忙模型超时……5、如果要对这整一个链路去做评估来评价一下目前这个agent的效果有没有类似于去做过这样的一些工作或者设计从离线评估、在线评估、分模块评估、以及bad case分析四个维度来详细说明。一、离线评估体系开发/测试阶段离线评估是在上线前用固定的测试集对Agent的各个模块和整体效果进行量化评估。1. 分模块评估模块评估指标测试方法目标阈值意图识别准确率、召回率、F11000条标注的用户query准确率 ≥ 92%实体抽取实体级别精确率/召回率标注的医疗实体症状、药品、时间等F1 ≥ 88%RAG检索Top5、MRR、NDCG500条query-文档对人工标注相关性Top5准确率 ≥ 80%LLM生成BLEU、ROUGE、BERTScore标准问诊测试集 vs 医生回答BERTScore ≥ 0.852. 专项评估集构建构建三个专门的测试集标准问诊测试集200条覆盖常见症状、药品咨询、报告解读等场景每条配有医生标注的“标准答案”对抗性测试集50条包含歧义问法、多模态混合输入、隐含紧急情况等边界案例边界测试集30条专门测试模型是否会给出危险建议、越界诊断或敏感信息泄露3. 离线评估流程测试集 → Agent执行 → 自动计算指标BLEU/ROUGE/准确率→ 人工抽样复核 → 生成评估报告每轮模型迭代后都要跑一遍完整的离线评估确保核心指标不出现反常。二、在线评估体系生产阶段上线后我们需要在真实环境中持续监控Agent的表现。核心业务指标指标定义监控频率当前基线回答采纳率用户对回答点击“有帮助”的比例每日~78%追问转化率系统追问后用户继续补充信息的比例每日~65%平均轮次完成一次健康咨询的平均对话轮数每日2.8轮用户满意度对话结束后1-5分评分每日4.2/5.0知识库未命中率RAG检索返回空结果的比例每日~5%三、人工评估体系机器指标不能完全代表质量我们定期引入医疗专业人员进行人工评估。1. 评估维度每个维度1-5分维度评分标准医学准确性回答是否符合医学共识有无明显错误安全性是否越界给出确诊建议是否包含必要免责声明完整性是否覆盖了用户问题的所有方面可读性语言是否清晰、结构化、易于理解多模态融合质量EEG/生理数据是否被正确解读并与文本融合2. 评估流程每周随机抽取50条真实对话由2名医学背景的研究生独立评分生成人工评估周报追踪趋势变化四、Bad Case 分析与迭代闭环评估的最终目的是驱动改进。我们建立了Bad Case闭环机制1. 来源收集用户点击“没有帮助”的对话人工评估中得分低于3分的案例触发安全拦截的回答RAG召回失败的查询2. 分析分类将问题分类问题类型占比示例根因改进措施RAG检索不到35%知识库覆盖不足补充知识文档LLM幻觉25%Prompt约束不够强化Prompt护栏意图识别错误15%训练数据不足补充标注微调EEG解读偏差10%模型阈值不当调整后处理逻辑安全护栏误触发10%规则过严调整关键词白名单3. 闭环流程Bad Case收集 → 分类标注 → 根因分析 → 制定改进方案 → 代码/配置修改 → 离线回归测试 → 上线验证每个Bad Case都有追踪ID确保不重复出现同类问题。6、如果要对agent去做一些比较专业的测评的话你觉得可以定义哪些指标一、核心能力维度功能性与准确性意图识别准确率实体抽取F1任务完成率答案准确率二、安全性维度医疗Agent场景医疗场景下安全性指标优先级最高。指标危险回答率越界诊断率免责声明覆盖率100%隐私泄露率0%三、效率与资源维度商业化后要考虑的一个方向衡量Agent的响应速度和资源消耗。指标名称定义量化方式目标值参考端到端延迟P50/P99从用户请求到完整响应的时间统计生产环境分位数P50 3sP99 8s首token时间TTFT用户看到第一个字符的时间流式输出场景下测量 1s吞吐量单节点每秒能处理的请求数压测获得 10 req/sGPUToken效率生成回答所需的平均token数统计LLM调用精简Prompt减少冗余四、鲁棒性与稳定性维度衡量Agent在异常情况下的表现。指标名称定义量化方式对抗性鲁棒性面对歧义、错别字、非常规表达时的表现对抗测试集上的任务完成率空输入处理输入为空或无效时是否返回友好提示而非报错边界测试超长上下文处理对话轮次过多如20轮时的表现压力测试降级成功率RAG无结果或模型超时等异常时降级策略是否生效故障注入测试重试成功率临时故障后自动重试并成功的比例统计重试次数与成功率五、用户体验维度主观但关键最终用户的主观感受需要结合问卷和行为数据。指标名称定义采集方式满意度评分CSAT用户对话结束后1-5分评分对话末尾弹窗回答采纳率用户点击“有帮助”按钮的比例埋点统计放弃率用户在未完成对话前退出的比例会话分析追问响应率Agent追问后用户继续回答的比例行为统计通用测评基准AgentBench清华8 大仿真环境OS、DB、Web、游戏、家庭服务等测长程推理、多步决策、跨环境能力指标任务成功率ToolBenchOpenAI专注工具 / API 调用16k 真实 API、单 / 多工具 / 多轮指标Pass Rate、Tool Call Accuracy、胜率MT-BenchLMSYS多轮对话 Agent 基准80 多轮问题GPT-4 自动打分 人工校准测对话能力、指令遵循、上下文保持7、场景题如果让你去构建一个电商导购的AI agent比如说用户输入一些比较模糊的需求“我想买一件夏天的T恤”或者“我想买一个礼物送给女朋友”从百万级别的商品库中去召回推荐适合的商品然后也要支持多轮对话等常见的agent能力如果让你去设计这个agent的构建方案的话你大概会怎么样去设计核心思路不要试图让大模型去记住百万商品而是让大模型学会“写查询”和“做判断”。第一步感知与记忆用户会说“我想要一件夏天的T恤但不要太贵的”。这需要Agent具备短期记忆。也可以从用户画像长期记忆中检索出用户的偏好。实现用Redis缓存维护当前会话的session_id对应的上下文存储user_preferences如{style:简约, color:浅色系, occasion:日常}和history。用数据库缓存用户的画像信息存储consumption_level消费水平为用户推荐相应价格的商品。关键点每轮对话后更新短期记忆长期记忆一般是用户长期以来的购物偏好可以触发更新购买多少个商品后或者定时更新。第二步意图理解与查询改写核心难点用户说的是“礼物送给女朋友”——这是一个极其模糊但高频的场景。需要做结构化拆解。方案采用“意图解析器”模式。场景识别判断是“给自己买”功能导向还是“给他人买”情感导向。属性抽取用LLM大语言模型配合Few-shot或Function Calling抽取出关键属性JSON查询改写将模糊词“夏天的T恤”扩展为多个检索词“纯棉短袖”、“亚麻T恤”、“透气圆领”提高召回率。第三步多路召回从百万到几百不可能让LLM直接遍历百万商品。使用传统检索ES/向量兜底LLM负责筛选。设计召回管道并行路径A关键词召回用ESElasticsearch对商品标题、属性进行BM25匹配。适合“耐克 运动鞋”这种明确需求。路径B向量召回将用户Query和商品描述都Embedding化用Faiss或Milvus做语义相似度搜索。适合“很有设计感的杯子”这种模糊需求。路径C画像召回从用户历史点击/购买中找出同品类、同价格带的热销商品。适合“再买一件类似的”。路径D知识图谱召回针对“送女友”这类关系型需求。图谱中定义“女友” - “偏好” - “口红/包包/首饰”的路径直接拉取对应商品。结果每条路径取Top 100去重后得到200-300个候选商品。第四步精排与解释生成从几百到几个200个商品还是太多不能全丢给用户。需要重排序模型。设计两阶段过滤轻量预过滤用传统排序模型如GBDT梯度提升决策树基于CTR点击率、销量、价格匹配度快速筛出Top 20。LLM精排将Top 20的商品信息标题、图片描述、价格、标签打包加上用户偏好Prompt让LLM做最终判断。Prompt“用户想要简约、500元内的女友生日礼物。以下商品中哪些符合按匹配度排序。”输出Top 3-5个商品ID。生成推荐理由这是AI agent的价值所在。LLM根据选中商品的特征生成个性化推荐语。输出“这款施华洛世奇黑天鹅项链很符合你女友的简约风格黑色百搭且刚好在你500元预算内。作为生日礼物小众又有仪式感。”第五步多轮对话与澄清机制当信息不足时不要瞎猜。主动提问。策略置信度评估如果意图解析器里category_hint有3个且分数接近或者price_max为None则进入澄清状态。追问模板“你是想给她买穿戴类的比如首饰、包包还是实用类的比如香薰、电子产品呢”“夏天的T恤你是想要纯棉的吸汗材质还是冰丝的凉感材质”闭环修正用户回复“太贵了”或“不喜欢这个颜色”Agent回到第一步更新user_preferences中的exclude_ids或price_max重新召回。这个方案的设计原则是LLM做它最擅长的理解、推理和生成传统算法做它最擅长的检索、统计和排序。两者结合才能在百万商品中既快又准地满足模糊需求。8、AOP的动态代理它底层是怎么实现的Spring AOP的动态代理底层实现核心运行时动态生成一个代理类在代理类的方法调用前后插入增强逻辑。具体有两种实现方式Spring会根据目标类是否实现接口来自动选择一、JDK动态代理基于接口适用条件目标类实现了至少一个接口底层机制利用Java标准库中的java.lang.reflect.Proxy类运行时动态生成一个实现了相同接口的代理类代理类内部持有InvocationHandler引用所有方法调用都会转发到invoke()方法简化版源码示意// 1. 定义接口 public interface UserService { void save(); } // 2. 目标类 public class UserServiceImpl implements UserService { public void save() { System.out.println(保存用户); } } // 3. InvocationHandler增强逻辑 public class MyInvocationHandler implements InvocationHandler { private Object target; // 真实对象 public Object invoke(Object proxy, Method method, Object[] args) { System.out.println(前置增强); // Before Object result method.invoke(target, args); // 调用真实方法 System.out.println(后置增强); // After return result; } } // 4. 生成代理 UserService proxy (UserService) Proxy.newProxyInstance( UserService.class.getClassLoader(), new Class[]{UserService.class}, // 必须传接口 new MyInvocationHandler(new UserServiceImpl()) ); proxy.save(); // 输出前置增强 - 保存用户 - 后置增强二、CGLIB动态代理基于继承适用条件目标类没有实现接口或Spring配置强制使用底层机制利用ASM字节码技术运行时动态生成目标类的子类子类重写父类的所有非final方法在重写的方法中插入增强逻辑通过MethodInterceptor实现方法拦截简化版源码示意// 1. 目标类没有接口 public class UserService { public void save() { System.out.println(保存用户); } } // 2. MethodInterceptor public class MyMethodInterceptor implements MethodInterceptor { private Object target; public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) { System.out.println(前置增强); Object result proxy.invokeSuper(obj, args); // 调用父类目标类方法 System.out.println(后置增强); return result; } } // 3. 生成代理 Enhancer enhancer new Enhancer(); enhancer.setSuperclass(UserService.class); // 设置父类 enhancer.setCallback(new MyMethodInterceptor()); // 设置拦截器 UserService proxy (UserService) enhancer.create(); proxy.save(); // 输出前置增强 - 保存用户 - 后置增强三、两种方式对比维度JDK动态代理CGLIB实现原理实现接口生成子类目标类要求必须有接口不能是final类方法不能是final/static性能较慢反射调用较快直接调用但生成代理慢依赖JDK自带需要额外引入cglib.jarSpring自带可见性只能代理public方法可代理protected/默认访问级别方法