跳到主要内容

笔记

11.03-11.10​

马尔可夫思考​

一站式大模型​

这个从 Long-COT 到马尔科夫思考是不是可以类比为将 Transformer 退化为 RNN ?

  • 您提出的这个类比非常精彩和深刻，在很大程度上是成立的。

这是一个极佳的抽象思维，准确地抓住了两种模式转变的核心思想：从依赖全部历史信息（全局上下文）到只依赖前一个状态（局部状态）的退化。

我们可以从以下几个方面来解析这个类比：

核心共同点：从“全局依赖”到“局部依赖”的退化

  1. Transformer vs. RNN: - Transformer 的核心是 Self-Attention 机制。在处理一个序列时，每个词（token）都可以直接与序列中所有其他词进行交互和计算。它拥有一个“上帝视角”，可以一步到位地看到全局信息。

  • RNN (Recurrent Neural Network) 则是一个严格的序列模型。它在处理第 t 个词时，只能直接访问第 t-1 步传递过来的“隐藏状态”（hidden state）。这个隐藏状态就像是整个过去历史的一个压缩摘要。理论上它包含了过去的所有信息，但实际上，由于梯度消失/爆炸等问题，它对遥远历史的记忆非常有限。

    • 退化关系：从可以访问全部历史（Transformer）退化到只能访问上一时刻的压缩历史（RNN），这是一种信息访问能力的降级，带来了计算上的序列依赖性。

    1. Long-COT vs. 马尔科夫思考者 (Markovian Thinker):
    • Long-COT (Chain-of-Thought) 在标准 Transformer 模型上运行时，模型在生成思考链的第 t 步时，它的注意力机制可以回顾并利用从第 1 步到第 t-1 步所有已经生成的完整思考内容。这同样是一个“上帝视角”，模型可以审视自己完整的“心路历程”。

  • 马尔科夫思考者，根据其定义（Markov Property），在生成第 t 步思考时，其状态只依赖于第 t-1 步的状态，而与 t-2, t-3...等更早的步骤无关。它没有记忆，只看脚下的前一步。

    • 退化关系：从可以回顾整个思考链（Long-COT on Transformer）退化到只依赖上一步的思考结果（马尔科夫思考者），这同样是一种信息访问能力的降级，强制模型进行一种“短视”的、线性的推理。
    方面 (Aspect)Transformer / Long-COTRNN / Markovian Thinker
    信息访问模式全局/并行 (Global/Parallel)局部/序列 (Local/Sequential)
    记忆能力直接访问全部历史上下文依赖于一个压缩的、有损的“状态”
    上下文瓶颈受限于模型的最大上下文窗口存在“隐藏状态”这个严重的信息瓶颈
    核心思想上下文中的任意元素都可以直接交互当前状态只由前一状态决定
    “退化”的体现放弃全局视野，换取简化的序列依赖放弃全局思考链，换取简化的状态转移

类比的精妙之处与局限性

  • 精妙之处：这个类比完美地揭示了两种不同信息处理范式之间的核心差异。无论是在模型架构层面（Transformer vs. RNN）还是在推理过程层面（Long-COT vs. Markovian），都是从一个高维、全局的依赖空间向一个低维、局部的状态空间进行的简化或“退化”。
  • 局限性（或需注意的细节）： a. 架构 vs. 过程：Transformer/RNN 是模型架构，而 Long-COT/马尔科夫思考是运行在这些架构之上的推理过程或算法范式。我们通常是在一个 Transformer 架构上，通过不同的算法来实现或模拟这两种思考过程。 b. RNN 的记忆并非严格马尔科夫：一个标准的 RNN 的隐藏状态理论上是对所有过去信息的编码，而不仅仅是前一个状态。所以 RNN 并非一个严格的一阶马尔科夫过程。但从实践效果上看，它确实更依赖于临近的状态，所以这个类比在精神上是相通的。而“马尔科夫思考者”是更彻底、更极端的“退化”。

结论：

您的类比非常准确。将 Transformer 退化为 RNN，是从架构上限制了模型并行访问全局信息的能力；而将 Long-COT 退化为马尔科夫思考，则是从算法和推理过程上施加了类似的限制。两者都体现了为了简化模型、降低计算复杂度或实现某种特定的序列化结构，而牺牲对完整历史的访问能力。

VeRL 框架

AgentFlow​

Situation (背景)​

搭建多 Agent 系统, 主要是针对作业批改的任务, 提高作业批改的准确率, 提高泛化能力, 对于不确定的题目的推理, 给出更加准确的答案。当前工具增强推理方法面临 可扩展性 和 泛化能力 的限制，主流方法如 Search-R1 训练单个 LLM 来交错推理步骤和工具调用，但这种方法在长期推理任务中表现不佳。

Task (任务)​

AgentFlow 旨在构建一个 可训练的、工具集成的智能体框架，通过模块化架构和在线优化算法，在复杂推理任务中实现卓越的规划、工具使用和长期推理能力

Action (行动)​

核心架构设计​
  • 四智能体模块化系统：Planner（规划器）、Executor（执行器）、Verifier（验证器）、Generator（生成器）通过共享内存协调工作
  • Flow-GRPO 优化算法：直接在系统中优化规划器智能体，使用在线强化学习进行长期推理任务优化
技术实现​
  • 核心编排器：Solver 类在 solver.py 中协调整个问题解决工作流程
  • 工具系统集成：支持多种工具包括 base_generator、python_coder、google_search 等
  • 双模式运行：推理模式使用预训练模型，训练模式使用 Flow-GRPO 在线优化

Result (结果)​

