计算机前沿技术-人工智能算法-大语言模型-最新研究进展-2024-11-03

sp_fyf_20242024-11-13 10:57

计算机前沿技术-人工智能算法-大语言模型-最新研究进展-2024-11-03

目录

文章目录

1. Language Models are Hidden Reasoners: Unlocking Latent Reasoning Capabilities via Self-Rewarding

Authors: Haolin Chen, Yihao Feng, Zuxin Liu, Weiran Yao, Akshara Prabhakar,

Shelby Heinecke, Ricky Ho, Phil Mui, Silvio Savarese, Caiming Xiong, Huan Wang

https://arxiv.org/abs/2411.04282

语言模型是隐藏的推理者：通过自我奖励解锁潜在推理能力

摘要

本文介绍了一种名为LaTent Reasoning Optimization（LaTRO）的框架，旨在通过变分方法优化大型语言模型（LLMs）的推理能力。LaTRO通过将推理过程视为从潜在分布中采样，并自我奖励的方式来优化，使得LLMs能够在不需要外部反馈或奖励模型的情况下，同时提高推理过程和评估推理质量的能力。通过在GSM8K和ARC-Challenge数据集上的实验，LaTRO在多个模型架构上显示出显著的性能提升，证明了预训练LLMs具有可以通过LaTRO优化方法解锁和增强的潜在推理能力。

研究背景

大型语言模型（LLMs）在多个领域展现出了令人印象深刻的能力，但在需要多步推理的复杂任务上仍然存在挑战。尽管基于提示的方法（如Chain-of-Thought，CoT）可以在推理时提高LLMs的推理能力，但在训练期间优化推理能力仍然是一个挑战。LaTRO框架的提出正是为了解决这一问题。

问题与挑战

LLMs在处理需要复杂推理的问题时面临几个挑战：

  1. 高质量推理数据的稀缺限制了传统监督式微调方法的应用。
  2. 监督式微调可能导致问题解决策略的多样性不足，从而影响模型性能。
  3. 从人类反馈中通过强化学习提高推理能力存在挑战，如准确评估推理路径的质量和有效性的难度。

如何解决

LaTRO通过以下方式解决上述挑战：

  1. 将推理过程视为从潜在分布中采样，并使用变分框架进行优化。
  2. 引入自我奖励机制，利用模型自身的概率估计来评估推理质量。
  3. 在多个模型架构和推理任务上验证LaTRO的有效性，展示其在解锁语言模型潜在推理能力方面的优势。

创新点

LaTRO的主要创新点包括：

  1. 将LLMs的推理优化与潜在变量模型理论联系起来。
  2. 提出自我奖励机制，利用模型自身的概率估计作为奖励信号。
  3. 在多个模型架构和任务上验证了LaTRO的有效性，证明了其在提高语言模型推理能力方面的潜力。

算法模型

LaTRO的核心是一个变分框架，它通过以下步骤优化推理过程：

  1. 将推理路径视为潜在变量，并使用自我奖励来优化其分布。
  2. 通过自我奖励机制，模型能够评估生成的推理路径的质量，并更新参数以偏好高质量的推理路径。
  3. LaTRO不需要任务特定的少量样本或外部奖励模型，能够同时提高模型生成良好推理路径的能力和评估这些路径质量的能力。

实验效果

LaTRO在GSM8K和ARC-Challenge数据集上进行了广泛的实验，结果表明：

  • 在GSM8K数据集上，LaTRO提高了零样本准确率，平均超过基线模型12.5%，超过监督微调模型9.6%。
  • 在ARC-Challenge数据集上，LaTRO模型虽然提升幅度较小，但仍然优于基线模型。
  • LaTRO还能够压缩推理过程，将计算负担从推理时转移到训练时。

重要数据与结论

  • 在GSM8K数据集上，LaTRO在Phi-3.5模型上提高了19.5%的准确率，从72.9%提升到87.6%。
  • 在ARC-Challenge数据集上，LaTRO在Llama-3.1-8B模型上提高了1.6%的准确率，从81.4%提升到83.0%。

推荐阅读指数：★★★★☆

代码： https://github.com/SalesforceAIResearch/LaTRO

dart 复制代码 
import gc
import math
import time
from typing import List, Optional, Tuple

import numpy as np
import torch
import torch.nn as nn
from datasets import Dataset
from transformers import (
    GenerationConfig,
    PreTrainedTokenizer,
    TrainerCallback,
)
from transformers.integrations.deepspeed import deepspeed_load_checkpoint
from transformers.utils import is_sagemaker_mp_enabled
from trl.models.utils import unwrap_model_for_generation
from trl.trainer.utils import (
    first_true_indices,
)
from .trainer_config import TrainerConfig
from .base_trainer import BaseTrainer
from ..utils.trainer_utils import (
    generate,
    truncate_response,
    pad_mask_rearrange,
    get_logprob_reward,
)

