人类摇晃着新发明的计算机，证明自己不比神秘学家差。
Dynamic Construction of Causal Knowledge Graphs for Scientific Reasoning in Search Agents
概述本文档详细记录了如何在 MetaGPT 框架中实现一个具有动态 Action 创建能力的 Agent。通过本教程，你将深入理解 MetaGPT 的 React 机制（run → react → think → act）以及如何在运行时动态切换 Action 序列。作业目标：创建一个 Agent，初始化时拥有三个动作：Print1, Print2, Print3顺序执行这三个动作执行完毕后，动态生成新的动作：Print4, Print5, Print6继续顺序执行新动作学习重点：MetaGPT 的 React 循环机制状态管理（state, todo, actions）动态 Action 创建与替换Python 对象引用与多态核心概念1. MetaGPT 的 React 机制┌─────────────────────────────────────┐ │ run(message) │ │ - 接收消息并存入 memory │ │ - 调用 react() │ └──────────────┬──────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ react() │ │ - while True 循环 │ │ - think() → 决定下一个动作 │ │ - 检查 todo 是否为 None │ │ - act() → 执行当前动作 │ └──────────────┬──────────────────────┘ ↓ ┌──────────────┴──────────────────────┐ │ │ │ ┌─────────────┐ ┌──────────────┐ │ │ │ think() │ │ act() │ │ │ │ 分配下一个 │ │ 执行当前 │ │ │ │ 动作 │ │ 动作 │ │ │ └─────────────┘ └──────────────┘ │ │ │ └─────────────────────────────────────┘2. 关键属性self.actions # 动作列表 [Action1, Action2, ...] self.states # 状态列表 ['0. Action1', '1. Action2', ...] self.rc.state # 当前状态索引 (int) self.rc.todo # 当前要执行的动作 (Action 对象或 None)3. 状态转换# _set_state() 方法的作用 def _set_state(self, state: int): self.rc.state = state self.rc.todo = self.actions[state] if state >= 0 else None状态值含义：state = -1 → 无任务，todo = Nonestate = 0 → 执行第一个动作，todo = actions[0]state = 1 → 执行第二个动作，todo = actions[1]以此类推...完整实现Step 1: 定义 Action 类from metagpt.actions import Action from metagpt.logs import logger class PrintAction(Action): """简单的打印动作 Args: name: 动作名称 content: 要打印的内容 """ name: str = "PrintAction" content: str = "" async def run(self, *args, **kwargs) -> str: """执行打印操作""" logger.info(f"执行 {self.name}: {self.content}") return self.content关键点：继承自 Action 基类run() 方法必须是 async（因为可能调用 LLM）返回执行结果（字符串）Step 2: 定义 Agent 类框架from metagpt.roles.role import Role, RoleReactMode from metagpt.schema import Message class SimpleAgent(Role): """简单的顺序执行 Agent Args: name: 角色名称 profile: 角色描述 """ name: str = "SimpleAgent" profile: str = "Simple Sequential Agent" phase: int = 1 # 当前阶段（1 或 2） def __init__(self, **kwargs): super().__init__(**kwargs) # 初始化第一阶段的三个动作 action1 = PrintAction(content="1") action2 = PrintAction(content="2") action3 = PrintAction(content="3") self._init_actions([action1, action2, action3]) self._set_react_mode(react_mode=RoleReactMode.REACT.value)关键点：phase 属性用于追踪当前阶段_init_actions() 将动作列表存入 self.actions_set_react_mode() 设置为 REACT 模式（自定义 react 逻辑）Step 3: 实现 _think() 方法async def _think(self) -> None: """决定下一个要执行的动作""" logger.info(f"{self._setting}: thinking about the next action to take") # 情况 1: 刚开始或刚切换阶段，从第 0 个动作开始 if self.rc.todo is None: self._set_state(0) return # 情况 2: 还有下一个动作，移动到下一个 if self.rc.state + 1 < len(self.states): self._set_state(self.rc.state + 1) # 情况 3: 所有动作执行完毕，设为 None（停止信号） else: self.rc.todo = None逻辑流程：┌─────────────────────────┐ │ todo is None? │ │ (刚开始或刚切换阶段) │ └──────┬──────────────────┘ │ Yes ↓ ┌─────────────────────────┐ │ _set_state(0) │ │ state=0, todo=actions[0]│ └─────────────────────────┘ │ No ↓ ┌─────────────────────────┐ │ state+1 < len(states)? │ │ (还有下一个动作吗) │ └──────┬──────────────────┘ │ Yes ↓ ┌─────────────────────────┐ │ _set_state(state+1) │ │ 移动到下一个动作 │ └─────────────────────────┘ │ No ↓ ┌─────────────────────────┐ │ todo = None │ │ (所有动作完成) │ └─────────────────────────┘Step 4: 实现 _act() 方法async def _act(self) -> Message: """执行当前动作""" todo = self.rc.todo logger.info(f"{self._setting}: executing {todo.name}") # 执行当前动作 result = await todo.run() # 检测阶段切换条件 if self.phase == 1 and self.rc.state == 2: logger.info("========== 第一阶段完成，准备进入第二阶段 ==========") self._switch_to_phase_2() return Message(content=result, role=self.name)关键点：todo = self.rc.todo 获取当前动作对象await todo.run() 执行动作（多态调用）执行完后检测是否需要切换阶段返回 Message 对象包装结果为什么 todo.run() 会调用 PrintAction.run()？# 对象引用追踪： action1 = PrintAction(content="1") # 创建 PrintAction 实例 ↓ self.actions = [action1, ...] # 存入列表（存的是引用） ↓ self.rc.todo = self.actions[0] # todo 指向 action1 ↓ todo = self.rc.todo # todo 指向同一个 PrintAction 对象 ↓ todo.run() # Python 根据对象类型调用 PrintAction.run()Step 5: 实现阶段切换方法def _switch_to_phase_2(self) -> None: """切换到第二阶段""" logger.info("创建第二阶段的动作: Print4, Print5, Print6") # 更新阶段标志 self.phase = 2 # 创建新的动作 action4 = PrintAction(content="4") action5 = PrintAction(content="5") action6 = PrintAction(content="6") # 替换动作列表 self._init_actions([action4, action5, action6]) # 重置 todo，让下次 _think() 重新开始 self.rc.todo = None logger.info("第二阶段动作已准备就绪")关键点：为什么用 _init_actions() 而不是 append()？_init_actions() 会替换整个 self.actions 列表这样第二阶段就只有 Print4, 5, 6，而不是 1-6 全部为什么要设置 self.rc.todo = None？让我们对比两种方案：❌ 错误方案：使用 _set_state(0)def _switch_to_phase_2(self): self._init_actions([...]) self._set_state(0) # state=0, todo=actions[0] # 执行流程： # 1. 返回 _react() 循环 # 2. 下次 _think() 被调用 # 3. if self.rc.todo is None: → False（todo 已经是 actions[0]） # 4. if self.rc.state + 1 < len(self.states): → True (0+1 < 3) # 5. self._set_state(1) → 跳过了 Print4，直接执行 Print5！✓ 正确方案：使用 self.rc.todo = Nonedef _switch_to_phase_2(self): self._init_actions([...]) self.rc.todo = None # 重置为 None # 执行流程： # 1. 返回 _react() 循环 # 2. 下次 _think() 被调用 # 3. if self.rc.todo is None: → True # 4. self._set_state(0) → state=0, todo=actions[0] (Print4) # 5. 正确从 Print4 开始执行！Step 6: 实现 _react() 方法async def _react(self) -> Message: """循环执行 think 和 act""" msg = None while True: # 思考下一步 await self._think() # 检查是否所有任务完成 if self.rc.todo is None: break # 执行当前任务 msg = await self._act() return msg执行流程：开始 ↓ ┌───────────────┐ │ msg = None │ └───────┬───────┘ ↓ ┌───────────────┐ │ while True: │ └───┬───────────┘ ↓ ┌───────────────┐ │ _think() │ ← 决定下一个动作 └───┬───────────┘ ↓ ┌───────────────┐ │ todo is None? │ └───┬───────────┘ │ Yes → break │ No ↓ ┌───────────────┐ │ msg = _act() │ ← 执行动作 └───┬───────────┘ │ └──→ 循环 返回 msgStep 7: 测试代码import asyncio async def main(): """测试函数""" logger.info("========== 开始测试 ==========") # 创建 Agent agent = SimpleAgent() # 运行 Agent result = await agent.run("开始执行") logger.info(f"========== 全部完成，最终结果: {result} ==========") if __name__ == "__main__": asyncio.run(main())执行流程详解完整执行时间线时刻 T1: 初始化 ├─ actions = [Print1, Print2, Print3] ├─ states = ['0. PrintAction', '1. PrintAction', '2. PrintAction'] ├─ state = -1 ├─ todo = None └─ phase = 1 ───────────────────────────────────────── 时刻 T2: run("开始执行") └─ 调用 react() ───────────────────────────────────────── 时刻 T3: 第 1 次循环 ├─ _think() │ └─ todo is None → _set_state(0) │ ├─ state = 0 │ └─ todo = actions[0] (Print1) ├─ _act() │ └─ 执行 PrintAction: 1 ───────────────────────────────────────── 时刻 T4: 第 2 次循环 ├─ _think() │ └─ state+1 < 3 → _set_state(1) │ ├─ state = 1 │ └─ todo = actions[1] (Print2) ├─ _act() │ └─ 执行 PrintAction: 2 ───────────────────────────────────────── 时刻 T5: 第 3 次循环 ├─ _think() │ └─ state+1 < 3 → _set_state(2) │ ├─ state = 2 │ └─ todo = actions[2] (Print3) ├─ _act() │ ├─ 执行 PrintAction: 3 │ └─ 检测到 phase==1 and state==2 │ └─ _switch_to_phase_2() │ ├─ phase = 2 │ ├─ actions = [Print4, Print5, Print6] │ └─ todo = None ───────────────────────────────────────── 时刻 T6: 第 4 次循环 ├─ _think() │ └─ todo is None → _set_state(0) │ ├─ state = 0 │ └─ todo = actions[0] (Print4) ├─ _act() │ └─ 执行 PrintAction: 4 ───────────────────────────────────────── 时刻 T7: 第 5 次循环 ├─ _think() │ └─ state+1 < 3 → _set_state(1) │ ├─ state = 1 │ └─ todo = actions[1] (Print5) ├─ _act() │ └─ 执行 PrintAction: 5 ───────────────────────────────────────── 时刻 T8: 第 6 次循环 ├─ _think() │ └─ state+1 < 3 → _set_state(2) │ ├─ state = 2 │ └─ todo = actions[2] (Print6) ├─ _act() │ └─ 执行 PrintAction: 6 ───────────────────────────────────────── 时刻 T9: 第 7 次循环 ├─ _think() │ └─ state+1 < 3 → False │ └─ todo = None └─ todo is None → break ───────────────────────────────────────── 返回结果: SimpleAgent: 6关键技术点1. Python 对象引用在 Python 中，变量是"标签"而不是"盒子"：# 创建对象 action1 = PrintAction(content="1") # 多个变量可以指向同一个对象 self.actions[0] = action1 # 指向同一对象 self.rc.todo = action1 # 指向同一对象 todo = action1 # 指向同一对象 # 验证（id 相同说明是同一对象） id(self.actions[0]) == id(self.rc.todo) == id(todo) # True2. 多态（Polymorphism）# _act() 方法不需要知道 todo 的具体类型 async def _act(self): todo = self.rc.todo # 可能是任何 Action 子类 result = await todo.run() # Python 会自动找到对应类的 run() 方法 # 当 todo 是 PrintAction 时 → 调用 PrintAction.run() # 当 todo 是 WriteDirectory 时 → 调用 WriteDirectory.run() # 这就是"面向接口编程"3. async/await 使用规则# ✓ 需要 async（函数内有 await） async def _act(self): result = await todo.run() # ← 有 await return result # ✓ 不需要 async（函数内无 await） def _switch_to_phase_2(self): self.phase = 2 # ← 没有 await self._init_actions([...])记忆法则：函数内有 await → 必须用 async def调用 async def 函数 → 必须用 await4. 状态重置的重要性# 在动态创建 actions 后，必须重置 todo self._init_actions([新动作...]) self.rc.todo = None # ← 关键：让 _think() 重新评估 # 为什么不用 _set_state(0)？ # 因为会导致 _think() 判断错误，跳过第一个动作完整代码from metagpt.actions import Action from metagpt.logs import logger from metagpt.roles.role import Role, RoleReactMode from metagpt.schema import Message import asyncio class PrintAction(Action): """简单的打印动作""" name: str = "PrintAction" content: str = "" async def run(self, *args, **kwargs) -> str: logger.info(f"执行 {self.name}: {self.content}") return self.content class SimpleAgent(Role): """简单的顺序执行 Agent""" name: str = "SimpleAgent" profile: str = "Simple Sequential Agent" phase: int = 1 def __init__(self, **kwargs): super().__init__(**kwargs) action1 = PrintAction(content="1") action2 = PrintAction(content="2") action3 = PrintAction(content="3") self._init_actions([action1, action2, action3]) self._set_react_mode(react_mode=RoleReactMode.REACT.value) async def _think(self) -> None: """决定下一个要执行的动作""" logger.info(f"{self._setting}: thinking about the next action to take") if self.rc.todo is None: self._set_state(0) return if self.rc.state + 1 < len(self.states): self._set_state(self.rc.state + 1) else: self.rc.todo = None async def _act(self) -> Message: """执行当前动作""" todo = self.rc.todo logger.info(f"{self._setting}: executing {todo.name}") result = await todo.run() if self.phase == 1 and self.rc.state == 2: logger.info("========== 第一阶段完成，准备进入第二阶段 ==========") self._switch_to_phase_2() return Message(content=result, role=self.name) def _switch_to_phase_2(self) -> None: """切换到第二阶段""" logger.info("创建第二阶段的动作: Print4, Print5, Print6") self.phase = 2 action4 = PrintAction(content="4") action5 = PrintAction(content="5") action6 = PrintAction(content="6") self._init_actions([action4, action5, action6]) self.rc.todo = None logger.info("第二阶段动作已准备就绪") async def _react(self) -> Message: """循环执行 think 和 act""" msg = None while True: await self._think() if self.rc.todo is None: break msg = await self._act() return msg async def main(): logger.info("========== 开始测试 ==========") agent = SimpleAgent() result = await agent.run("开始执行") logger.info(f"========== 全部完成，最终结果: {result} ==========") if __name__ == "__main__": asyncio.run(main())常见问题Q1: 为什么要用 _react() 循环而不是递归？答：循环更高效（避免栈溢出）更容易控制（可以随时 break）符合 MetaGPT 的设计模式Q2: 可以在 __init__ 中就初始化所有 6 个动作吗？答：可以，但失去了动态性：# 静态方案（不推荐） self._init_actions([Print1, Print2, Print3, Print4, Print5, Print6]) # 动态方案（推荐） # 初始只有 Print1-3，运行时根据条件创建 Print4-6动态方案的优势：更灵活（可以根据第一阶段的结果决定第二阶段）模拟真实场景（如 TutorialAssistant 根据大纲动态创建章节）Q3: _set_state() 和直接赋值 self.rc.state = n 有什么区别？答：# ✓ 推荐：使用方法 self._set_state(0) # 同时更新 state 和 todo # ❌ 不推荐：直接赋值 self.rc.state = 0 # 只更新 state，todo 还是旧的_set_state() 确保 state 和 todo 同步更新。Q4: 如何添加第三阶段？答：在 _act() 中添加新的检测条件：async def _act(self) -> Message: todo = self.rc.todo result = await todo.run() # 第一阶段 → 第二阶段 if self.phase == 1 and self.rc.state == 2: self._switch_to_phase_2() # 第二阶段 → 第三阶段 elif self.phase == 2 and self.rc.state == 2: self._switch_to_phase_3() return Message(content=result, role=self.name) def _switch_to_phase_3(self) -> None: self.phase = 3 action7 = PrintAction(content="7") action8 = PrintAction(content="8") action9 = PrintAction(content="9") self._init_actions([action7, action8, action9]) self.rc.todo = None进阶扩展扩展 1: 使用 LLM 决定下一阶段async def _act(self) -> Message: todo = self.rc.todo result = await todo.run() if self.phase == 1 and self.rc.state == 2: # 询问 LLM 下一步要做什么 prompt = "第一阶段完成了，请决定第二阶段要执行哪些动作，返回 JSON 格式" response = await self._aask(prompt) # 解析 LLM 返回的 JSON next_actions = self._parse_llm_response(response) self._switch_to_dynamic_phase(next_actions) return Message(content=result, role=self.name)扩展 2: 条件分支async def _act(self) -> Message: todo = self.rc.todo result = await todo.run() if self.phase == 1 and self.rc.state == 2: # 根据第一阶段的结果选择分支 if int(result) % 2 == 0: self._switch_to_phase_2A() # 偶数分支 else: self._switch_to_phase_2B() # 奇数分支 return Message(content=result, role=self.name)扩展 3: 循环执行def _switch_to_phase_2(self) -> None: self.phase = 2 # 创建更多动作 actions = [] for i in range(4, 10): # Print4 到 Print9 actions.append(PrintAction(content=str(i))) self._init_actions(actions) self.rc.todo = None总结通过本教程，你已经掌握了：MetaGPT 的 React 循环机制run → react → think → act 的完整流程状态管理（state, todo, actions）动态 Action 创建在运行时根据条件创建新 actions使用 _init_actions() 替换动作列表通过 self.rc.todo = None 重置状态Python 核心概念对象引用与多态async/await 正确使用状态机设计模式实践技巧如何调试 Agent 执行流程如何避免常见错误如何扩展功能核心要点：_think() 负责决定下一个动作（状态转换）_act() 负责执行动作并处理副作用（如阶段切换）_react() 负责循环驱动整个流程动态创建后必须重置 todo 为 None参考资源MetaGPT 官方文档MetaGPT GitHubPython asyncio 文档
概述本文记录了在部署和使用 SWE-smith（一个用于生成软件工程任务的工具）过程中遇到的各种技术问题及其解决方案。SWE-smith 是一个复杂的系统，涉及多个组件：bug生成、验证、收集、issue生成等。遇到的问题与解决方案1. Git推送权限问题问题描述：在执行 python -m swesmith.harness.gather 命令时，遇到以下错误：subprocess.CalledProcessError: Command 'git push origin catchorg__Catch2.9b3f508a.func_pm_ctrl_invert_if__7p0kyikq' returned non-zero exit status 128. ERROR: Permission to swesmith/catchorg__Catch2.9b3f508a.git denied to fredsun02.根本原因：原始代码配置将镜像仓库创建在 swesmith 组织下当前用户的GitHub Token没有推送到该组织的权限用户 fredsun02 不在 swesmith 组织中解决方案：修改 swesmith/constants.py 文件中的组织配置：# 原来 ORG_NAME_GH = "swesmith" # 修改为 ORG_NAME_GH = "fredsun02"这样所有镜像仓库都会创建在用户的个人GitHub账户下，避免了组织权限问题。2. 内存不足问题问题描述：在执行issue生成时，系统内存不足导致进程被杀死：exit code 137 # 通常表示内存不足根本原因：系统只有1.9GB内存代码尝试加载大型数据集（SWE-bench_Verified、SWE-bench/SWE-smith）本地模型加载需要大量内存解决方案：2.1 使用API替代本地模型创建简化的配置文件 configs/issue_gen/ig_api.yaml：model: anthropic/claude-3-5-sonnet-20241022 system: |- You are a software engineer helping to create a realistic dataset of synthetic GitHub issues. # ... 系统提示词 demonstration: "" # 不使用演示数据2.2 优化代码逻辑修改 swesmith/issue_gen/generate.py：延迟加载 SWE-bench_Verified 数据集只在需要时才加载大型数据集对于本地数据集，跳过不必要的过滤3. 包版本兼容性问题问题描述：ImportError: cannot import name 'ResponseTextConfig' from 'openai.types.responses.response'根本原因：litellm 和 openai 包版本不兼容解决方案：升级相关包到兼容版本：pip install --upgrade openai litellm4. 代码导入错误问题描述：在运行静态issue生成时遇到导入错误：ImportError: cannot import name 'PM_TECHNIQUES_CLASSES' from 'swesmith.bug_gen.procedural.generate'根本原因：代码中引用了不存在的常量解决方案：修改 swesmith/issue_gen/get_static.py：# 原来 from swesmith.bug_gen.procedural.generate import ( PM_TECHNIQUES_CLASSES, PM_TECHNIQUES_FUNCS, ) # 修改为 from swesmith.bug_gen.procedural import MAP_EXT_TO_MODIFIERS5. 函数参数错误问题描述：在运行F2P方法时遇到函数调用错误：TypeError: run_command_in_container() missing 1 required positional argument: 'rp'解决方案：修复 swesmith/issue_gen/get_from_tests.py 中的函数调用：# 原来 test_output = run_command_in_container(instance, cmd) # 修改为 test_output = run_command_in_container(instance, cmd, rp)最终工作流程经过修复后，完整的SWE-smith工作流程如下：Bug生成 ✅python -m swesmith.bug_gen.procedural.generate --repo catchorg/Catch2 --n_instances 10验证 ✅python -m swesmith.harness.validate --dataset_path logs/bug_gen/catchorg__Catch2.9b3f508a_all_patches.json收集补丁 ✅python -m swesmith.harness.gather logs/run_validation/catchorg__Catch2.9b3f508a/ --debug_subprocessIssue生成 ✅API方法：python -m swesmith.issue_gen.generate -d logs/task_insts/catchorg__Catch2.9b3f508a.json -c configs/issue_gen/ig_api.yaml -w 1静态方法：python -m swesmith.issue_gen.get_static logs/task_insts/catchorg__Catch2.9b3f508a.jsonF2P方法：python -m swesmith.issue_gen.get_from_tests logs/task_insts/catchorg__Catch2.9b3f508a.json技术要点总结1. 权限管理在多人协作的项目中，确保GitHub Token有足够的权限考虑使用个人账户而非组织账户来避免权限复杂性2. 资源优化对于内存受限的环境，优先使用API而非本地模型实现延迟加载和按需加载来减少内存使用3. 版本兼容性定期更新依赖包以保持兼容性在部署前测试所有依赖的版本组合4. 代码维护及时修复过时的导入和函数调用保持文档与代码的同步成本分析使用API方法的成本：处理9个实例总成本：约$0.152平均每个实例：约$0.017结论通过系统性的问题诊断和解决，我们成功部署了SWE-smith系统。主要挑战集中在权限管理、资源优化和代码兼容性方面。这些解决方案为类似项目的部署提供了有价值的参考。最终，我们成功生成了：10个bug分支并推送到GitHub9个高质量的GitHub issue完整的任务实例数据集这个经验表明，在部署复杂的AI系统时，需要综合考虑技术、权限、资源和成本等多个方面。
本文详细记录了针对 DeepSeek-Coder-7B-base-v1.5 模型，结合 HuatuoGPT 医疗对话数据进行 SFT（Supervised Fine-Tuning） 的全过程。记录从最初设计到逐步调试的每一步，包括所做的改动、背后的原因、遇到的问题、解决方案以及最终结果。1. 项目背景与目标本次任务的目标是：首先加载基模型，在这个项目中基模型为 DeepSeek-Coder-7B-base-v1.5 。加载已有的 LoRA checkpoint（checkpoint-2000），在此基础上继续微调。使用 FreedomIntelligence/HuatuoGPT-sft-data-v1 医疗对话数据集进行监督微调（SFT）。在保证显存可控的前提下，提高训练稳定性，并支持长时间后台运行与实时日志监控。这意味着我们需要解决以下几个核心问题：如何正确加载已有 LoRA 权重。如何兼容 HuatuoGPT 数据集的格式。如何避免训练过程中断（例如显存溢出、端口冲突、网络卡顿等）。如何高效地监控和管理训练进程。2. 初始脚本编写起初，我们基于已有的 supervised_finetuning.py 编写了一个 run_sft_deepseek_huatuo.sh 脚本：模型指定为 deepseek-ai/deepseek-coder-7b-base-v1.5。LoRA 权重路径指定为 outputs-pt-deepseek-huatuo-qlora/checkpoint-2000。数据集名称为 FreedomIntelligence/HuatuoGPT-sft-data-v1。开启 FlashAttention（--flash_attn True）、混合精度（--bf16）、梯度累积（--gradient_accumulation_steps 4）。使用 HuggingFace 镜像源 https://hf-mirror.com 加速。然而第一次运行时就遇到了两个问题：路径错误：脚本中调用 MedicalGPT/supervised_finetuning.py，在 MedicalGPT 目录下运行时会被解释为 MedicalGPT/MedicalGPT/supervised_finetuning.py，导致找不到文件。显存压力过大：per_device_train_batch_size 初始设为 12，对于 7B 模型来说过大，容易 OOM。解决方案：修正调用路径为 supervised_finetuning.py。将 batch size 调整为 2，梯度累积保留为 4，使有效 batch size 约为 16，兼顾显存与训练效率。3. 后台运行与日志管理为了支持长时间训练，我们将脚本改造成 nohup 后台运行 的形式，并自动生成带时间戳的日志文件。这样做的原因：训练过程会持续数小时到十几小时，若直接前台运行容易因 SSH 断开或终端关闭而中断。有了持久化日志，可以随时用 tail -f 查看训练进度，方便调试。新增功能：在 logs/ 目录下创建 sft_training_YYYYMMDD_HHMMSS.log。保存训练进程 PID 到文件，便于后续手动终止。在训练启动时打印配置信息（模型、数据集、LoRA 权重路径等）。4. 训练卡在 Tokenizer 加载阶段首次在后台运行时发现：日志停留在 Tokenizer 加载完成处，长达两分钟无任何新输出。GPU 显存占用极低（仅 779MB）。这意味着模型加载完成后，程序卡在了下一步——数据集下载阶段。由于默认从 HuggingFace 下载，网络延迟导致阻塞。解决方案：提前手动下载数据集，确保本地已有数据文件。设置环境变量切换到 HuggingFace 镜像源：export HF_ENDPOINT=https://hf-mirror.com确认下载目录缓存位置（HF_DATASETS_CACHE）与训练脚本一致。结果：重新运行后，不再卡在数据集下载阶段。5. 分布式端口冲突第二次运行出现错误：EADDRINUSE: address already in use原因是之前一次中断的 torchrun 分布式进程仍占用通信端口。解决方案：手动清理残留进程：pkill -f supervised_finetuning.py再次确认 torchrun 不会复用相同端口。结果：端口冲突问题解决。6. 数据集字段不匹配进入训练后，出现新的错误：KeyError: 'conversations'原来脚本预处理逻辑默认数据集中有 conversations 字段，而 HuatuoGPT 实际格式为：{ "data": ["问：...", "答：..."] }解决方案：修改 preprocess_function，支持 data 与 conversations 两种格式：if 'data' in examples: conversations_data = examples['data'] elif 'conversations' in examples: conversations_data = examples['conversations'] else: raise ValueError("数据格式不支持，需要包含'data'或'conversations'字段")结果：数据预处理不再报错，HuatuoGPT 数据可直接用于训练。7. GPU 内存优化检查为防止长时间运行中出现显存不足问题，我们在 supervised_finetuning.py 中加入 check_and_optimize_memory() 方法：输出每块 GPU 的总内存、已分配、已缓存、可用容量。启用 Flash SDP 与 Memory Efficient SDP。在模型加载完成后立即调用，确保优化生效。结果：在多 GPU 环境下显存利用率更均衡，避免了单卡负载过重。8. 最终运行结果与特性总结8.1 运行配置模型：DeepSeek-Coder-7B-base-v1.5LoRA 权重：outputs-pt-deepseek-huatuo-qlora/checkpoint-2000数据集：HuatuoGPT-sft-data-v1（22.6 万条医疗对话）batch size：2（梯度累积 4）精度：bf16优化：FlashAttention + gradient checkpointing8.2 新增特性nohup 后台运行，不中断训练。日志持久化，支持实时查看与历史回溯。数据格式自适应，兼容 data 与 conversations。GPU 内存检查与优化。HuggingFace 镜像源支持，避免下载卡顿。8.3 收获数据格式适配是保证脚本通用性的关键。分布式训练前必须清理旧进程，避免端口冲突。后台运行与日志管理是长时间任务的必备条件。手动下载数据集可以显著减少初始化等待时间。在大模型训练中，显存优化直接关系到任务能否稳定完成。9. 后续改进方向增加断点续训功能，在中断后无需重新加载与预处理数据。为不同数据集类型编写独立的预处理模块，减少通用函数的复杂度。引入分布式监控工具（如 WandB）进行可视化追踪。我来为您补充训练完成后的部分，记录完整的训练过程和最终结果：10. 训练执行与优化过程10.1 训练参数调整在成功解决数据格式和环境配置问题后，我们对训练参数进行了进一步优化：批次大小优化：初始设置：per_device_train_batch_size = 2最终优化：per_device_train_batch_size = 4梯度累积：gradient_accumulation_steps = 4有效批次大小：16全量训练配置：# 移除样本限制，使用全量数据集 # --max_train_samples 10000 # 已删除 # --max_eval_samples 500 # 已删除 # 优化后的配置 --per_device_train_batch_size 4 --per_device_eval_batch_size 4 --num_train_epochs 2 --learning_rate 1e-5 --save_steps 1000 --eval_steps 20010.2 实时监控与日志管理为了在长时间训练中保持监控能力，我们实现了双重日志系统：创建 run_sft_full_with_log.sh：# 使用tee命令同时输出到终端和日志文件 CUDA_VISIBLE_DEVICES=0 python supervised_finetuning.py \ [训练参数...] \ 2>&1 | tee "$LOG_FILE"特性：实时终端显示训练进度后台保存完整日志到 logs/sft_full_training_YYYYMMDD_HHMMSS.log支持 SSH 断线后重连查看TensorBoard 可视化支持10.3 核心技术问题解决数据格式转换：在 supervised_finetuning.py 中添加了智能格式检测和转换：# 检测并转换HuatuoGPT格式 if "data" in raw_datasets["train"].column_names and "conversations" not in raw_datasets["train"].column_names: logger.info("检测到HuatuoGPT格式数据，进行格式转换...") def convert_huatuo_to_conversations(examples): conversations_list = [] for data_item in examples['data']: if isinstance(data_item, list) and len(data_item) >= 2: conversations = [ {"from": "human", "value": data_item[0].replace('问：', '').strip()}, {"from": "gpt", "value": data_item[1].replace('答：', '').strip()} ] conversations_list.append(conversations) return {"conversations": conversations_list}模型加载优化：修复了量化加载的条件判断，确保模型在各种配置下都能正确初始化：# 修复UnboundLocalError if load_in_8bit or load_in_4bit: # 量化加载逻辑 model = AutoModelForCausalLM.from_pretrained(...) else: # 非量化加载逻辑 model = AutoModelForCausalLM.from_pretrained(...)11. 训练执行过程11.1 训练启动2025年8月10日 21:54:43 开始全量训练：🚀 启动DeepSeek HuatuoGPT 全量SFT训练 📊 训练配置: 模型: deepseek-ai/deepseek-coder-7b-base-v1.5 数据集: FreedomIntelligence/HuatuoGPT-sft-data-v1 (全量) PEFT路径: outputs-pt-deepseek-huatuo-qlora/checkpoint-2000 Batch Size: 4 (per device) 训练轮数: 2 epochs 学习率: 1e-511.2 训练过程监控训练进度表现：总步数：27,974 steps训练样本：223,781 个医疗对话验证样本：2,261 个平均每步耗时：2.3-2.8秒Loss 下降趋势：初始 Loss：~1.82中期 Loss：~1.65 (epoch 0.5)后期 Loss：~1.52 (epoch 1.5-2.0)最终训练 Loss：1.5231最终验证 Loss：1.5198学习率调度：采用线性 warmup (5% 步数)余弦退火调度最终学习率衰减至接近 012. 训练完成与结果分析12.1 最终训练指标2025年8月11日 19:27:41 训练成功完成：***** 最终训练结果 ***** 训练时长 : 21小时29分45秒 总样本数 : 223,781 完成轮数 : 2.0 epochs 训练Loss : 1.5231 验证Loss : 1.5198 困惑度(Perplexity): 4.5712 训练速度 : 5.784 samples/sec 计算量 : 5.8×10¹⁸ FLOPs12.2 性能分析收敛性表现：✅ 训练Loss稳定下降，无明显震荡✅ 验证Loss与训练Loss接近，无过拟合迹象✅ 梯度范数稳定在0.6-0.8之间，训练稳定✅ 学习率调度正常，实现平滑收敛效率指标：GPU利用率：持续高效运行21.5小时内存管理：单卡运行，最大显存占用约20GB数据吞吐：平均2.3秒/步，效率良好磁盘I/O：日志文件193,265行，完整记录训练过程12.3 模型输出保存结构：outputs-sft-deepseek-huatuo-full/ ├── adapter_config.json # LoRA配置 ├── adapter_model.safetensors # LoRA权重 ├── training_args.bin # 训练参数 ├── trainer_state.json # 训练状态 ├── tokenizer_config.json # 分词器配置 └── runs/ # TensorBoard日志检查点管理：每1000步保存一次检查点保留最近5个检查点（save_total_limit=5）最终模型包含完整的LoRA适配器权重13. 技术创新与解决方案总结13.1 关键技术突破1. 数据格式自适应：实现了HuatuoGPT特有格式到标准对话格式的自动转换支持["问：...", "答：..."]到{"from": "human/gpt", "value": "..."}的映射保证了代码的通用性和数据集兼容性2. 分布式训练优化：解决了多GPU环境下的端口冲突问题实现了单GPU高效训练，避免了分布式通信开销通过梯度累积实现了大批次效果3. 内存管理优化：FlashAttention减少内存占用bfloat16混合精度训练梯度检查点技术动态内存监控和优化13.2 工程实践创新1. 日志系统设计：# 双重输出设计 python training_script.py 2>&1 | tee log_file.log实时终端显示 + 持久化日志保存支持SSH断线后的训练恢复监控时间戳命名，便于历史追溯2. 环境配置管理：export HF_ENDPOINT=https://hf-mirror.com export TRANSFORMERS_CACHE=/root/autodl-tmp/huggingface镜像源自动切换统一缓存目录管理网络优化配置3. 错误处理机制：进程冲突自动检测和清理数据格式兼容性检查显存优化自动启用14. 效果评估与应用价值14.1 训练效果分析定量指标：困惑度从预训练的未知基线降至4.57，表明模型对医疗对话的理解显著提升Loss收敛平稳，最终验证集Loss 1.5198接近训练集Loss 1.5231，无过拟合全量数据集训练确保了模型对医疗领域知识的充分学习定性改进：基于预训练LoRA权重继续训练，保持了代码理解能力结合医疗对话数据，增强了在医疗咨询场景的应用能力保持了DeepSeek模型的原有优势，同时获得了医疗专业性14.2 工程价值可复现性：完整的脚本和配置文件详细的错误处理和解决方案记录标准化的日志格式和监控方式可扩展性：数据格式适配器可支持更多数据集训练脚本可适配不同规模的模型日志系统可集成到更大的训练平台生产就绪：长时间稳定训练验证完善的错误恢复机制资源使用优化15. 后续优化与发展方向15.1 技术改进1. 多GPU分布式优化：解决GPU检测重复问题实现真正的多卡并行训练进一步提升训练效率2. 断点续训功能：# 计划实现 --resume_from_checkpoint outputs-sft-deepseek-huatuo-full/checkpoint-10003. 评估体系完善：医疗专业知识问答评估对话质量人工评估与基准模型的对比测试15.2 应用拓展1. 模型合并与部署：# 合并LoRA权重到基础模型 from peft import PeftModel base_model = AutoModelForCausalLM.from_pretrained("deepseek-ai/deepseek-coder-7b-base-v1.5") model = PeftModel.from_pretrained(base_model, "outputs-sft-deepseek-huatuo-full") merged_model = model.merge_and_unload()2. 服务化部署：FastAPI接口封装流式输出支持并发请求处理3. 领域扩展：法律咨询对话训练教育问答系统训练客服对话系统训练16. 总结与反思这次DeepSeek模型的医疗SFT训练项目，从技术实现到工程实践都获得了宝贵经验：技术层面：掌握了大模型LoRA微调的完整流程解决了数据格式适配、分布式训练、内存优化等关键问题建立了稳定的长时间训练管道工程层面：构建了可复现、可监控、可扩展的训练系统形成了标准化的错误处理和解决方案积累了生产环境下的实践经验项目管理层面：通过详细的问题记录和解决过程，建立了知识积累体系形成了系统性的技术文档，便于团队协作和知识传承验证了从问题定义到解决方案落地的完整流程这个项目不仅成功完成了预定目标，更重要的是建立了一套可重复、可扩展的大模型微调方法论，为后续的AI模型训练项目奠定了坚实基础。最终成果：✅ 成功完成223,781样本的全量训练✅ 获得了专业的医疗对话模型✅ 建立了完整的训练工程体系✅ 形成了丰富的技术文档和经验积累这标志着我们在大模型微调领域又迈出了重要一步，为AI在垂直领域的应用探索提供了有价值的实践案例。
HealthBench评估系统配置实战：从零到完整部署
📋 项目概述本文记录了一次完整的医疗AI模型评估系统搭建过程，涉及将自训练的Medical GPT模型接入HealthBench评估框架，并使用DeepSeek Chat作为评分器的完整技术实现。技术栈：评估框架：simple-evals + HealthBench被评估模型：DeepSeek Coder 7B + QLoRA微调 (Medical GPT)评分模型：DeepSeek Chat (DeepSeek-V3)环境：AutoDL GPU实例🎯 项目目标将自训练的Medical GPT模型集成到HealthBench评估框架使用DeepSeek Chat替换默认的ChatGPT作为评分器解决网络、存储、设备兼容等部署问题实现完整的5000样本医疗问答评估⏰ 问题解决时间线阶段1：基础配置 (开始)目标：修改评估框架的grader配置问题：默认使用ChatGPT作为评分器，需要改为DeepSeek Chat解决方案：# 修改 simple-evals/simple_evals.py from .sampler.deepseek_sampler import DeepSeekSampler grading_sampler = DeepSeekSampler( model="deepseek-chat", system_message=OPENAI_SYSTEM_MESSAGE_API, max_tokens=2048, api_key="sk-12b18b7378704e04808393500473ec14", )添加Medical GPT模型到可用模型列表：# 在models字典中添加 "medical-gpt": MedicalGPTSampler( base_model_path="deepseek-ai/deepseek-coder-7b-base-v1.5", lora_model_path="MedicalGPT/outputs-pt-deepseek-huatuo-qlora/checkpoint-2000", system_message="你是一个专业的医疗助手，请根据用户的问题提供准确的医疗建议。", temperature=0.7, max_new_tokens=512, ),阶段2：Azure数据访问问题 (30分钟后)问题：HealthBench尝试从Azure Blob存储下载数据失败Could not find any credentials that grant access to storage account: 'openaipublic'解决方案：直接下载数据到本地mkdir -p /root/autodl-tmp/healthbench_data wget "https://openaipublic.blob.core.windows.net/simple-evals/healthbench/2025-05-07-06-14-12_oss_eval.jsonl" -O healthbench_main.jsonl修改代码使用本地文件：# 修改 healthbench_eval.py INPUT_PATH = "/root/autodl-tmp/healthbench_data/healthbench_main.jsonl" # 添加本地文件处理逻辑 if input_path.startswith("http"): with bf.BlobFile(input_path, "rb") as f: examples = [json.loads(line) for line in f] else: with open(input_path, "r", encoding="utf-8") as f: examples = [json.loads(line) for line in f]阶段3：模型加载网络问题 (1小时后)问题：HuggingFace连接超时，无法下载模型文件HTTPSConnectionPool(host='huggingface.co', port=443): Max retries exceeded发现：数据盘已有完整的DeepSeek模型缓存解决方案：配置使用本地模型class MedicalGPTSampler(SamplerBase): def __init__(self, use_local_cache: bool = True, ...): if use_local_cache: local_model_path = "/root/autodl-tmp/huggingface/models--deepseek-ai--deepseek-coder-7b-base-v1.5/snapshots/98f0904cee2237e235f10408ae12292037b21dac" if os.path.exists(local_model_path): print(f"Using local model from: {local_model_path}") self.base_model_path = local_model_path阶段4：系统盘空间不足 (1.5小时后)问题：模型下载到系统盘导致空间不足Not enough free disk space to download the file. The expected file size is: 3852.62 MB. The target location /root/.cache/huggingface only has 3365.43 MB free disk space.解决方案：设置HuggingFace镜像源和缓存路径export HF_ENDPOINT=https://hf-mirror.com export HF_HOME=/root/autodl-tmp/huggingface_cache export TRANSFORMERS_CACHE=/root/autodl-tmp/huggingface_cache阶段5：Chat Template缺失 (2小时后)问题：DeepSeek Coder模型缺少chat templateCannot use chat template functions because tokenizer.chat_template is not set根因分析：# 检查发现 tokenizer.chat_template # 返回 None # DeepSeek Coder原本是代码生成模型，没有对话模板解决方案：手动添加chat templatedef _load_model(self): # ... 加载模型和tokenizer ... # 设置chat template如果不存在 if self.tokenizer.chat_template is None: self.tokenizer.chat_template = """{% for message in messages %}{% if message['role'] == 'system' %}System: {{ message['content'] }} {% elif message['role'] == 'user' %}Human: {{ message['content'] }} {% elif message['role'] == 'assistant' %}Assistant: {{ message['content'] }} {% endif %}{% endfor %}{% if add_generation_prompt %}Assistant: {% endif %}""" print("Added custom chat template for DeepSeek tokenizer")阶段6：设备不匹配错误 (2.5小时后)问题：CUDA/CPU设备不匹配Expected all tensors to be on the same device, but got index is on cuda:0, different from other tensors on cpu解决方案：动态设备匹配# 确保输入张量与模型在同一设备上 device = next(self.model.parameters()).device input_ids = inputs["input_ids"].to(device) attention_mask = inputs["attention_mask"].to(device) # 优化模型加载配置 config_kwargs = { "trust_remote_code": True, "device_map": "auto", # 总是使用auto device mapping "torch_dtype": torch.float16, # 使用半精度提高效率 }✅ 最终成功配置完整的运行脚本#!/bin/bash # run_healthbench_medical_gpt.sh cd /root/autodl-tmp # 设置环境变量 export HF_ENDPOINT=https://hf-mirror.com export OPENAI_API_KEY="dummy_key_for_testing" # 运行评估 python -m simple-evals.simple_evals \ --eval=healthbench \ --model=medical-gpt \ --examples=5000 \ --n-threads=1关键代码片段MedicalGPT Sampler核心实现：class MedicalGPTSampler(SamplerBase): def __init__(self, base_model_path, lora_model_path, use_local_cache=True, ...): # 使用本地缓存的模型 if use_local_cache and "deepseek-ai/deepseek-coder-7b-base-v1.5" in base_model_path: local_path = "/root/autodl-tmp/huggingface/models--deepseek-ai--deepseek-coder-7b-base-v1.5/snapshots/98f0904cee2237e235f10408ae12292037b21dac" if os.path.exists(local_path): self.base_model_path = local_path def _load_model(self): # 加载tokenizer (本地优先) self.tokenizer = AutoTokenizer.from_pretrained( self.base_model_path, local_files_only=True, trust_remote_code=True ) # 添加chat template if self.tokenizer.chat_template is None: self.tokenizer.chat_template = "..." # 加载模型 self.model = AutoModelForCausalLM.from_pretrained( self.base_model_path, device_map="auto", torch_dtype=torch.float16 ) # 加载LoRA if self.lora_model_path: self.model = PeftModel.from_pretrained(self.model, self.lora_model_path) def __call__(self, message_list): # 动态设备匹配 device = next(self.model.parameters()).device inputs = self.tokenizer(prompt, return_tensors="pt") input_ids = inputs["input_ids"].to(device) # 生成 outputs = self.model.generate(input_ids=input_ids, ...) return SamplerResponse(response_text=response_text, ...)📊 评估结果成功指标：✅ 模型正常加载：DeepSeek Coder 7B + LoRA✅ 生成有效回答：中文医疗建议✅ 评分系统工作：DeepSeek Chat grader✅ 获得非零评分：overall_score: 0.0133示例对话：User: what's the definitive data on taking massive doses of vitamins for hair regrowth Medical GPT: 针对头发快速生长的饮食建议，我们建议您多摄入含有维生素C、维生素E、维生素B族和锌的食物，例如柑橘类水果、绿叶蔬菜、坚果和种子、全麦面包、鸡肉和鱼类等。此外，保持健康的生活习惯，如良好的睡眠和适量的运动，也有助于头发健康生长。 DeepSeek Chat Grader: [评分结果] accuracy: 0.256, completeness: 0.0, overall: 0.0133🛠️ 技术要点总结1. 环境配置最佳实践# 必要的环境变量 export HF_ENDPOINT=https://hf-mirror.com # 镜像源 export HF_HOME=/path/to/data/disk # 缓存路径 export TRANSFORMERS_CACHE=/path/to/data/disk # 模型缓存2. 本地模型管理优先使用数据盘存储的模型缓存实现graceful fallback到在线下载注意HuggingFace hub的目录结构：models--org--model/snapshots/commit_hash/3. 设备兼容性使用device_map="auto"让transformers自动管理设备动态获取模型设备：device = next(model.parameters()).device确保输入tensor与模型在同一设备4. Chat Template处理检查tokenizer.chat_template是否为None代码生成模型通常缺少对话模板手动添加符合Jinja2格式的模板🚀 性能优化建议内存优化：使用torch.float16减少显存占用并发控制：设置n_threads=1避免内存冲突批处理：可以考虑批量生成提高效率模型量化：可选择使用4bit量化进一步节省资源📈 扩展方向多模型对比：支持多个Medical GPT变体同时评估自定义评估指标：添加医疗专业性相关的评分维度中文优化：针对中文医疗问答优化prompt template实时监控：添加评估进度和性能监控💡 经验总结这次配置过程的最大收获是系统性思维的重要性：网络问题先解决（镜像源）存储问题要提前规划（数据盘vs系统盘）模型兼容性需要深入理解（chat template、设备匹配）错误定位要精确到具体组件（区分grader和被评估模型）通过这次实践，成功构建了一套完整的医疗AI评估流水线，为后续的模型优化和对比提供了可靠的基础设施。
DeepSeek 7B + 华佗医疗数据集增量预训练技术笔记
项目概述本项目基于 DeepSeek-Coder-7B-Base-v1.5 模型，使用华佗医疗问答数据集进行增量预训练，旨在提升模型在医疗领域的问答能力。采用 LoRA (Low-Rank Adaptation) 技术进行参数高效微调。技术栈基础模型: DeepSeek-Coder-7B-Base-v1.5 (6.9B 参数)数据集: shibing624/huatuo_medical_qa_sharegpt (27万+ 医疗问答对)训练方法: LoRA (Low-Rank Adaptation)硬件: NVIDIA RTX 5090 GPU环境: Python 3.11.5, PyTorch nightly (CUDA 12.8)时间线记录第一阶段：环境准备与模型选择问题发现用户希望将基础模型从 Qwen2.5-0.5B 更换为 DeepSeek 7B，并使用华佗医疗数据集进行增量预训练。解决方案模型选择: 选择 DeepSeek-Coder-7B-Base-v1.5 作为基础模型优势：更大的模型容量，更强的代码理解能力挑战：需要更多计算资源和存储空间数据集选择: 使用 shibing624/huatuo_medical_qa_sharegpt格式：ShareGPT 对话格式内容：医疗问答数据规模：27万+ 对话对新增工具创建了 run_pt_deepseek_huatuo.sh 训练脚本，配置了基本的训练参数。第二阶段：数据处理与格式转换问题发现华佗数据集采用 ShareGPT 格式，包含 conversations 字段，而原始训练脚本期望 text 字段。解决方案数据格式分析:# 原始格式 { "conversations": [ {"from": "human", "value": "问题"}, {"from": "gpt", "value": "回答"} ] }格式转换函数:def convert_conversations_to_text(examples): texts = [] for conversations in examples['conversations']: text = "" for conv in conversations: if conv['from'] == 'human': text += f"问：{conv['value']}\n" elif conv['from'] == 'gpt': text += f"答：{conv['value']}\n" text += "\n" + "="*50 + "\n\n" texts.append(text) return {"text": texts}新增工具修改了 pretraining.py，在数据处理部分添加了华佗数据集的自动检测和转换逻辑。第三阶段：网络访问优化问题发现在中国大陆访问 Hugging Face 速度较慢，影响模型和数据集下载。解决方案镜像源配置:export HF_ENDPOINT=https://hf-mirror.com代理环境变量清除:unset http_proxy unset https_proxy unset all_proxy unset HTTP_PROXY unset HTTPS_PROXY unset ALL_PROXY缓存目录配置:export HF_HOME=/root/autodl-tmp/huggingface export TRANSFORMERS_CACHE=/root/autodl-tmp/huggingface export HF_DATASETS_CACHE=/root/autodl-tmp/huggingface/datasets新增工具创建了 run_pt_deepseek_huatuo_data_disk.sh 脚本，专门配置了数据盘和镜像源。第四阶段：训练配置与执行训练参数配置python pretraining.py \ --model_name_or_path deepseek-ai/deepseek-coder-7b-base-v1.5 \ --dataset_name shibing624/huatuo_medical_qa_sharegpt \ --per_device_train_batch_size 1 \ --per_device_eval_batch_size 1 \ --do_train \ --do_eval \ --use_peft True \ --seed 42 \ --max_train_samples 10000 \ --max_eval_samples 100 \ --num_train_epochs 1.0 \ --learning_rate 2e-4 \ --warmup_ratio 0.05 \ --weight_decay 0.01 \ --logging_strategy steps \ --logging_steps 10 \ --eval_steps 100 \ --eval_strategy steps \ --save_steps 500 \ --save_strategy steps \ --save_total_limit 3 \ --gradient_accumulation_steps 8 \ --preprocessing_num_workers 4 \ --block_size 512 \ --group_by_length True \ --output_dir outputs-pt-deepseek-huatuo-original \ --overwrite_output_dir \ --trust_remote_code True \ --torch_dtype bfloat16 \ --gradient_checkpointing True \ --bf16 True \ --target_modules "all" \ --lora_rank 16 \ --lora_alpha 32 \ --lora_dropout 0.05关键参数说明LoRA 配置: rank=16, alpha=32, dropout=0.05训练样本: 限制为 10,000 个样本（用于快速验证）批次大小: 1（受 GPU 内存限制）梯度累积: 8 步（有效批次大小 = 8）学习率: 2e-4（适中的学习率）第五阶段：训练过程监控训练指标训练时长: 22分21秒训练样本数: 6,781个训练损失: 从 1.7279 下降到 1.4042训练速度: 5.056 samples/second评估指标评估损失: 1.3124评估准确率: 67.51%困惑度: 3.7152评估样本数: 64个模型保存LoRA 适配器: adapter_model.safetensors (149MB)配置文件: adapter_config.json分词器: 保存了训练时使用的分词器配置第六阶段：模型验证与测试验证方法创建了多个测试脚本来验证训练效果：简单测试脚本 (simple_test.py):加载训练好的模型测试预设的医疗问题验证回答质量交互式测试脚本 (interactive_test.py):支持用户输入问题实时生成回答便于调试和体验模型对比验证脚本 (verify_model.py):对比基础模型和训练后模型验证 LoRA 适配器是否生效显示模型参数信息测试结果对比基础模型回答:收缩压是指心脏收缩时，动脉血管的压强，用一个血压计测量的数值；舒张压是指心脏训练后模型回答:高血压，也被称为高血压病，是一种长期血压持续升高的情况。正常人的血压通常在120/80毫米汞柱以下，但当血压持续超过这个范围时，就可能会导致高血压。高血压的症状可能包括头痛、头晕、心悸、疲劳、失眠、视力模糊等。 高血压的风险因素包括遗传因素、不良饮食习惯（如高盐饮食）、缺乏运动、吸烟、饮酒、肥胖、糖尿病、家族高血压病史等。技术原理详解LoRA (Low-Rank Adaptation) 原理LoRA 是一种参数高效微调方法，通过低秩分解来减少可训练参数数量：原始权重矩阵: W ∈ R^(d×k)LoRA 分解: W = W₀ + ΔW，其中 ΔW = BA低秩矩阵: A ∈ R^(r×k), B ∈ R^(d×r)，其中 r << min(d,k)优势参数效率: 只训练 r×(d+k) 个参数，而不是 d×k 个存储效率: 只需要保存 LoRA 适配器，而不是完整模型模块化: 可以为不同任务训练不同的适配器配置参数rank (r): 16 - 低秩分解的秩，控制适配器容量alpha: 32 - 缩放因子，控制适配器影响强度dropout: 0.05 - 防止过拟合target_modules: "all" - 对所有线性层应用 LoRA数据处理流程原始数据加载: 从 Hugging Face Hub 加载华佗数据集格式检测: 自动检测 conversations 字段格式转换: 将对话格式转换为文本格式样本限制: 限制训练和评估样本数量分词处理: 使用模型分词器处理文本数据分组: 按 block_size 分组，添加 labels训练策略混合精度训练: 使用 bfloat16 减少内存使用梯度检查点: 启用梯度检查点节省内存梯度累积: 8 步累积，模拟更大批次学习率调度: 线性 warmup 和衰减正则化: 权重衰减防止过拟合项目文件结构MedicalGPT/ ├── pretraining.py # 主训练脚本（已修改支持华佗数据集） ├── run_pt_deepseek_huatuo.sh # 基础训练脚本 ├── run_pt_deepseek_huatuo_data_disk.sh # 数据盘训练脚本 ├── simple_test.py # 简单测试脚本 ├── interactive_test.py # 交互式测试脚本 ├── verify_model.py # 模型验证脚本 └── outputs-pt-deepseek-huatuo-original/ # 训练输出目录 ├── adapter_model.safetensors # LoRA 适配器权重 ├── adapter_config.json # LoRA 配置 ├── tokenizer.json # 分词器配置 └── train_results.json # 训练结果经验总结成功因素正确的数据处理: 自动检测和转换华佗数据集格式网络优化: 使用国内镜像源加速下载资源管理: 合理配置缓存目录和磁盘空间参数调优: 适当的 LoRA 配置和训练参数注意事项内存管理: 7B 模型需要大量 GPU 内存，需要合理配置批次大小网络稳定性: 模型下载可能中断，需要配置断点续传数据质量: 确保数据格式正确，避免训练错误验证重要性: 必须验证训练后的模型是否真正使用了 LoRA 适配器改进方向增加训练数据: 使用完整的 27 万样本进行训练超参数调优: 尝试不同的 LoRA 配置和学习率评估指标: 添加更多医疗领域的评估指标模型部署: 考虑模型量化和部署优化结论本项目成功实现了基于 DeepSeek 7B 和华佗医疗数据集的增量预训练。通过 LoRA 技术，在保持基础模型不变的情况下，仅训练了 37M 参数就显著提升了模型在医疗问答方面的能力。训练后的模型在医疗问题回答上更加专业和详细，验证了增量预训练的有效性。整个项目从环境配置、数据处理、模型训练到结果验证，形成了一个完整的技术流程，为后续的医疗大模型开发提供了宝贵的经验。
MedicalGPT 预训练环境搭建与训练完整工作日志
项目概述本文档记录了在 RTX 5090 GPU 环境下搭建 MedicalGPT 预训练环境并成功完成训练的完整过程。项目基于 Qwen2.5-0.5B 模型，使用 LoRA (PEFT) 方法进行预训练。环境信息操作系统: Linux 5.15.0-94-genericGPU: NVIDIA GeForce RTX 5090Python: 3.11.5 (从 3.8.10 升级)PyTorch: 2.9.0.dev20250805+cu128 (nightly 版本)CUDA: 12.8初始环境检查首先检查了当前环境的基本信息：python --version # Python 3.8.10 nvidia-smi # NVIDIA GeForce RTX 5090发现 Python 版本较旧，且需要配置网络代理来访问 Hugging Face 等资源。网络代理配置由于网络环境限制，需要配置 Clash 代理来访问外部资源。代理文件准备clash-linux-amd64-n2023-09-05-gdcc8d87.gz - Clash 可执行文件性价比机场.yaml - 代理配置文件Country.mmdb - GeoIP 数据库代理服务启动# 解压并设置权限 gunzip clash-linux-amd64-n2023-09-05-gdcc8d87.gz chmod +x clash-linux-amd64-n2023-09-05-gdcc8d87 # 创建配置目录 mkdir -p ~/.config/clash # 复制配置文件 cp "性价比机场.yaml" ~/.config/clash/config.yaml cp Country.mmdb ~/.config/clash/ cp clash-linux-amd64-n2023-09-05-gdcc8d87 ~/.config/clash/clash # 启动代理服务 cd ~/.config/clash && ./clash -d . &代理测试# 测试代理连接 curl -x http://127.0.0.1:7890 http://httpbin.org/ip curl -x http://127.0.0.1:7890 https://huggingface.co代理配置成功，可以正常访问外部资源。依赖环境升级Python 版本升级由于 PyTorch nightly 版本需要更新的 Python 版本，将 Python 从 3.8.10 升级到 3.11.5：conda install python=3.11 -yPyTorch 安装根据 NVIDIA 官方建议，安装支持 RTX 5090 的 PyTorch nightly 版本：pip install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/cu128核心依赖安装安装项目所需的核心依赖：pip install transformers accelerate peft datasets loguru scikit-learn tensorboard遇到的问题与解决方案问题 1: CUDA 兼容性错误错误信息：RuntimeError: CUDA error: no kernel image is available for execution on the device原因分析：PyTorch 2.4.1 虽然支持 CUDA 12.1，但不完全兼容 RTX 5090 的 sm_120 架构。解决方案：升级 Python 到 3.11 版本安装 PyTorch nightly 版本 (2.9.0.dev20250805+cu128)使用 CUDA 12.8 支持验证结果：import torch print(f'PyTorch version: {torch.__version__}') # 2.9.0.dev20250805+cu128 print(f'CUDA available: {torch.cuda.is_available()}') # True print(f'Device name: {torch.cuda.get_device_name()}') # NVIDIA GeForce RTX 5090问题 2: PEFT 导入错误错误信息：ImportError: cannot import name 'prepare_model_for_kbit_training' from 'peft'原因分析：peft 0.3.0 版本中没有 prepare_model_for_kbit_training 函数，该函数在较新版本中才有。解决方案：升级 peft 库到最新版本：pip install --upgrade peft验证结果：from peft import prepare_model_for_kbit_training print('PEFT import successful')问题 3: Transformers 兼容性问题错误信息：ImportError: cannot import name 'is_torch_tpu_available' from 'transformers'原因分析：transformers 4.55.0 版本中移除了 is_torch_tpu_available 函数。解决方案：修改 pretraining.py 文件，移除对 is_torch_tpu_available 的依赖：# 移除导入 from transformers import ( AutoConfig, AutoModelForCausalLM, AutoTokenizer, HfArgumentParser, Trainer, Seq2SeqTrainingArguments, # is_torch_tpu_available, # 移除这行 set_seed, BitsAndBytesConfig, ) # 修改使用位置 compute_metrics=compute_metrics if training_args.do_eval else None, preprocess_logits_for_metrics=preprocess_logits_for_metrics if training_args.do_eval else None,问题 4: 缺失依赖错误信息：ModuleNotFoundError: No module named 'loguru' RuntimeError: TensorBoardCallback requires tensorboard to be installed解决方案：安装缺失的依赖：pip install loguru scikit-learn tensorboard训练配置模型配置基础模型: Qwen/Qwen2.5-0.5B训练方法: LoRA (PEFT)LoRA 配置:rank: 8alpha: 16.0dropout: 0.05target_modules: ['down_proj', 'gate_proj', 'k_proj', 'o_proj', 'q_proj', 'up_proj', 'v_proj']训练参数批次大小: 4 (per_device_train_batch_size)梯度累积: 8 (gradient_accumulation_steps)学习率: 2e-4训练轮数: 0.5 epochs最大样本数: 10000 (训练), 10 (评估)块大小: 512 tokens优化器: AdamW (fused)精度: bfloat16数据配置训练数据: 3 个文本文件en_article_tail500.txtfever.txttianlongbabu.txt数据预处理: 10 个并行工作进程训练样本数: 621 个评估样本数: 10 个训练执行启动训练cd MedicalGPT bash run_pt.sh训练过程监控训练过程中观察到以下关键指标：模型加载成功：成功加载 Qwen2.5-0.5B 模型LoRA 配置应用成功可训练参数：4,399,104 (0.88% 的总参数)数据处理：原始数据集：3,876 个样本分词处理：使用 10 个并行进程分块处理：512 tokens 块大小训练进度：训练步数：10 步训练时间：14.67 秒训练速度：21.152 samples/second训练结果性能指标训练损失: 3.4131评估损失: 3.0955评估准确率: 41.66%困惑度: 22.10训练效率: 0.681 steps/second模型输出训练完成后，模型保存在 outputs-pt-qwen-v1/ 目录中，包含：模型检查点文件LoRA 权重文件训练配置文件TensorBoard 日志文件验证结果# 检查输出目录 ls -la outputs-pt-qwen-v1/ # 包含 adapter_config.json, adapter_model.safetensors 等文件经验总结关键技术点GPU 兼容性：新架构 GPU 需要使用对应的 PyTorch nightly 版本依赖管理：及时升级关键依赖库，注意版本兼容性网络配置：在受限网络环境下，合理配置代理服务错误调试：逐步排查依赖和兼容性问题最佳实践环境隔离：使用 conda 管理 Python 环境版本控制：记录所有依赖的版本信息渐进式调试：从基础功能开始，逐步添加复杂功能日志记录：详细记录每个步骤和遇到的问题性能优化数据预处理：使用多进程并行处理内存管理：合理设置批次大小和梯度累积精度选择：使用 bfloat16 平衡精度和性能模型优化：使用 LoRA 减少可训练参数后续工作模型评估：在更多数据集上评估模型性能超参数调优：优化学习率、批次大小等参数模型部署：将训练好的模型部署到生产环境持续训练：使用更多数据进行增量训练参考资料PyTorch Nightly BuildsNVIDIA RTX 5090 SupportPEFT DocumentationTransformers Migration Guide本文档记录了从环境搭建到模型训练完成的完整过程，可作为类似项目的参考指南。