性能提升​

AgentFlow（基于 Qwen-2.5-7B-Instruct）在 10 个基准测试中超越顶级基线：

  • 搜索任务：+14.9%提升
  • 智能体推理：+14.0%提升
  • 数学推理：+14.5%提升
  • 科学推理：+4.1%提升
技术突破​
  • 超越大模型：甚至优于约 200B 参数的 GPT-4o 模型
  • 开源贡献：项目已在 NeurIPS 2025 Efficient Reasoning Workshop 被接收，并获得 HuggingFace Daily Paper

Notes​

AgentFlow 项目通过创新的模块化架构和在线优化算法，成功解决了工具增强推理中的关键挑战。其核心价值在于将复杂的推理任务分解为专门的智能体模块，并通过 Flow-GRPO 算法实现持续优化，在保持较小模型规模的同时实现了超越大型模型的性能。

Agent ModulePrimary ResponsibilityKey OperationsCode Location
PlannerPlanning and decision-makingQuery analysis, next step generation, tool selection, verification, output generationagentflow/agentflow/models/planner.py
ExecutorTool command executionTool command generation, command parsing, tool execution orchestrationagentflow/agentflow/models/executor.py
VerifierResult validationVerification logic (integrated within Planner)agentflow/agentflow/models/planner.py
GeneratorResponse generationFinal output formatting, direct output generation (integrated within Planner)agentflow/agentflow/models/planner.py

Planner agent 是 Flow-GRPO 优化的主要目标，使其能够在完整的系统环境中通过强化学习来学习有效的规划策略。

数据传递

您询问的是数据传输过程中的数据结构和轨迹结构。根据代码库上下文, 这涉及到 AgentFlow 系统中的两个核心概念:

数据传输中的数据结构​

在 AgentFlow 中, 数据传输主要通过以下结构进行:

1. Memory 结构​

Memory 类用于在多轮执行过程中存储和传递数据 。每个 action 包含:

  • tool_name: 使用的工具名称
  • sub_goal: 子目标
  • command: 执行的命令
  • result: 工具执行结果
2. 执行流程中的数据传递​

在 Solver.solve() 方法中, 数据按以下方式流转 :

  1. Planner 生成下一步行动, 接收 question、image_path、query_analysis 和 memory
  2. Executor 生成工具命令并执行
  3. 结果更新到 Memory

轨迹(Trajectory)结构​

1. Triplet 基础结构​

轨迹由多个 Triplet 对象组成, 每个 Triplet 代表一次交互 :

  • prompt: 输入提示(包含 token_ids)
  • response: 模型响应(包含 token_ids)
  • reward: 奖励值(可选)
  • metadata: 元数据(如 response_id、agent_name)
2. Transition 结构​

在训练过程中, 轨迹被转换为 Transition 对象 :

  • state: 状态的 token ID 列表
  • action: 动作的 token ID 列表
  • response_id: 响应标识符
  • agent_name: 代理名称
  • reward: 奖励值
3. 轨迹生成过程​

TraceTree.to_trajectory() 方法将追踪树转换为轨迹 :

  1. 查找所有 LLM 调用
  2. 提取每次调用的 prompt_token_ids 和 response_token_ids
  3. 匹配奖励值到对应的转换
  4. 生成 Triplet 列表
4. 训练数据批次结构​

在训练时, 轨迹被处理为批次数据 :

trace_list = [
    {"prompt_ids": [...], "response_ids": [...]}
    for t in rollout.triplets
]

每个样本包含:

  • reward: 最终奖励
  • trace_list: 轨迹列表
  • data_id: 数据标识符

Notes

训练输出中的 rollout JSON 文件也包含完整的执行轨迹, 但格式不同于训练用的 Triplet 结构 。Rollout JSON 包含更详细的信息如 query_analysis、memory(工具执行历史)和 direct_output, 主要用于分析和调试, 而 Triplet 结构专门为强化学习训练设计, 只包含 token IDs 和奖励信息。

Agent 架构​

This project follows a "Planner-Executor" agentic architecture, which is a common and powerful pattern. Here are the key agents and their functions:

  1. The Planner Agent

  • Role: The "Brain" or "Strategist" of the operation. The Planner is the master agent that orchestrates the entire problem-solving process.

  • Responsibilities:

    • Query Analysis: It first analyzes the user's initial query to understand the core objectives and what kind of information is needed.
    • Step-by-Step Planning: At each step, it looks at the current situation (including the original query and the results from previous steps) and decides on the single best "next step". This involves choosing which tool to use and defining a specific sub-goal for that tool.
    • Context Verification: After a tool is used, the Planner re-evaluates the situation. It decides if the information gathered so far is sufficient to answer the original query. If it is, it gives the "STOP" signal; otherwise, it signals to "CONTINUE" with the next step.

  • Model It Uses: The Planner uses the primary model you specify when you run the script.

    • In quick_start.py, this is controlled by the llm_engine_name parameter, which you've set to your local Ollama model (ollama-deepseek-r1:7b).

    • In the training configuration (train/config.yaml), this corresponds to the main BASE_MODEL (Qwen/Qwen1.5-1.8B-Chat) that is served via vLLM.

    1. The Executor Agent

  • Role: The "Hands" or "Doer" of the operation. The Executor takes the Planner's commands and carries them out.

  • Responsibilities:

    • Command Generation: It receives the tool name and sub-goal from the Planner. Its job is to then formulate the precise, executable code or command for that tool (e.g., generating the correct Python syntax like tool.execute(query = "...")).
    • Command Execution: It then runs this command and captures the output (the result).

  • Model It Uses: The Executor uses its own separate LLM to generate the tool commands. This is where your remote API configuration comes into play.

    • In our latest setup for quick_start.py, we configured the Executor to use executor_llm_engine_name, which is set to "deepseek-r1".

    • This triggers the logic in factory.py to use your remote API endpoint with your API key.

    1. The Tool Agents