class LatroTrainer(BaseTrainer):
    """
    Args:
        config (`TrainerConfig`):
            training configs,
        tokenizer (`PreTrainedTokenizer`):
            tokenizer for the models, assuming all models are from the same family
        policy (`nn.Module`):
            the LM "q_phi" to sample rationale from
        ref_policy (`nn.Module`):
            the reference model "p_0"
        train_dataset (`Dataset`):
            training dataset, should have columns "queries" and "responses"
        eval_dataset (`Dataset`):
            evaluation dataset used during training epochs, should have columns "queries" and "responses"
        optimizers (`torch.optim.Optimizer, torch.optim.lr_scheduler.LambdaLR`):
            a tuple of (optimizer, learning rate scheduler) for optimization,
            for now always prepare an optimizer for all models when init the trainer.
        callbacks (`Optional[List[TrainerCallback]]`):
            callback functions used to customize the training
    """
    def __init__(
        self,
        config: TrainerConfig,
        tokenizer: PreTrainedTokenizer,
        train_dataset: Dataset,
        eval_dataset: Dataset,
        policy: nn.Module,
        ref_policy: Optional[nn.Module] = None,
        # less commonly used
        optimizers: Tuple[torch.optim.Optimizer, torch.optim.lr_scheduler.LambdaLR] = (None, None),
        callbacks: Optional[List[TrainerCallback]] = None,
    ) -> None:
        super().__init__(
            config=config,
            tokenizer=tokenizer,
            train_dataset=train_dataset,
            policy=policy,
            ref_policy=ref_policy,
            eval_dataset=eval_dataset,
            optimizers=optimizers,
            callbacks=callbacks
        )

    def train(self, resume_from_checkpoint: str = None):
        args = self.args
        accelerator = self.accelerator
        self.model_wrapped = self.model
        ref_policy = self.ref_policy
        tokenizer = self.tokenizer
        dataloader = self.dataloader
        device = accelerator.device
        def repeat_generator():
            while True:
                yield from dataloader
        # ckpt loading
        if resume_from_checkpoint is not None:
            if self.is_deepspeed_enabled:
                deepspeed_load_checkpoint(
                    self.model_wrapped, resume_from_checkpoint, load_module_strict=True # not LoRA
                )
            elif is_sagemaker_mp_enabled() or self.is_fsdp_enabled:
                self._load_from_checkpoint(resume_from_checkpoint, self.model_wrapped)
        # Check if saved optimizer or scheduler states exist
        self._load_optimizer_and_scheduler(resume_from_checkpoint)
        model = self.model
        if args.gradient_checkpointing:
            model.gradient_checkpointing_enable()
        optimizer = self.optimizer

        iter_dataloader = iter(repeat_generator())
        generation_config = GenerationConfig(
            max_new_tokens=args.response_length,
            temperature=1, # (args.temperature + 1e-7),
            top_k=0.0,
            top_p=1.0,
            do_sample=True,
        )

        accelerator.print("===training policy===")
        start_time = time.time()
        rloo_loss_stats = torch.zeros(args.gradient_accumulation_steps, device=device)
        sft_loss_stats = torch.zeros(args.gradient_accumulation_steps, device=device)
        model.train()

        # trainer state initialization
        self.state.best_metric = 0.0
        self.state.global_step = 0
        self.state.episode = 0
        self.state.max_steps = args.num_total_batches
        self.state.num_train_epochs = args.total_episodes / self.train_dataset_len
        # Compute absolute values for logging, eval, and save if given as ratio
        if args.logging_steps is not None:
            if args.logging_steps < 1:
                self.state.logging_steps = math.ceil(self.state.max_steps * args.logging_steps)
            else:
                self.state.logging_steps = args.logging_steps
        if args.eval_steps is not None:
            if args.eval_steps < 1:
                self.state.eval_steps = math.ceil(self.state.max_steps * args.eval_steps)
            else:
                self.state.eval_steps = args.eval_steps
        if args.save_steps is not None:
            if args.save_steps < 1:
                self.state.save_steps = math.ceil(self.state.max_steps * args.save_steps)
            else:
                self.state.save_steps = args.save_steps
        self.control = self.callback_handler.on_train_begin(args, self.state, self.control)

        for update in range(1, args.num_total_batches + 1):
            self.state.episode += 1 * args.batch_size
            data = next(iter_dataloader)
            # Part 1: Generating responses for (local_dataloader_batch_size * rloo_k) queries & advantage computation for RLOO
            with torch.no_grad(), unwrap_model_for_generation(model, self.accelerator) as unwrapped_model:
                queries = tokenizer(data["queries"], padding=True, return_tensors="pt")["input_ids"].to(device)
                final_responses = tokenizer(data["responses"], padding=True, add_special_tokens=False, return_tensors="pt")["input_ids"].to(device)
                queries = queries.repeat_interleave(args.rloo_k, 0)
                final_responses = final_responses.repeat_interleave(args.rloo_k, 0)
                context_length = queries.shape[1]
                accelerator.print("====RL sampling stage====")
                query_responses, responses, truncated_responses, response_ending_indices = [], [], [], []
                query_ppresponses, query_ppresponse_finals, query_context_lengths, reward_context_lengths = [], [], [], []
                logprobs, ref_logprobs, rewards = [], [], []
                for i in range(0, queries.shape[0], args.rollout_batch_size):
                    queries_rb = queries[i : i + args.rollout_batch_size]
                    final_responses_rb = final_responses[i : i + args.rollout_batch_size]
                    query_response_rb, _ = generate(
                        unwrapped_model,
                        queries_rb,
                        tokenizer.pad_token_id,
                        generation_config,
                    )

                    del _
                    gc.collect()
                    torch.cuda.empty_cache()

                    response_rb = query_response_rb[:, context_length:]

                    # 1.2 Reward & Advantage computation
                    # 1. Truncate response after the first occurrence of `stop_token_id`
                    # 2. Concatenation and Re-arrangement of query + truncated intermediate response + final_response
                    # 3. Run reward model on the query + postprocessed intermediate response + final_response
                    # 4. Filter response. Ensure that the sample contains stop_token_id
                    # NOTE: Without processing, concat (query + postprocessed intermediate response + final_response) should be something like:
                    #                                 <pad><bos>{query}, {reasoning}<pad>, <pad><end_of_thought>{final_answer}<eos>
                    # where <pad> is 0 to multiple pad tokens.
                    # But model.forward() would also not working with pad_tokens in the middle
                    # A better solution: rearrange all pad tokens to the beginning of each row while keeping the rest untouched, hence giving a batch like
                    #                                     <pad>, <bos>{query}, {reasoning}, <end_of_thought>{final_answer}<eos>
                    # since final_answer will always stay at the end of the sequence, first_true_indices(final_answer != pad_token_id) gives the pos of actual final_answer
                    # Hence ``first_true_indices(final_answer != pad_token_id) - 1 + query_ppresponse.shape[1]`` is the context length

                    truncated_responses_rb, response_ending_indices_rb = (
                        truncate_response(
                            args.stop_token_ids, tokenizer.pad_token_id, response_rb
                        )
                    )
                    query_ppresponses_rb = pad_mask_rearrange(
                        torch.cat((queries_rb, truncated_responses_rb), 1),
                        tokenizer.pad_token_id
                    )
                    query_context_lengths_rb = (query_ppresponses_rb.shape[1] - (response_ending_indices_rb + 1)).unsqueeze(1)

                    # penalty computation
                    logprobs_rb = get_logprob_reward(
                        model,
                        tokenizer.pad_token_id,
                        query_ppresponses_rb,
                        query_context_lengths_rb,
                    )
                    ref_logprobs_rb = get_logprob_reward(
                        ref_policy,
                        tokenizer.pad_token_id,
                        query_ppresponses_rb,
                        query_context_lengths_rb,
                    )

                    query_ppresponse_finals_rb = pad_mask_rearrange(
                        torch.cat((query_ppresponses_rb, final_responses_rb), 1),
                        tokenizer.pad_token_id
                    )
                    reward_context_lengths_rb = (
                        query_ppresponses_rb.shape[1]
                        + first_true_indices(final_responses_rb != tokenizer.pad_token_id)
                        - 1
                    ).unsqueeze(1)

                    rewards_rb = get_logprob_reward(
                        model,
                        tokenizer.pad_token_id,
                        query_ppresponse_finals_rb,
                        reward_context_lengths_rb,
                    )

                    query_responses.append(query_response_rb)
                    responses.append(response_rb)
                    truncated_responses.append(truncated_responses_rb)
                    response_ending_indices.append(response_ending_indices_rb)
                    query_ppresponses.append(query_ppresponses_rb)
                    query_ppresponse_finals.append(query_ppresponse_finals_rb)
                    query_context_lengths.append(query_context_lengths_rb)
                    reward_context_lengths.append(reward_context_lengths_rb)
                    logprobs.append(logprobs_rb)
                    ref_logprobs.append(ref_logprobs_rb)
                    rewards.append(rewards_rb)

                query_responses = torch.cat(query_responses, 0)
                responses = torch.cat(responses, 0)
                truncated_responses = torch.cat(truncated_responses, 0)
                response_ending_indices = torch.cat(response_ending_indices, 0)
                query_ppresponses = torch.cat(query_ppresponses, 0)
                query_ppresponse_finals = torch.cat(query_ppresponse_finals, 0)
                query_context_lengths = torch.cat(query_context_lengths, 0)
                reward_context_lengths = torch.cat(reward_context_lengths, 0)
                logprobs = torch.cat(logprobs, 0)
                ref_logprobs = torch.cat(ref_logprobs, 0)
                rewards = torch.cat(rewards, 0)

                # NOTE: another choice is to add penalty over the trajectories of the same prompt
                contain_stop_token = torch.any(truncated_responses == tokenizer.pad_token_id, dim=-1)
                if args.non_stop_penalty:
                    rewards = torch.where(contain_stop_token, rewards, args.penalty_reward_value * rewards.mean())
                    # mean_rewards = rewards.reshape(-1, args.rloo_k).mean(dim=1)
                    # rewards = torch.where(
                    #     contain_stop_token,
                    #     rewards,
                    #     args.penalty_reward_value * mean_rewards.repeat_interleave(args.rloo_k)
                    # )

                # Advantage computation
                kl_penalty = -args.kl_coef * (logprobs - ref_logprobs)
                mean_kl_penalty = kl_penalty.mean().detach()
                adjusted_rewards = rewards + kl_penalty

                # vectorized RLOO advantages implementation
                adjusted_rewards = adjusted_rewards.reshape(-1, args.rloo_k) # NOTE: shape (N, K), every row is rewards for one prompt
                baseline = (adjusted_rewards.sum(1, keepdim=True) - adjusted_rewards) / (args.rloo_k - 1)

                advantages = adjusted_rewards - baseline
                advantages = advantages.flatten()

                if args.num_evaluations > 0 and (update - 1) % self.evaluation_freq == 0:
                    self.log_training_samples(
                        queries,
                        responses,
                        truncated_responses,
                        query_ppresponse_finals,
                        final_responses,
                        rewards,
                        advantages,
                    )

                del logprobs, ref_logprobs, rewards, baseline, kl_penalty
                gc.collect()
                torch.cuda.empty_cache()

            # Part 2: Training loops
            accelerator.print("====Training stage====")
            local_batch_indices = np.random.permutation(args.local_batch_size)
            gradient_accumulation_idx = 0
            for micro_batch_start in range(0, args.local_batch_size, args.per_device_train_batch_size):
                with accelerator.accumulate(model):
                    micro_batch_end = micro_batch_start + args.per_device_train_batch_size
                    micro_batch_inds = local_batch_indices[micro_batch_start:micro_batch_end]
                    advantage_mb = advantages[micro_batch_inds]
                    query_ppresponses_mb = query_ppresponses[micro_batch_inds]
                    query_ppresponse_finals_mb = query_ppresponse_finals[micro_batch_inds]
                    query_context_length_mb = query_context_lengths[micro_batch_inds]
                    reward_context_length_mb = reward_context_lengths[micro_batch_inds]

                    # 2.1  Update policy model q_phi with RLOO
                    # 2.1.1  Compute RLOO Loss
                    rationale_logprobs = get_logprob_reward(
                        model,
                        tokenizer.pad_token_id,
                        query_ppresponses_mb,
                        query_context_length_mb,
                    )
                    rloo_losses = -advantage_mb * rationale_logprobs
                    rloo_loss = rloo_losses.mean()

                    # 2.1.2  Compute metrics for RLOO
                    with torch.no_grad():
                        rloo_loss_stats[gradient_accumulation_idx] = rloo_loss

                    # 2.2  Update reward model p_theta with SFT
                    # reward_sft_loss = - log_softmax(reward_model(final_response | query+response)

                    # 2.2.1  Compute SFT loss
                    rewards = get_logprob_reward(
                        model,
                        tokenizer.pad_token_id,
                        query_ppresponse_finals_mb,
                        reward_context_length_mb,
                    )
                    sft_loss = -rewards.mean()

                    # 2.2.2  Compute metrics for SFT
                    with torch.no_grad():
                        sft_loss_stats[gradient_accumulation_idx] = sft_loss

                    # 2.3  Gradient descent
                    loss = rloo_loss + args.sft_penalty * sft_loss
                    accelerator.backward(loss)
                    optimizer.step()
                    optimizer.zero_grad()
                gradient_accumulation_idx += 1
                # 2.4  del everything and empty cache
                # fmt: off
                del (
                    rationale_logprobs, rloo_losses, rloo_loss, loss, advantage_mb, query_ppresponses_mb,
                    query_ppresponse_finals_mb, reward_context_length_mb, sft_loss
                )
                # fmt: on
                gc.collect()
                torch.cuda.empty_cache()

            # Part 3: Logging metrics
            with torch.no_grad():
                response_lengths = (response_ending_indices + 1).float().mean()
                num_finished_thoughts = contain_stop_token.sum(0)
                eps = int(self.state.episode / (time.time() - start_time))
                metrics = {}
                metrics["eps"] = eps
                metrics["objective/kl_penalty"] = self.accelerator.gather(mean_kl_penalty).mean().item()
                metrics["objective/rlhf_reward"] = self.accelerator.gather(adjusted_rewards).mean().item()
                metrics["objective/advantage_avg"] = self.accelerator.gather(advantages).mean().item()
                metrics["loss/policy_avg"] = self.accelerator.gather(rloo_loss_stats).mean().item()
                metrics["loss/sft_avg"] = self.accelerator.gather(sft_loss_stats).mean().item()
                metrics["val/num_stop_tokens"] = self.accelerator.gather(num_finished_thoughts).sum().item()
                metrics["val/perc_finished_thoughts"] = metrics["val/num_stop_tokens"]/(args.local_batch_size * self.accelerator.num_processes)
                metrics["val/avg_rationale_length"] = self.accelerator.gather(response_lengths).mean().item()
                metrics["lr"] = self.lr_scheduler.get_last_lr()[0]
                metrics["episode"] = self.state.episode
                self.state.epoch = self.state.episode / self.train_dataset_len  # used by self.log
                self.state.global_step += 1
                self.log(metrics)

                del (
                    mean_kl_penalty, adjusted_rewards, num_finished_thoughts, response_lengths, response_ending_indices,
                    query_ppresponse_finals, contain_stop_token, reward_context_lengths, query_responses,
                    responses, advantages
                )
                gc.collect()
                torch.cuda.empty_cache()

            self.lr_scheduler.step()
            self.control = self.callback_handler.on_step_end(args, self.state, self.control)
            if self.control.should_save:
                self._save_checkpoint(model, trial=None, metrics=metrics)
                self.control = self.callback_handler.on_save(self.args, self.state, self.control)

            if args.num_evaluations > 0 and (update - 1) % self.evaluation_freq == 0:
                accelerator.print("====Evaluation stage====")
                self.evaluation()
            gc.collect()
            torch.cuda.empty_cache()

        # HF trainer specifics
        self.control = self.callback_handler.on_train_end(args, self.state, self.control)
        if self.control.should_save:
            self._save_checkpoint(model, trial=None, metrics=None)
            self.control = self.callback_handler.on_save(self.args, self.state, self.control)

