gpt4 book ai didi

simulation - 如何为基于代理的模型实现基于规则的决策者?

转载 作者:行者123 更新时间:2023-12-04 07:22:37 24 4
gpt4 key购买 nike

我很难理解如何在我尝试开发的基于代理的模型中为代理结合基于规则的决策方法。
代理的界面非常简单。

public interface IAgent
{
public string ID { get; }

public Action Percept(IPercept percept);
}
为了举例,让我们假设代理代表车辆,它们在大型仓库内穿越道路,以便装卸 cargo 。他们的路线(道路序列,从起点到代理的目的地)由另一个代理(主管)指定。车辆代理的目标是遍历其指定的路线,卸载 cargo ,装载新的 cargo ,接收主管指定的另一条路线并重复该过程。
车辆还必须意识到潜在的碰撞,例如在交叉点,并根据某些规则给予优先权(例如,装载最重 cargo 的车辆具有优先权)。
据我了解,这是我要构建的代理的内部结构:
enter image description here
所以车辆代理可以是这样的:
public class Vehicle : IAgent
{
public VehicleStateUpdater { get; set; }

public RuleSet RuleSet { get; set; }

public VehicleState State { get; set; }

public Action Percept(IPercept percept)
{
VehicleStateUpdater.UpdateState(VehicleState, percept);
Rule validRule = RuleSet.Match(VehicleState);
VehicleStateUpdater.UpdateState(VehicleState, validRule);
Action nextAction = validRule.GetAction();
return nextAction;
}
}
对于 Vehicle 代理的内部状态,我正在考虑以下内容:
public class VehicleState
{
public Route Route { get; set; }

public Cargo Cargo { get; set; }

public Location CurrentLocation { get; set; }
}
对于此示例,必须为 Vehicle Agent 实现 3 条规则。
  • 如果另一辆车靠近代理(例如小于 50 米),则 cargo 最重的车辆优先,其他代理必须保持其位置。
  • 当代理到达目的地时,他们卸载 cargo ,装载新 cargo 并等待主管分配新路线。
  • 在任何给定时刻,无论出于何种原因,主管都可能发送命令,接收车辆必须遵守该命令(保持位置或继续)。

  • VehicleStateUpdater 必须考虑代理的当前状态、接收到的感知类型并相应地更改状态。因此,为了让状态反射(reflect),例如Supervisor收到一条命令,可以修改如下:
    public class VehicleState
    {
    public Route Route { get; set; }

    public Cargo Cargo { get; set; }

    public Location CurrentLocation { get; set; }

    // Additional Property
    public RadioCommand ActiveCommand { get; set; }
    }
    其中 RadioCommand 可以是具有 None、Hold、Continue 值的枚举。
    但是现在,如果另一辆车正在接近,我还必须在代理状态中进行注册。所以我必须向 VehicleState 添加另一个属性。
    public class VehicleState
    {
    public Route Route { get; set; }

    public Cargo Cargo { get; set; }

    public Location CurrentLocation { get; set; }

    public RadioCommand ActiveCommand { get; set; }

    // Additional properties
    public bool IsAnotherVehicleApproaching { get; set; }

    public Location ApproachingVehicleLocation { get; set; }
    }
    这是我在理解如何进行时遇到巨大麻烦的地方,我觉得我没有真正遵循正确的方法。首先,我不确定如何使 VehicleState 类更加模块化和可扩展。其次,我不确定如何实现定义决策过程的基于规则的部分。我是否应该创建互斥规则(这意味着每个可能的状态必须对应不超过一个规则)?是否有一种设计方法可以让我添加额外的规则,而不必在 VehicleState 类中来回添加/修改属性,以确保代理的内部状态可以处理每种可能的 Percept 类型?
    我已经看过《人工智能:现代方法》课本和其他来源中演示的示例,但是当必须设计更复杂的模型时,可用示例太简单了,我无法“掌握”所讨论的概念。
    如果有人能指出我关于基于规则部分的实现的正确方向,我将不胜感激。
    我正在用 C# 编写,但据我所知,它与我试图解决的更广泛的问题并不真正相关。
    更新:
    我试图合并的规则示例:
    public class HoldPositionCommandRule : IAgentRule<VehicleState>
    {
    public int Priority { get; } = 0;

    public bool ConcludesTurn { get; } = false;


    public void Fire(IAgent agent, VehicleState state, IActionScheduler actionScheduler)
    {
    state.Navigator.IsMoving = false;
    //Use action scheduler to schedule subsequent actions...
    }

    public bool IsValid(VehicleState state)
    {
    bool isValid = state.RadioCommandHandler.HasBeenOrderedToHoldPosition;
    return isValid;
    }
    }
    我也尝试实现的代理决策者示例。
    public void Execute(IAgentMessage message,
    IActionScheduler actionScheduler)
    {
    _agentStateUpdater.Update(_state, message);
    Option<IAgentRule<TState>> validRule = _ruleMatcher.Match(_state);
    validRule.MatchSome(rule => rule.Fire(this, _state, actionScheduler));
    }

    最佳答案

    我认为您的问题包含两个主要子问题:

  • 建模灵活性,尤其是如何更轻松地向系统添加属性和规则。
  • 如何提出正确的规则集以及如何组织它们以使代理正常工作。

  • 所以让我们去看看他们每个人。
    建模灵活性
    我认为你现在拥有的还不错,实际上。让我解释一下原因。
    您表达了对“一种设计方法的担忧,它允许我添加额外的规则,而不必来回切换 VehicleState 类并添加/修改属性”。
    我认为答案是否定的,除非你遵循完全不同的路径让代理自主学习规则和属性(如 Deep Reinforcement Learning ),这有其自身的一系列困难。
    如果您要按照问题中的描述手动编码代理知识,那么您将如何避免在添加新规则时引入新属性?您当然可以尝试预测您将需要的所有属性,不允许自己编写需要新属性的规则,但新规则的本质是带来问题的新方面,这通常需要新属性。这与软件工程不同,软件工程需要多次迭代和更改。
    基于规则的建模
    有两种编写规则的方式:命令式和声明式。
  • 在命令式风格中,您编写执行操作所需的条件。当两者都适用时,您还必须注意选择一个操作而不是另一个操作(可能具有优先级系统)。因此,您可以制定一条沿路线行驶的规则,以及另一条在优先级更高的车辆接近时停止的规则。这似乎是您目前正在采用的方法。
  • 在声明式风格中,您声明您的环境规则是什么、操作如何影响环境以及您关心什么(将实用程序分配给特定状态或子状态),并让系统处理所有这些以计算最佳操作你。所以在这里你声明做出移动的决定如何影响你的位置,你声明碰撞是如何发生的,你声明到达你的路线终点是好的,而碰撞是坏的。请注意,在这里您没有做出决定的规则;系统使用规则来确定给定特定情况下具有最大值(value)的 Action 。

  • 理解命令式和声明式风格之间区别的一种直观方法是考虑编写一个下棋的代理。在命令式风格中,程序员编码了国际象棋的规则,还有如何下棋、如何打开游戏、如何选择最佳 Action 等等。也就是说,系统会体现出程序员的棋艺水平。在声明式风格中,程序员只是对国际象棋规则进行编码,以及系统如何自动探索这些规则并确定最佳棋步。在这种情况下,程序员不需要知道如何下棋,程序就可以真正下棋。
    命令式风格更易于实现,但灵活性较差,并且随着系统复杂性的增加会变得非常困惑。您必须开始考虑各种场景,例如当三辆车相遇时该怎么办。在国际象棋的例子中,想象一下如果我们稍微改变国际象棋规则;整个系统需要审核!在某种程度上,命令式系统中几乎没有“人工智能”和“推理”,因为是程序员提前进行了所有推理,提出了所有解决方案并对其进行了编码。它只是一个常规程序,而不是人工智能程序。这似乎就是你所说的那种困难。
    声明式风格更加优雅和可扩展。您不需要弄清楚如何确定最佳操作;系统会为您完成。在国际象棋示例中,您可以轻松地更改代码中的一种国际象棋规则,系统将使用新规则在更改后的游戏中找到最佳走法。但是,它需要一个推理引擎,该软件知道如何接受大量规则和实用程序并决定哪个是最佳操作。这样的推理引擎就是系统中的“人工智能”。它会自动考虑所有可能的场景(不一定是一个一个,因为它通常会采用更智能的技术来考虑场景类别)并确定每个场景中的最佳操作。但是,推理引擎实现起来很复杂,或者,如果您使用现有的推理引擎,它可能非常有限,因为这些通常是研究包。我相信,当涉及到使用声明式方法的实际实际应用程序时,人们几乎会为他们的特定需求编写一个定制的系统。
    我在这些方面找到了几个研究开源项目(见下文);这将使您了解可用的内容。如您所见,这些都是研究项目,范围相对有限。
    说了这么多,接下来怎么办?我不知道你的具体目标是什么。如果你正在开发一个玩具问题来练习,你当前的命令式风格系统可能就足够了。如果你想了解声明式风格,深入阅读 AIMA 教科书会很好。作者维护了一个 open source repository with implementations for some of the algorithms in the book , 也。
    https://www.jmlr.org/papers/v18/17-156.html
    https://github.com/douthwja01/OpenMAS
    https://smartgrid.ieee.org/newsletters/may-2021/multi-agent-opendss-an-open-source-and-scalable-distribution-grid-platform

    关于simulation - 如何为基于代理的模型实现基于规则的决策者?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/68403907/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com