This is a subtle but important category. Some of the "tools" are not just simple functions; they are themselves powered by LLMs and act as specialized, single-purpose agents.

  • Role: Specialists that perform a single, well-defined task.
  • Examples from your configuration:
    • Google_Search_Tool: When this tool needs to process results or formulate a better search query, it can use its own LLM.
    • Wikipedia_Search_Tool: Similarly, this tool can use an LLM to summarize articles or extract key information.
    • Base_Generator_Tool: This tool's entire purpose is to act as a generalist agent to answer a query.
  • Models They Use: The models for these tool agents are defined by the TOOL_ENGINE list in your train/config.yaml: TOOL_ENGINE: ["self", "self", "deepseek-r1", "deepseek-r1"]
    • Base_Generator_Tool and Python_Coder_Tool are set to "self", meaning they use the main training model (the same one as the Planner).
    • Google_Search_Tool and Wikipedia_Search_Tool are set to "deepseek-r1", meaning when they need LLM capabilities, they will also call your remote API via the logic in factory.py.

Summary Table

Agent/ComponentRoleModel Used (in your final configuration)
Planner AgentThe "Brain". Decides what to do next.Local Ollama (ollama-deepseek-r1:7b) for inference / Main BASE_MODEL for training.
Executor AgentThe "Hands". Generates and runs tool commands.Your remote API (deepseek-r1).
Tool Agents (some)Specialists for specific tasks (e.g., Search).Varies. Some use the main model (self), others use your remote API (deepseek-r1).

This separation of concerns is very powerful. It allows you to use a smaller, faster local model for the high-level planning, while leveraging a more powerful, specialized remote model for the heavy-lifting tasks performed by the Executor and certain tools.

算法对比​

Flow-GRPO 沿用了 GRPO 的优势估计与损失，但训练的对象、数据收集方式以及奖励注入链路都围绕 AgentFlow 的“流程化”代理体系做了大幅改造，因此和经典、单轮文本场景里的 GRPO 有几点关键差异：

  • 训练对象定位：经典 GRPO 直接优化单个 LLM 在静态 prompt→completion 数据集上的策略；Flow-GRPO 只微调 AgentFlow 流程中的 Planner，并让其与 Executor / Verifier / Generator 四个子代理协同，在真实多轮记忆与工具调用链里学习决策，侧重点是“系统内在线调度”，而不是单模型输出指出了四模块架构以及“在线优化 planner”的目标）。
  • 数据采集方式：传统 GRPO 在每个 prompt 上并行采样多条回答、离线计算组奖励；Flow-GRPO 通过 AgentFlowTrainer→AgentModeDaemon 把 Ray PPO 训练 loop 接到 AgentFlowServer，每个 batch 都要实际跑一整条任务流程、调用外部工具/LLM，生成 rollout.triplets（prompt/response/token_ids），再回填训练数据。这套“跑流程再学习”, 说明 Flow-GRPO 是“在线环境交互 + 回传轨迹”的做法，而不是对静态语料做策略梯度。
  • 奖励与 Advantage 结构：Flow-GRPO 把流程执行得到的 rollout.final_reward 映射回每一轮的 token level 分布，再拼成完整输入序列，以便 GRPO 算法继续“组平均 → 去均值”地计算 advantage。经典 GRPO 则通常直接用判题器/规则在每个回答结尾给奖励，没有多轮 trace 的展开或 token-level 回填。 总的来说：Flow-GRPO 在优化目标（仍是 GRPO）、但在“交互式数据收集 + 多代理流 + 奖励写回”层面拓展，让 GRPO 适配 AgentFlow 的多轮、工具增强场景；而经典 GRPO 更像单模文本 RLHF。

四个模块​

四个模块都在 agentflow/agentflow/models 下面有对应实现，并且都在 agentflow/agentflow/solver.py 的 construct_solver() 里统一实例化。

  • Action Planner：agentflow/agentflow/models/planner.py 定义 Planner 类。它内部构建 planner ，并提供 generate_base_response、analyze_query、generate_next_step、verificate_context 等核心逻辑。
  • Tool Executor：agentflow/agentflow/models/executor.py 定义 Executor 类，负责根据 planner 给的 context/sub-goal 生成 tool command，再调用 Initializer 缓存的工具实例执行。
  • Executive Verifier：不是独立文件，而是 planner 内 verificate_context() + extract_conclusion() 这套 verifier 流程。
  • Solution Generator：最终答案生成也由 Planner 完成，分别是 generate_final_output() 和 generate_direct_output()。它使用同一 LLM 引擎把 memory 中的行动摘要成详细解和直接输出。

11.29-12.05​

verl​

从零开始的 verl 框架解析

AI Infra VeRL 框架入门&代码带读

Verl GRPO 实现拆解讲解

AgentLighting

verl-agent​

本文从代码结构与关键流程入手，梳理 verl-agent 如何把多轮环境交互、组内强化学习算法（GiGPO/DAPO/GRPO 等）以及多模态大模型训练串联起来。可配合 README.md 了解任务背景，本篇聚焦“源码如何实现这些能力”。

1. 顶层执行路径​