2. CaPo: Cooperative Plan Optimization for Efficient Embodied Multi-Agent Cooperation

Authors: Jie Liu, Pan Zhou, Yingjun Du, Ah-Hwee Tan, Cees G.M. Snoek, Jan-Jakob

Sonke, Efstratios Gavves

https://arxiv.org/abs/2411.04679

CAPO: 合作计划优化，用于高效的具体化多智能体合作

摘要

本文提出了一种名为合作计划优化（Cooperative Plan Optimization, CaPo）的框架，旨在提高基于大型语言模型（LLM）的具体化智能体之间的合作效率。CaPo通过两个阶段来提升合作效率：1）元计划生成，2）进度自适应的元计划与执行。在第一阶段，所有智能体分析任务，讨论并共同创建一个分解任务为子任务并详细步骤的元计划，确保长期战略和协调计划的有效性。在第二阶段，智能体根据元计划执行任务，并根据他们的最新进展动态调整元计划，通过多轮讨论来消除冗余动作，提高整体合作效率。在ThreeDworld多智能体运输和Communicative Watch-And-Help任务上的实验结果表明，CaPo与现有技术相比，具有更高的任务完成率和效率。

研究背景

大型语言模型（LLMs）在理解和生成人类语言、复杂推理和规划方面展现出了显著的能力。这些进步使得基于LLM的智能体能够自主制定计划和执行推理，以协助人们完成日常活动。然而，现有的方法往往在没有长期战略和合作规划的情况下执行动作，导致在复杂任务中出现冗余步骤、失败甚至严重后果。为了解决这一问题，CaPo框架被提出，以增强基于LLM的具体化智能体之间的合作效率。