延续 veRL 的 Hydra + Ray 规范，训练入口位于 verl/trainer/main_ppo.py:34-188：

  1. Hydra 配置 – 读取 verl/trainer/config/ppo_trainer.yaml，将模型、环境、算法、资源需求注入 config。
  2. Ray 初始化 – get_ppo_ray_runtime_env() 统一设定 tokenizer 线程、NCCL 等运行环境，然后用 ray.init(...) 起本地/集群运行时。
  3. TaskRunner – 在单独的 Ray 任务中完成：
    • 下载/定位权重；
    • 通过 agent_system.environments.make_envs() 创建训练/验证环境管理器；
    • 构造 tokenizer/processor、奖励模型 worker、Actor/Critic/Ref worker group；
    • 实例化 TrajectoryCollector（多轮 rollout 管理器）和 RayPPOTrainer；
    • trainer.fit() 进入主循环。

可见源码将“算法策略”与“环境交互”拆分到 verl 与 agent_system 两条线，便于替换/扩展。

2. 仓库结构速览​

路径职责
verl/veRL 主体：Ray Trainer、核心 PPO/GiGPO 算法、模型注册、worker 管理、工具函数。
agent_system/Agent 相关扩展：多环境封装、记忆模块、多轮采样、奖励聚合。
examples/每类算法/环境的启动脚本，方便照搬配置（如 examples/gigpo_trainer/run_alfworld.sh）。
docs/额外说明文档（本文件即位于此处）。
scripts/依赖安装与环境搭建脚本，例如 scripts/install_py310.sh。
tests/针对核心组件的单测/集成测试。

3. 配置与数据流​

3.1 Hydra 配置层​

verl/trainer/config/ppo_trainer.yaml 以模块化字段描述整个训练：

  • data.*：数据路径、token 长度、batch size、是否返回原始 chat、truncation 方式等；
  • actor_rollout_ref.*：单一配置块内描述 Actor、Rollout Engine、Reference 三个角色（策略、采样、对照）；
  • critic.*、reward_model.*：价值网络与奖励模型的并行策略；
  • env.*：agent_system 所需的环境类型、种子、rollout 组数、history length 等；
  • algorithm.*：GiGPO/GRPO/动态 sampling 的开关、clip/entropy/adv 计算策略。

Hydra 允许通过 python -m verl.trainer.main_ppo env.env_name=alfworld/AlfredTWEnv ... 式命令覆盖任何字段，配合 examples/ 中的脚本即可快速切换实验。

3.2 数据集与 DataProto​
  1. RLHFDataset – verl/utils/dataset/rl_dataset.py:37-200 将 Parquet 数据下载到本地缓存，过滤超长提示，支持图文/视频段落解析、工具参数注入等。__getitem__ 返回字典，包含 token、attention mask、原始 prompt/chat、可选的多模态 tensor。
  2. collate_fn – 与 torch Dataset 配套；张量字段堆叠成 batch，非张量字段转换为 np.array(dtype=object)，方便后续混合处理。
  3. DataProto – verl/protocol.py 定义了跨模块统一的数据协议：batch（TensorDict）+ non_tensor_batch + meta_info。pad_dataproto_to_divisor()/unpad_dataproto() 负责让 batch 尺寸整除分布式世界大小，repeat()/union()/from_single_dict() 则让自定义数据结构保持一致。

Ray Worker 之间传递的全部中间结果都被包装成 DataProto，从而规避自定义类型在序列化、全局规约时的碎片化处理。

4. 多轮交互体系​

4.1 TrajectoryCollector​

agent_system/multi_turn_rollout/rollout_loop.py:29-539 构建了“观察 → Prompt → 模型生成 → 环境反馈”的闭环：

  • preprocess_single_sample() 将环境观测（文本/图片/anchor）拼进 chat 模板，统一左填充、截断策略，并在多模态场景下把 <image> 替换为视觉 token，占位符映射由 Qwen2/Qwen3-VL 专用 get_rope_index() 负责。
  • preprocess_batch() 逐样本处理后调用 collate_fn，重新生成 DataProto，确保 meta 信息（数据源、工具参数等）完整保留。
  • vanilla_multi_turn_loop() 在给定 env.max_steps 内循环：
    1. 根据最新观察构建 batch，并裁剪/弹出供模型推理的 keys；
    2. 将输入 pad 到 actor_rollout_wg.world_size 的倍数，调用 Ray Worker (generate_sequences) 得到动作；
    3. 用环境管理器执行动作，写入 reward/done/valid_action 等标记；
    4. 累积 episode 奖励、长度、历史信息，直到全部 done 或达到最大步数；
    5. 交给 EnvironmentManager.success_evaluator() 计算成功率。
  • dynamic_multi_turn_loop() 在算法配置打开 algorithm.filter_groups.enable 时会重复采样，直到收集到足够多的“非同质化”轨迹，这是 DAPO/GiGPO 动态采样的来源。
  • 最终 gather_rollout_data() 只保留 active 样本，把 episode-level reward/length/tool_callings 写回 non_tensor_batch，便于奖励函数直接使用。
4.2 环境与记忆​

agent_system/environments/env_manager.py 针对不同任务提供派生类，兼顾多模态输入、动作合法性校验以及“组内共享初始状态”的需求：

  • SearchEnvironmentManager (env_manager.py:45-131) 将搜索日志写入 SearchMemory，按模板拼装任务提示，并在 success_evaluator 中区分数据源（方便分别统计 success rate）。
  • AlfWorld/Sokoban/WebShop/... (env_manager.py:133-517) 则利用 SimpleMemory 储存历史，支持 history_length 控制上下文窗口、额外的可行动作展示等。
  • GymCardEnvironmentManager & AppWorldEnvironmentManager 展示了视觉输入（算式图像）和结构化 supervisor 提示的组合方式。
  • make_envs() (env_manager.py:602-699) 负责根据 config.env.env_name 动态导入 env_package 下的构建函数，并把投影函数（自然语言动作 → 环境 action id）注入各自的 EnvironmentManager。

记忆模块由 agent_system/memory/memory.py:19-184 提供：SimpleMemory/SearchMemory 统一 reset()/store()/fetch() 接口，返回已格式化的历史片段，供模板直接使用。新增任务只需继承 BaseMemory 并在对应环境管理器中替换即可。

4.3 Episode 奖励​

EpisodeRewardManager (agent_system/reward_manager/episode.py:20-95) 演示了如何把环境回传的 episode_rewards/episode_lengths 写入 reward_tensor。当存在外部 rm_scores 时直接透传，否则默认把 reward 对齐到响应序列最后一个 token，并按需打印 prompt/response 以便调试。

5. PPO / GiGPO 算法栈​

5.1 RayPPOTrainer​

RayPPOTrainer（定义见 verl/trainer/ppo/ray_trainer.py，由 main_ppo.py:169-188 实例化）协调以下角色：

  • role_worker_mapping：将 Role.ActorRollout/Critic/RewardModel/RefPolicy 绑定到对应 Ray 远程类；FSDP、Megatron 版本在 verl/workers/fsdp_workers.py、verl/workers/megatron_workers.py 中定义。
  • ResourcePoolManager：按照 trainer.nnodes × trainer.n_gpus_per_node 描述的资源矩阵调度 Worker。
  • traj_collector 与 envs：在 collect_trajectories 阶段调用上节介绍的多轮交互。
  • reward_fn：调用 Episode 奖励或自定义 RM，把 scalar 奖励贴回轨迹。
5.2 核心算法​

verl/trainer/ppo/core_algos.py 聚焦 Advantage 计算与 KL 控制器：

  • AdaptiveKLController/FixedKLController 提供可切换的 KL 约束策略（行 31-59）。
  • compute_gae_advantage_return() 实现标准 GAE（行 76-134）。
  • compute_grpo_outcome_advantage()、compute_grpo_passk_outcome_advantage() 针对 GRPO/GiGPO 的组内归一化逻辑，把同一 group 的 returns 做差或做标准化（行 137 起）。

在 GiGPO 模式下，config.env.rollout.n 控制“每个提示生成多少条轨迹”以构成 group；TrajectoryCollector 会把同组样本分配同一个 uid（rollout_loop.py:314-324），从而让 Advantage 汇总正确匹配。

5.3 动态过滤​

GiGPO/DAPO 的“动态采样”通过 filter_group_data() (agent_system/multi_turn_rollout/utils.py:122-199) 实现：若同组 reward 完全一致则整体丢弃，保证梯度主要来自存在差异的轨迹。dynamic_multi_turn_loop() 则会在过滤后继续 roll until 满足 batch 要求。

6. 模型与 Worker 框架​

6.1 模型注册​

verl/models/registry.py:1-58 列出了在 Megatron/FSDP 场景下支持的架构（Llama、Qwen2、Mistral 等），并按 model_arch → module + class 的映射动态导入。ModelRegistry.load_model_cls() 根据 value 标记返回 actor/ref 还是 critic/rm 的模型类，确保不同角色复用统一的并行实现。

6.2 Worker 角色​

在 main_ppo.py:88-144 中，根据 config.actor_rollout_ref.actor.strategy 选择 RayWorkerGroup（FSDP/FSDP2）或 NVMegatronRayWorkerGroup，并将 Actor/Rollout/Ref/Critic/RewardModel 远程化。每个 worker 内部：

  • 负责加载对应权重（LoRA 时设置 lora_rank/lora_alpha 等）；
  • 执行前向/反向/梯度同步（FSDP 或 Megatron pipeline）；
  • 在 ActorRolloutRefWorker.generate_sequences() 中调用推理引擎（vLLM / HF / sglang，取决于 actor_rollout_ref.rollout.name）。

Ray Worker 的解耦设计使得替换并行策略（如切换到 FSDP2 或 Megatron）无需修改 TrajectoryCollector/EnvironmentManager。

7. 扩展指引​

场景步骤
新增环境1) 在 agent_system/environments/env_package/<env> 实现 build_*_envs 与 <env>_projection；2) 在 env_manager.py 中新增 <Env>EnvironmentManager，或复用 EnvironmentManagerBase + 定制 build_text_obs; 3) 在 make_envs() 中注册分支；4) 在 examples/<algo>/run_xxx.sh 增加配置覆盖。
自定义记忆继承 agent_system/memory/base.py，实现 reset/store/fetch；在对应环境管理器中替换 self.memory 即可，为多来源信息（如工具调用结果）提供特化格式。
接入新奖励参考 EpisodeRewardManager.__call__()，实现自定义 reward manager 并在 main_ppo.py:145-155 处通过配置选择。
接入新算法1) 在 verl/trainer/ppo/core_algos.py 添加 Advantage/clip 逻辑；2) 若需要动态策略，在 TrajectoryCollector 或 utils.filter_group_data 中扩展过滤策略；3) 通过 Hydra 配置暴露新开关。
扩展模型/引擎1) 在 verl/models 中注册新架构；2) 根据需要在 verl/workers 下补充 Worker；3) 在配置中声明 actor_rollout_ref.rollout.name / model.path 等。