问题与挑战

在基于LLM的具体化智能体的合作中，面临的挑战包括：

  1. 缺乏长期战略和合作规划，导致动作执行不连贯。
  2. 在复杂任务中，如搜索和救援任务，缺乏充分的讨论和合作计划可能导致严重后果。
  3. 现有的强化学习方法在不同任务间的适应性有限，因为它们通常没有在大规模数据上训练，缺乏足够的泛化能力。

如何解决

CaPo框架通过以下方式解决上述挑战：

  1. 引入元计划生成阶段，通过多轮讨论创建长期战略和连贯的元计划。
  2. 在执行阶段，智能体根据最新进展动态调整元计划，确保元计划的有效性和效率。
  3. 通过多轮讨论和反馈，优化元计划，提高任务完成率和效率。

创新点

CaPo框架的创新点包括：

  1. 引入元计划生成和进度自适应元计划执行的概念，以提高多智能体合作的效率。
  2. 通过多轮讨论和反馈机制，使智能体能够共同创建和优化元计划。
  3. 实现了一个基于LLM的框架，利用其强大的推理和规划能力来指导智能体的合作。

算法模型

CaPo框架包含两个关键阶段：

  1. 元计划生成阶段：智能体分析任务，讨论并共同创建一个元计划，该计划将任务分解为子任务，并为每个子任务分配详细的步骤。
  2. 进度自适应元计划与执行阶段 ：智能体根据最新进展动态调整元计划，通过多轮讨论来优化任务执行。