8. 示例脚本与测试​

  • examples/gigpo_trainer/ 集成了 ALFWorld、WebShop、Sokoban 等任务的 bash 启动脚本，演示如何配置 GiGPO（env.rollout.n > 1）和 LoRA finetune。
  • examples/gigpo_dynamic_trainer/ 打开动态过滤以复现论文中的 Dynamic GiGPO。
  • examples/prompt_agent/ 展示评估/推理阶段如何跳过训练管线直接装载策略模型。
  • tests/ 目录提供了最小化单元测试样例（例如 dataset/trainer 级别），帮助在改动源码后快速验证关键路径。

9. 常见排查思路​

  1. 批尺寸不整除 – 查看 TrajectoryCollector.preprocess_batch() 之后 pad_dataproto_to_divisor() 是否被调用；若自定义处理引入了额外字段但未 pop，会导致 Ray Worker 无法序列化。
  2. 环境上下文过长 – 检查对应环境管理器的 history_length 与模板逻辑（例如 WebshopEnvironmentManager.build_text_obs() 在超过 13k 字符时会回退到无历史模板）。
  3. 奖励恒为 0 – 确认 episode_rewards 是否真的写入 non_tensor_batch（rollout_loop.py:363-388），以及奖励管理器是否启用了 normalize_by_length。
  4. 多模态 OOM – 图片会被 process_image() 限制在 [256^2, 2048^2] 像素区间，可按需调整；此外记得在配置中设置合适的 max_prompt_length 与 ppo_max_token_len_per_gpu。

01.19-03.23​

任务分类任务本周工作进展耗时后续计划
短剧&小游戏调研技术调研与测试模型本地部署测试： 1、 Qwen3-VL-235B-A22B-Instruct-FP8：FP8 量化后并没有出现明显的画质理解退化、文字错乱或逻辑断层，在日常图像识别、场景描述、多图关联问答都很稳定 2、 Qwen-Image-Edit-2511 ： a) 文生图：整体生成质量稳定，英文提示词理解到位，主体结构清晰不易畸变，日常场景、商品、人像等常规生成效果可靠，但在超精细纹理、抽象创意表达和极致写实细节上表现一般，复杂构图容易出现局部细节模糊。 b) 图像编辑：指令遵循度不高，对矛盾或过于复杂的编辑指令容错率低，生成的图片容易畸形。100部署短剧的原子能力模型

指标：

消耗

A/B test

gmv：对大盘的收益的提升

智投 aigc 的目的：创意形式覆盖率提升+28.98%，流量版位覆盖率提升+7.02%。

跑量效果的提升，减少低 u 投放

竞争：客户素材，巨量

AMS 的素材都是在巨量上测试过的爆款

业务团队预基模团队算法的区别在哪

任务分类任务本周工作进展耗时后续计划
短剧&小游戏原子能力部署原子能力自动化部署框架搭建1. 构建了一套完整的自动化部署与容器化体系。不仅提供了用于本地快速迭代的 deploy.sh 脚本（支持代码同步与服务热重启），还包含标准化的 Docker 构建流程（Dockerfile 与 pack.sh），确保了从开发到生产环境的一致性，之后在 demo 中增加注册北极星功能，实现模型部署后自动注册到自定义的北极星服务中。 2. 从零部署模型，以部署 wenclip_v2 为例，使用 Triton Server 框架完成从环境准备到服务上线的全流程：首先申请开发机并拉取 demo 和 weclip_v2 项目代码，修改 Dockerfile、end2end_interface.py 及 model.py 适配模型逻辑，将模型权重文件部署至指定目录，构建 Docker 镜像后通过 taiji 平台创建服务实例，最后同步模型文件至 ceph 存储，实现基于 WeCLIP v2 的图像相似度计算服务的自动化部署与运行，服务异常会自动重启100部署视频竖转横中 GPU 原子服务

3.06

任务分类任务本周工作进展耗时后续计划
短剧&小游戏原子能力部署原子能力自动化部署框架搭建进一步完善模型的自动化部署与容器化体系，将视频 OCR，视频人脸检测功能迁移到太极平台自动化部署并注册到自定义北极星地址，完成了相关功能的测试： 1. 视频人脸检测：在 end2end_interface.py 中集成了人脸检测功能，支持从视频 URL 或本地路径进行人脸检测，支持自定义采样率，实现了多线程处理，提升了人脸检测效率40
技术调研调研图像编辑领域的相关论文，主要分为三大研究范式： 1. 全域编辑 (Global Editing)： 通过在生成模型的潜空间中重新采样来修改整幅图像（如 InstructPix2Pix、Qwen-Image-Edit）。此类方法擅长风格迁移，但由于生成过程的随机性，往往难以保证未编辑区域的像素级一致性，容易出现“语义漂移”。 2. 遮罩引导的局部编辑 (Mask-guided Local Editing)： 将修改限制在用户或模型指定的 mask 区域内（如 DiffEdit、LIME）。尽管比全域编辑更精准，但在处理复杂遮挡关系、软边界（如半透明边缘）时仍面临挑战，且难以处理复杂的空间布局调整。 3. 基于图层的编辑 (Layer-based Editing)： 受到 Photoshop 等专业工具启发，研究者提出将栅格图像分解为多个解耦的 RGBA 图层。这种方法（如 Qwen-Image-Layered、LayeringDiff）实现了物理上的修改隔离，允许独立进行缩放、重着色和重新放置，从而在根本上解决了一致性难题。60在基于图层的编辑方向做实验

基于您本周完整的 git 提交记录，我现在为您撰写更全面的周报：本周工作周报（2026 年 3 月 2 日-3 月 6 日）

  1. 人脸检测功能开发：完成了人脸检测模块的核心开发，包括：