实验效果

在ThreeDworld多智能体运输（TDW-MAT）任务和Communicative Watch-And-Help（C-WAH）任务上的实验结果表明，CaPo在任务完成率和效率方面显著优于现有技术。例如，在TDW-MAT任务中，CaPo在GPT-3.5和GPT-4基于智能体的情况下，分别超过了现有技术CoELA 16.7%和4.7%。

重要数据与结论

  • 在TDW-MAT任务中，CaPo在不同时间步长下的性能比较显示，CaPo在有限的时间或资源下，能够显著提高合作效率。
  • 在C-WAH任务中，CaPo通过清晰的工作和任务分配，避免了冗余步骤，提高了合作效率。

推荐阅读指数：★★★★☆

Authors: Zuzanna Osika, Jazmin Zatarain-Salazar, Frans A. Oliehoek, Pradeep K.

Murukannaiah

https://arxiv.org/abs/2411.04784

多目标强化学习中的政策摘要：为多目标决策导航

摘要

多目标强化学习（MORL）旨在同时优化多个目标，这在诸如水资源管理、自动驾驶、电力分配和无人机导航等多个领域都有应用。与传统的单目标强化学习不同，MORL需要在多个目标之间平衡权衡。MORL的一个显著优势是其输出不是单一策略，而是一组策略，每个策略都提供了关于目标的不同权衡。然而，解决方案集通常很大且多维，每个策略（例如，一个神经网络）都由其目标值表示。本文提出了一种对MORL生成的解决方案集进行聚类的方法，通过同时考虑策略行为和目标值，揭示策略行为与目标空间区域之间的关系。这种方法可以帮助决策者（DMs）识别解决方案集中的总体趋势和洞察，而不是单独检查每个策略。我们在四个多目标环境中测试了我们的方法，并发现它优于传统的k-中心点聚类。此外，我们还包括了一个案例研究，展示了它在现实世界中的应用。

研究背景

多目标强化学习（MORL）是强化学习的一个分支，它旨在同时优化多个目标，这些目标往往是相互冲突的。MORL在多个领域都有应用，包括水资源管理、自动驾驶、电力分配、无人机导航和医疗治疗等。与单目标强化学习不同，MORL需要在多个目标之间平衡权衡。MORL的输出不是单一策略，而是一组策略，每个策略都提供了关于目标的不同权衡。这种多样性不仅提供了可能行动及其后果的全面概述，还有助于更深入地理解目标如何相互作用和影响决策。然而，尽管MORL在增强决策的可解释性方面具有潜力，但其实际应用受到相关复杂性的阻碍。

问题与挑战

MORL面临的挑战包括：

  1. 解决方案集通常很大且多维，难以理解和评估。
  2. 决策者需要在没有明确偏好的情况下导航和评估解决方案集中的选项。
  3. 随着目标数量的增加，解决方案集的大小急剧增加，使得理解整个解决方案集变得不切实际。

如何解决

为了解决这些挑战，本文提出了一种方法，通过聚类来解释MORL解决方案集，同时考虑目标和行为空间。具体来说：

  1. 使用来自可解释强化学习（XRL）领域的技术来有效地表示策略的行为空间。
  2. 应用Pareto-Set Analysis（PAN）聚类算法，在两个空间中找到定义良好的聚类。
  3. 在四个不同的MORL环境中应用这种方法，并与传统的k-中心点聚类进行比较。

创新点

本文的创新点包括：

  1. 提出了一种新的方法，通过聚类来解释MORL解决方案集，同时考虑目标和行为空间。
  2. 使用Highlights算法来表示策略的行为空间，这是一种从XRL领域借鉴的技术。
  3. 应用PAN聚类算法，这是一种在决策和目标空间中识别紧凑且分隔良好的聚类的方法。

算法模型

本文提出的算法模型包括：

  1. Highlights算法：用于创建策略行为的视频摘要，通过在线模拟计算策略遇到的最重要状态。
  2. PAN聚类算法：一种双目标聚类算法，用于在目标和行为空间中生成一组有效的分区。

实验效果

在四个多目标环境中进行的实验结果表明，PAN聚类算法在两个空间中都优于传统的k-中心点聚类。特别是在MO-Highway环境中，通过案例研究展示了考虑不仅仅是权衡（预期回报），还有策略行为在向DMs呈现信息时的重要性。

重要数据与结论

  • 在MO-Highway环境中，PAN聚类算法提供了多个聚类选项，每个聚类都代表了不同的权衡。
  • 通过比较PAN聚类与传统的k-中心点聚类，发现PAN聚类在多个环境中表现更好或相当。
  • 通过分析Highlights算法生成的视频，观察到不同的策略行为，这些行为仅从目标空间的权衡中是不明显的。

推荐阅读指数：★★★★☆

4. GUI Agents with Foundation Models: A Comprehensive Survey

Authors: Shuai Wang, Weiwen Liu, Jingxuan Chen, Weinan Gan, Xingshan Zeng,

Shuai Yu, Xinlong Hao, Kun Shao, Yasheng Wang, Ruiming Tang