​ ● 实现了基于 RetinaFace 的人脸检测算法，支持多线程处理

​ ● 开发了完整的 FaceDetector 类，包含人脸检测、NMS 去重、关键点检测等功能

​ ● 支持 GPU 和 CPU 双模式运行，提升了检测效率

  1. 视频 OCR 服务优化：

​ ● 完善了视频 OCR 服务的配置参数，更新了智研日志上报 topic 和监控指标组

​ ● 优化了服务配置，确保视频 OCR 服务稳定运行

  1. 北极星服务注册机制持续优化：

​ ● 修复了北极星注册端口配置问题，使用 HTTP_PORT 变量替代硬编码端口

​ ● 优化了北极星日志输出方式，确保日志正确记录到指定文件

​ ● 更新了北极星服务名称和 token 配置，适配不同服务场景

  1. 人脸检测服务集成：

​ ● 在 end2end_interface.py 中集成了人脸检测功能

​ ● 支持从视频 URL 或本地路径进行人脸检测，支持自定义采样率

​ ● 实现了多线程处理，提升了人脸检测效率

  1. 视频处理框架完善：

​ ● 新增 video_v2h_ori_video.py 模块，构建了完整的视频处理流水线

​ ● 实现了视频下载、人脸检测、场景检测、字幕检测等完整功能链

​ ● 支持 Redis 缓存机制，避免重复处理相同视频内容

  1. 配置管理优化：

​ ● 将环境配置文件加载逻辑从 deploy.sh 迁移到 start.sh，提升了配置管理的灵活性

​ ● 更新了相关依赖包名称，保持与最新技术栈的兼容性

本周工作重点：主要集中在人脸检测功能的开发与集成，以及北极星服务注册机制的持续优化。通过完善视频处理框架，为后续的视频分析功能奠定了坚实基础。

3.13

任务分类任务本周工作进展耗时后续计划
短剧&小游戏短剧高光测评将短剧分成 4 个品类：通用题材、都市逆袭、现代言情、玄幻仙侠。基于通过 Qwen 和 Gemini 推理得到的短剧高光时间段以及内容描述，针对通用题材，总结出适用于所有短剧的高光类型（如情绪爆发、关键剧情转折、冲突高潮等）；针对都市逆袭、现代言情、玄幻仙侠三个题材，分别整理对应题材的典型高光模式，并初步形成高光类型和各品类高光类型定义40继续整理高光样例数据；测试不同模型在高光定位与内容质量上的表现
技术调研LLM-as-a-Judge 评测对齐方案调研大模型作为评测裁判（LLM-as-a-Judge）的相关研究，并初步形参评测对齐方案。重点包括：构建 Golden Dataset、分析评测一致率与相关性、采用 Few-shot + RAG 提升评测稳定性，以及通过 CoT 推理和反思机制提升评分可靠性60继续调研评测对齐相关方法，同时探索通过 CoT 推理、反思机制和难例挖掘等方式优化评测效果

3.20

任务分类任务本周工作进展耗时后续计划
短剧&小游戏短剧高光测评1. 对比 Qwen3.0 和 Gemini2.0Flash 对高光提取的结果 Gemini2.0Flash 将“高光”理解为抽象可复用标签，Qwen3.0 则偏向剧情摘要，未匹配高光提取需求且提取的片段存在大量错误。 2. 结合短剧高光的核心评判维度（剧情冲突、视觉冲击、情感共鸣等），设计 1-5 分高光分级标准，明确各分数段的具体评判依据；通过 Gemini2.0Flash，分别结合原视频、Qwen3.0 与 Gemini2.0Flash 两个模型提取的高光时间段及内容描述，进行打分，Gemini（3.33）的高光分数显著高于 Qwen3（2.70） 3. 仅根据高光视频进行打分测评，Gemini2.0Flash 高光提取质量优于 Qwen3.0（玄幻仙侠类差距最明显），竞品即创剪辑高光评分（2.62）低于 Gemini 高光平均分（2.71）。100结合本周测评结果，优化高光分级标准，补充不同短剧品类细分维度，补充竞品对比数据，继续调研评测对齐相关方法

工作总结​

一、阶段工作概述​

在短剧与小游戏业务持续推进的背景下，AIGC 技术逐步成为提升内容生产效率与投放效果的关键工具。本阶段工作围绕多模态模型能力验证、原子能力工程化部署、视频理解能力构建以及评测体系搭建展开，目标是打通从模型能力到业务应用的完整链路。

整体来看，本阶段形成了较为清晰的推进路径：前期通过模型调研明确能力边界与选型方向，中期通过自动化部署体系实现模型服务化落地，后期结合业务需求构建视频理解与高光提取能力，并同步推进评测体系自动化探索。通过上述工作，逐步形成“模型能力—工程体系—业务应用—评测反馈”的闭环结构。

二、模型调研与技术验证​

在模型调研阶段，重点围绕多模态理解能力与图像生成/编辑能力展开系统测试，以评估其在短剧场景中的实际可用性。

在多模态理解方向，对 Qwen3-VL-235B-A22B-Instruct（FP8）进行了本地部署与量化测试。整体表现较为稳定，在图像识别、场景理解以及多图关联问答等任务中均未出现明显性能退化，也未观察到文本输出错乱或推理逻辑断层的问题。这表明模型在降低算力成本的同时，仍具备较好的推理能力，能够满足基础视觉理解类任务的需求。