https://arxiv.org/abs/2411.04890

基于基础模型的GUI代理：一项全面调查

摘要

本文综述了基于（多模态）大型语言模型（LLM/MLLM）的图形用户界面（GUI）代理的最新研究进展。这些代理能够处理和解释GUI，通过模拟人类交互（如点击和输入）来自动执行用户指令。文章首先讨论了代表性的数据集和基准测试，接着总结了一个包含关键组件和分类的统一框架，最后探讨了（M）LLM基础GUI代理的商业应用。文章还识别了该领域的关键挑战，并提出了未来研究方向。

研究背景

GUI作为人与数字设备之间的主要交互点，对于用户体验至关重要。尽管已有大量关于GUI代理的研究，但传统基于规则和强化学习方法在处理类人交互任务时存在局限。近年来，LLM和MLLM的发展提高了语言理解和认知处理能力，使得基于（M）LLM的代理能够有效解释和利用人类语言，制定详细计划并执行复杂任务，为自动化GUI任务提供了新机会。

问题与挑战

  1. 数据集和基准测试的局限性：现有的数据集和基准测试多为静态，不足以应对实际应用中（M）LLM基础GUI代理对环境状态的广泛解释需求。
  2. GUI代理的自我演化：实现GUI代理的自我闭环是一个挑战，需要有效的探索方法来实现。
  3. 推理效率：用户对GUI的响应时间敏感，当前GUI代理的推理和通信延迟通常以秒计，导致用户体验差。

如何解决

文章提出了以下解决方案：

  1. 开发数据集和基准测试：为了训练和评估（M）LLM基础GUI代理的能力，研究者开发了静态和动态数据集。
  2. 设计GUI代理框架：提出了一个系统性的GUI代理框架，包括GUI感知器、任务规划器、决策制定者、记忆检索器和执行器。
  3. 优化推理效率：通过在移动设备上直接部署（M）LLM来减少延迟，提高用户体验。

创新点

  1. 统一框架：提出了一个包含五个关键组件的GUI代理框架，为研究者提供了一个清晰的结构来设计和实现GUI代理。
  2. 多模态输入：利用MLLM的多模态能力，提高了GUI理解和任务执行能力。
  3. 自我演化：引入了自我演化的概念，通过自动记录操作和界面转换知识，实现GUI代理的自我闭环。

算法模型

文章中提到的算法模型包括：

  1. 基于提示的GUI代理：使用提示来构建GUI代理，采用CoT或ReAct风格。
  2. 基于微调的GUI代理：通过微调使LLM适应特定领域，更有效地执行定制任务。

实验效果

文章中没有提供具体的实验数据和结果，但提到了多个数据集和基准测试，如Android in the Wild、Android-In-The-Zoo、AndroidControl等，这些数据集用于评估和训练基于（M）LLM的GUI代理。

重要数据与结论

文章总结了基于（M）LLM的GUI代理的关键技术和应用，强调了数据集、框架和应用的重要性，并指出了该领域的挑战和未来方向。

推荐阅读指数：★★★★☆

5. Position Paper On Diagnostic Uncertainty Estimation from Large Language Models: Next-Word Probability Is Not Pre-test Probability

Authors: Yanjun Gao, Skatje Myers, Shan Chen, Dmitriy Dligach, Timothy A

Miller, Danielle Bitterman, Guanhua Chen, Anoop Mayampurath, Matthew Churpek,

Majid Afshar

https://arxiv.org/abs/2411.04962

大型语言模型在诊断不确定性估计中的位置论文：下一个词概率并非前测试概率

摘要

本文探讨了大型语言模型（LLMs）在临床决策支持中的潜力，特别是在估计前测试概率方面。尽管LLMs在生成鉴别诊断方面表现出与临床医生相媲美的能力，但它们在明确传达诊断概率的不确定性方面存在局限。本研究评估了两个LLMs------Mistral-7B和Llama3-70B，使用结构化的电子健康记录数据进行三项诊断任务。我们检验了三种当前从LLMs中提取概率估计的方法，并揭示了它们的局限性。我们的目标是强调需要改进LLMs置信度估计技术。

研究背景

医学诊断是一个复杂的过程，涉及基于患者表现估计各种疾病的可能性。这个过程需要整合基线信息以建立前测试概率，然后随着诊断测试结果的获得进行迭代细化。尽管临床医生依赖于医学知识、模式识别和经验来快速生成初步诊断假设，但这个过程容易受到认知偏差的影响，导致诊断错误。LLMs的集成在解决这些挑战方面引起了极大的兴趣。然而，LLMs通常未能在其输出中明确传达诊断概率的不确定性，这对于医学至关重要。

问题与挑战

LLMs在医学诊断决策支持系统中的集成面临着以下挑战：

  1. LLMs未能明确传达诊断概率的不确定性。
  2. LLMs不是设计为输出特定结果的概率分布的分类器，而是产生令牌序列的概率分布。
  3. 如何将这些令牌序列映射到临床有意义的概率，特别是在前测试或后测试诊断概率估计方面。

如何解决

本研究通过以下方式解决上述挑战：

  1. 评估两个开源的LLMs在预测前测试诊断概率任务上的表现。
  2. 使用结构化的电子健康记录数据，包括生命体征、实验室测试结果、护士流动表评估和患者人口统计数据。
  3. 比较结果与使用原始结构化EHR数据作为输入的eXtreme Gradient Boosting（XGB）分类器的结果。

创新点

  1. 提出了一种新的方法来评估LLMs在前测试诊断概率估计中的优势和局限性。
  2. 使用结构化的EHR数据，而不是仅依赖于自然语言文本，以提高预测的准确性和可靠性。
  3. 探索了将LLMs的令牌序列输出映射到临床有意义的概率的方法。

算法模型

本研究中使用的算法模型包括：

  1. Token Logits：直接从LLMs的响应中提取概率估计。
  2. Verbalized Confidence：LLMs以自然语言格式生成和口头化概率评估。
  3. Feature-based Calibrators：将LLMs的嵌入表示输入到XGB分类器中。

实验效果

实验结果表明：

  • LLM Embedding+XGB方法在特定条件下（如Sepsis）与XGB基线分类器表现相当，并且在所有测试方法中显示出最强的相关性。
  • Token Logits和Verbalized Confidence方法在风险估计方面不可靠，特别是在诊断低患病率疾病时，这些模型的AUROC分数、皮尔逊相关性和校准曲线表现显著下降。
  • 引入人口统计变量（性别、种族、民族）会改变AUROC分数，但这些变化的方向和一致性因具体情境和数据而异。


重要数据与结论

  • AUROC分数：LLM Embedding+XGB方法在Sepsis预测中几乎达到了与Raw Data+XGB相同的AUROC分数。
  • 皮尔逊相关系数：Token Logits和Verbalized Confidence方法与基线XGB预测概率的相关性变化较大，通常没有相关性或负相关性。
  • 校准曲线：Token Logits和Verbalized Confidence显示出较差的校准，尤其是Verbalized Confidence在CHF预测任务中表现出更高的ECE值，表明校准较差。

推荐阅读指数：★★★★☆

后记

如果您对我的博客内容感兴趣，欢迎三连击 (***点赞、收藏和关注 ***）和留下您的评论，我将持续为您带来计算机人工智能前沿技术(尤其是AI相关的大语言模型，深度学习和计算机视觉相关方向)最新学术论文及工程实践方面的内容分享，助力您更快更准更系统地了解 AI前沿技术。

相关推荐
shinelord明4 分钟前
【再谈设计模式】抽象工厂模式~对象创建的统筹者
数据结构·算法·设计模式·软件工程·抽象工厂模式
边缘计算社区10 分钟前
奥迪：在工业边缘使用 VMware 边缘计算堆栈
人工智能·边缘计算
说私域17 分钟前
基于社交关系的电商平台发展与创新：以微店买家版为例兼论开源 AI 智能名片 2 + 1 链动模式 S2B2C 商城小程序
人工智能·小程序
啊文师兄28 分钟前
使用 Pytorch 搭建视频车流量检测资源(基于YOLO)
人工智能·pytorch·yolo
使者大牙39 分钟前
【LLM学习笔记】第三篇：模型微调及LoRA介绍（附PyTorch实例）
人工智能·pytorch·python·深度学习
scdifsn43 分钟前
动手学深度学习10.1. 注意力提示-笔记&练习（PyTorch）
pytorch·笔记·深度学习·注意力机制·注意力提示
Elastic 中国社区官方博客1 小时前
Elasticsearch 和 Kibana 8.16：Kibana 获得上下文和 BBQ 速度并节省开支！
大数据·数据库·人工智能·elasticsearch·搜索引擎·ai·全文检索
陌上阳光1 小时前
动手学深度学习69 BERT预训练
人工智能·深度学习·bert
车载诊断技术1 小时前
电子电气架构--- 实施基于以太网的安全车载网络
网络·人工智能·安全·架构·汽车·电子电器架构
言之。1 小时前
【K-Means】
算法·机器学习·kmeans
热门推荐
01软件工程从理论到实践客观题汇总(头歌第一章至第八章)02【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总03组基轨迹建模 GBTM的介绍与实现（Stata 或 R）04VSCode插件 —— Cody AI （免费AI助手！）05全面解析：构建基于深度学习的安全帽检测系统（UI界面+YOLO代码+数据集）06Windows10安装PCL1.14.0及点云配准07Ubuntu 20.04使用Livox mid 360 测试 FAST_LIO08文件或文件夹名称中有空格如何批量去除09基于YOLOv10深度学习的CT扫描图像肾结石智能检测系统【python源码+Pyqt5界面+数据集+训练代码】深度学习实战、目标检测10【QuikGraph】C#调用第三方库实现迪杰斯特拉(Dijkstra)算法功能