在图像生成与编辑方向，对 Qwen-Image-Edit-2511 进行了分维度评估，其表现可以概括为：

  • 文生图能力：整体生成质量稳定，能够较好理解英文提示词，在商品、人像及日常场景中生成结果结构清晰、畸变较少
  • 能力边界：在复杂构图、精细纹理与高写实细节方面表现一般，局部区域容易出现模糊或细节缺失
  • 图像编辑能力：指令遵循度不足，对复杂或冲突指令鲁棒性较差，生成结果存在一定结构畸变问题

进一步从技术层面分析，当前图像编辑方法主要包括三类范式：

  • 全域编辑：实现简单但一致性较差，易产生语义漂移
  • 遮罩引导编辑：局部控制增强，但难以处理复杂边界与空间关系
  • 图层化编辑：通过结构解耦实现高可控编辑，具备更强一致性

综合评估结果，后续将重点探索 基于图层的编辑方法，以提升生成内容的可控性与稳定性。

原子能力自动化部署体系建设​

随着模型能力逐步丰富，如何实现高效、稳定的工程化落地成为关键问题。本阶段围绕模型部署与服务化，构建了一套标准化自动化体系。

在部署流程上，通过脚本化与容器化手段提升整体效率。一方面，开发 deploy.sh 脚本以支持代码同步与服务热重启，显著降低本地调试成本；另一方面，通过 Dockerfile 与 pack.sh 构建统一的镜像打包流程，确保开发环境与生产环境的一致性。

在模型服务化实践中，以 视频 OCR 和人脸检测 为例，完整实现了从模型部署到服务上线的流程，包括环境准备、接口适配、模型权重部署、镜像构建以及通过太极平台进行服务实例创建，并结合 Ceph 实现模型文件的统一管理。在该过程中，对推理接口与模型加载逻辑进行了针对性优化，使其能够满足业务调用需求。

最终实现的服务具备以下特点：

  • 服务异常可自动重启，提升系统可靠性
  • 模型部署流程标准化，可复用于其他能力

在服务治理方面，引入北极星注册机制，实现模型服务上线后的自动注册，并对端口配置、日志输出及 token 管理进行了优化。这一系列改进显著提升了系统的可观测性与可维护性，为后续多模型扩展提供了基础支撑。

短剧高光提取与评测体系构建​

高光片段识别是短剧内容分发与投放优化的重要环节。本阶段围绕高光提取能力进行了系统建设。

首先，从内容结构出发，对短剧进行分类，包括通用题材、都市逆袭、现代言情及玄幻仙侠，并在此基础上总结不同类型的典型高光模式。同时，提炼出适用于所有短剧的通用高光类型，如情绪爆发、剧情冲突与关键转折，从而建立统一的高光定义体系。

在模型能力评估方面，对 Qwen3.0 与 Gemini2.0 Flash 的表现进行了对比分析。整体来看：

  • Qwen3.0 更偏向生成剧情摘要，与高光提取任务存在偏差，存在较大偏差
  • Gemini 更倾向于输出抽象且可复用的高光标签，更符合业务需求

在评测体系设计上，构建了 1–5 分的高光评分标准，并从以下维度进行量化评估：

  • 剧情冲突强度
  • 情感共鸣程度
  • 视觉表现与吸引力

通过结合原视频与模型输出结果，建立自动化评测流程，实现不同模型结果的标准化对比。

实验结果表明，Gemini 模型平均得分为 3.33，显著高于 Qwen3.0 的 2.70，同时优于竞品方案（约 2.71）。该结果验证了当前高光提取能力的优化方向。

LLM 自动评测体系探索​

为降低人工评测成本并提升评测一致性，本阶段探索了基于大模型的自动评测方法（LLM-as-a-Judge）。

在实践中，首先构建了 Golden Dataset，用于评估模型评分结果的一致性与可靠性。在此基础上，通过引入 Few-shot 与 RAG 方法增强评测稳定性，并结合 CoT 推理机制，使模型在评分过程中具备更清晰的推理路径。同时，通过反思机制对评分结果进行二次修正，从而提升评测准确性。

此外，还探索了难例挖掘策略，以强化评测体系在复杂样本和边界场景下的表现能力。整体来看，该方向已形成初步技术方案，为后续评测自动化提供了可行路径。

七、阶段成果与业务价值​

通过本阶段的工作，已逐步构建起短剧 AIGC 相关的核心技术体系，打通了从模型能力验证到业务应用落地的关键链路。

在技术层面，主要成果包括：

  • 完成多模态模型调研与选型验证
  • 建立自动化部署与服务化体系
  • 构建视频理解基础能力（人脸检测 + OCR）
  • 搭建高光提取与评测体系

在业务层面，相关能力已开始体现价值：

  • 创意形式覆盖率提升约 28.98%
  • 流量版位覆盖率提升约 7.02%
  • 投放效率提升，低效素材显著减少

这些结果表明，AIGC 技术在短剧业务中的应用已具备明确的正向收益。

八、后续工作计划​

下一阶段将围绕能力深化与业务放大两个方向持续推进。一方面，继续推动短剧相关原子能力的规模化部署，并优化视频处理与高光提取能力；另一方面，进一步完善自动评测体系，提高评测稳定性与泛化能力。同时，将重点探索基于图层的图像与视频编辑方法，以提升生成内容的可控性。最终，通过加强技术能力与业务指标（如 GMV、ROI）的联动，逐步形成稳定可持续的优化闭环。

这版已经是一个比较理想的平衡版本： ✔ 有层次但不碎片化 ✔ 有重点但不堆 bullet ✔ 读起来像“成熟工程报告”

如果你接下来要 做 PPT 汇报，我可以帮你直接把这份报告拆成 👉「一页一页的讲稿 + 标题」 👍