"会说不会做"的大模型

LLM虽然能力非常强大，但其应用不应局限在语言或者对话，但是如果需要做更深入细节的相关相关的AI应用除了对
MCP全称是 Model Context Protocol，是Anthropic在2024年11月25日提出的一个开源协议标准，用来解决大预言模型处理外部资源以及工具的的问题。即使是目前最先进的LLM，仍受到很多限制，很多数据需要来源于外部工具来实现共享和调用。

Function Calling

关于外部工具调用，最早的是OpenAI的在gpt-4中引入的Function Calling 功能，该功能通过定义工具的名称、功能、参数、描述等信息，将工具库提供给大模型，大模型会根据业务需求自主判断是否需要以及调用工具库中的工具。下面是一个简单的tools定义和fucntion calling的示例：

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_current_weather",
            "description": "Get the current weather in a given location",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "The city and state, e.g. San Francisco, CA",
                    },
                    "unit": {
                        "type": "string", 
                        "enum": ["celsius", "fahrenheit"]},
                },
                "required": ["location"],
            },
        },   
    }
]

调用使用openai的标准库

def get_completion(messages, model="gpt-3.5-turbo-1106", temperature=0, max_tokens=300, tools=None):
    response = openai.chat.completions.create(
        model=model,
        messages=messages,
        temperature=temperature,
        max_tokens=max_tokens,
        tools=tools
    )
    return response.choices[0].message

但是最初版的Function Calling 功能存在以下问题：
+ 没有统一的行业标准，每个厂商LLM提供的JSON结构和实现方式都不同
+ 需要开发者为每个模型编写特定的适配代码
+ 不负责执行，无法提供函数管理，通常只生成指令，需要开发者手动完成调用
这导致实际AI应用中集成Function calling开发量过大。因此MCP应运而生。

MCP协议

MCP定义了应用程序和大模型之间信息交换的方式，让开发者可以用一致的方式吧数据源、工具和功能连接到大模型中，类似USB-C可以让不同的设备进行连接一样。

类别	MCP（Model Context Protocol）	Function Calling
性质	协议	功能
范围	通用（多数据源、多功能）	特定场景（单一数据源或功能）
目标	统一接口，实现互操作	扩展模型能力
实现	基于标准协议	依赖于特定模型实现
开发复杂度	低：通过统一协议实现多源兼容	高：需要为每个任务单独开发函数
复用性	高：一次开发，可多场景使用	低：函数通常为特定任务设计
灵活性	高：支持动态适配和扩展	低：功能扩展需要额外开发

总的来说MCP和Function Calling一样，都是为了实现大模型和外部资源的集成，解决LLM只能说不能做的问题。

使用Cline和MCP Inspector 构建能源系统优化MCP Server

构建能源系统优化程序

要使用MCP协议封装一个能源系统优化程序，首先要将能源系统优化问题的代码和资源封装成函数，然后将函数注册到MCP服务器上，最后通过MCP客户端调用函数。

def opt(ramp_up,pv_osi) -> tuple:
    """_summary_

    Args:
        ramp_up (float): fuel cell ramp up rate
        pv_osi (int): pv oscillation index 

    Returns:
        tuple: device capacity, operation results
    """
    # optuimize
    return device_cap, res

device_cap,res = opt(1/6,0)

这里不展开优化函数内部的逻辑，总的来说是根据输入的爬坡速率参数和光伏波动指数计算出设备容量和运行结果。

注册和构建MCP Server

这里使用mcp库构建stdio的mcp server，注册工具函数，然后启动server。具体脚本如下

from mcp.server.fastmcp import FastMCP
from model_idc.model import opt
# Create an MCP server
mcp = FastMCP("Demo")


# Add an addition tool
@mcp.tool()
def copt_opt(dict_in) -> int:
    """计算一组规划问题，考虑不同的燃料电池爬坡速度

    Args:
        ramp_rate (float): 燃料电池爬坡时间，通常为0.3,0.8,0.1等
        pv_osi (int): in [0,1,2],描述波动程度，通产给0即可

    Returns:
        device_cap: 设备规划容量
    """
    device_cap,_ = opt(float(dict_in["ramp_rate"]),int(dict_in['pv_osi']))
    print(device_cap)

if __name__ == "__main__":
    mcp.run(transport="stdio")

值得注意的是这里mcp虽然使用修饰器@mcp.tool()来注册，但是实际上函数的输出应当是print的io形式返回，return是无法给出具具体内容的。

使用MCP Inspector 调用MCP Server

MCP Inspector是一个基于MCP协议的客户端，用于调用MCP服务器上的函数。它提供了一个图形化的界面，让用户可以方便地调用MCP服务器上的函数。

具体安装方法可以参考MCP Inspector

这里使用以下命令启动inspector

npx @modelcontextprotocol/inspector

启动后默认端口在6274，在左侧创建新的mcp server，这里使用命令行创建。在创建的时候一定要注意路径的选择，包括server的路径和python的路径。

PATH_PYTHON\\python.exe PATH_SERVER\\mcp_server.py

启动后的界面上可以connect到server，然后可以调用工具函数。

点击tools中枚举以下识别的，随后设置好测试的输入即可调试输出。这里我们的输出是一组设备的规划容量。

使用Cline集成大模型并调用MCP Server

为了方便使用，使用vscode的cline插件，这里需要使用以下json注册一个mcp server。

{
"mcpServers": {
    "copt": {
    "disabled": false,
    "timeout": 60000,
    "command": "PAHT_TO_PYTHON\\python.exe",
    "args": [
        "PAHT_TO_SERVER\\optMCP\\server.py"
    ],
    "transportType": "stdio"
    }
}
}

随后使用cline进行测试，如果有绿点和info而没有error则说明成功

最后可以每次直接与大模型对话，大模型会自动识别并申请调用。因为MCP消耗的token较大，所以每次需要给用户申请。

MOE 基本原理

MOE由两个主要的部件构成：第一个是专家expert，每个专家代表一个就诊网络；第二个是路由router，门控网络，通过开关将输入的token路由到不同的专家。
MOE结构里面每一层都有很多专家和路由，每一层的专家和路由数量都可以调整。

回顾transformer架构，每个输入都是一个token，每个token输入到position embedding，然后通过多层decoder堆叠，最后输出token。

其中每个decoder内部如下所示：

首先需要数据归一化，随后进入多头注意力机制，然后进入残差连接，最后进入稠密的前馈神经网络。
MOE就是把稠密的前馈神经网络变成了稀疏的前馈神经网络，通过门控网络来选择哪些专家来处理输入的token。

每次通过路由选择下一层经过哪一个专家

MOE的核心是把FFNN替换成多个系数的FFN，每一个FFN都是一个专家。

路由原理

路由是用来选择专家的，由FFNN和softmax组成，如下图所示。

softmax会输出每一个专家的概率，最后用一个或多个专家来权和输入的token。

稀疏架构和稠密架构

Transformer是一个稠密的架构，每个输入都需要经过所有的专家。MOE是一个分为稠密MOE和稀疏MOE的架构。

稠密MOE是每个输入都需要经过所有的专家。稀疏MOE是每个输入只需要经过一部分的专家。输出时候只激活部分专家
MOE的一般输入是具体的矩阵，包括包括(b,s,h)，其中b是batch size，s是sequence length，h是hidden size。
输入首先经过FFN路由层，输出到H(x)层在经过softmax，计算得到专家的概率分布。随后通过门控网络选择一部分专家来处理输入的token。

负载均衡 load balancing

在deepseek里面专家为256个，在训练时候每个专家的训练速度不一样，pathway会跟倾向于选择算的快的专家，导致算的快的专家学的多，算的慢的专家学的较少，因此引入load balance让每个专家的训练速度一样。

• Keep Top-k
  这里通过 keep Top-k 策略来实现。引入噪声矩阵，来抑制某个专家选择过多时候的得分。
  
  通过在每一层的时候引入噪声矩阵，实现整个网络的负载均衡。

• 辅助损失
  为了进一步提升负载均衡能力，引入auxiliary loss。通过将每个token的专家选择分布求和，来计算每个专家的平均选择次数，然后计算每个专家的平均选择次数和平均选择次数的差值，计算辅助损失，并将其加入到总的损失函数中。

• 专家容量
  专家容量同样是为了解决训练负载均衡问题。
  每个专家在输进去token之前加入每个专家最大出力的token数量，通过增加容量来提升训练稳定性，让专家之间训练更加寻哼

ORLM

大模型带来的技术革命下，优化的行业壁垒还能撑多久？

虽然目前优化技术受限于其高度定制化的建模和强非线性导致的计算复杂度，短时间内大模型难以实现端到端的建模和求解，从而无法取代优化算法。但目前由两方面我认为是当前优化领域需要提前预判的技术风险：

1.推理大模型+行业知识库的跨领域优化建模方法

系统工程作为自动化的一个二级学科，核心竞争力就在于学科融合，换句话说就是比领域的人更懂优化，比优化的人更懂业务，这一部分融合的能力是很容易被大模型的海量知识库所取代的。目前现有的推理大模型加上行业知识库和案例库，建立的优化模型可以完全媲美人工优化模型（参考我们做的EnergyLLM能源领域垂直大模型），后续靠行业信息差吃饭的系统工程又能有多少生命力呢。

2.GPU算力+并行启发式的暴力优化求解算法

我们再用求解器求解大规模MIP的时候通常可以注意到，第一个可行解的日志的左边通常是H而不是*。这意味着现有的gurobi、COPT甚至SCIP等求解器的初始可行解大部分是从启发式方法得到的，但启发式面临参数问题，不同的参数通常计算的效率差距非常大而且不具备梯度特性无法精准调参。然而随着GPU算力不算增强，显卡最擅长的就是并行计算，现在英伟达推出的cuOPT正是使用多种群并行的启发式大力出奇迹。大规模组合优化问题在未来只能说很难保证不被取代，后续研究优化算法那么多甚至可能还不如几张显卡用启发式暴力求解了。

research gap

现有的优化领域大模型存在以下缺陷：

1. 建模能力有限：现有的大模型通常在逻辑约束和非线性约束方面有限，无法应对复杂的优化问题。
2. 优化模型额训练数据的质量不足：数据的范围和质量与模型的能力密切相关，但目前优化领域缺少高质量建模数据，限制了大模型的高级建模能力。
3. 数据隐私考虑：基于API成都闭源大模型可能导致数据泄露，尤其是在一些工业应用领域。
4. 测试集相对同质：目前已有的数据集市2023年的NL4OPT比赛，但是这个数据集只关注简单的线性规划部分，复杂度较低，规模较小，很难与实际中的场景类比。

主要内容

为了解决上述问题，ORLM提出了一个生成优化建模数据的半自动框架，可以增强大模型的建模能力：

1. OR-Instruct数据生成框架 ：
   提出了数据集应当满足的四个准则，基于这些准则设计了OR-Instruct框架，该框架可以自动生成优化模型的训练数据。该框架使用迭代增强框架如下图所示。
   首先手机686个实际工业场景，并把他们放置到训练data pool。根据这些数据使用扩展（expansion）和增强（Augmentation）两种技术生成更多场景的建模问题。最后使用启发式框架来筛选明显的低质量数据，往复循环直至训练数据集达到预期数量。
   
2. 性能测试：为了验证OR-Instruct的性能，提出了Industry Benchmark。该benchmark使用13个不同工业场景，包括5中问题方式和3中难度。
3. 使用OR-Instruct产生的数据对开源大模型7B级别的模型进行了微调，并把这些模型训练成了 operation research language model（ORLM）。

OR-Instruct

优化大模型数据集的四个准则：

1. Comprehensive Coverage：数据集应该覆盖优化领域的所有问题，包括供应链、仓库、物流等等行业；不同的问题类型应当满足，包括LP、MIP、QP、NLP、RMP等；不同的问题难度应当满足，包括简单、中等、困难。

• 初始化数据集：使用686个实际工业场景作为初始数据集。
• 扩展数据集:首先使用 GPT-4生成100个优化模型的实际应用场景。每次迭代使用data pool中的三个案例作为in-context prompt。每一轮迭代中使用两个real-world scenarios和一个data pool的案例。
• 增强数据集：增强策略主要是为了提升算法求解的多样性，包括：
  • 目标函数和约束条件的变换：增加、删除、替换目标函数和约束。
  • 重新描述问题：第二种增强方法为了提升LLM应对不同prompt的鲁棒性，将同一个优化问题的不同描述形式。
  • 融合多重建模技巧：结合包括大M法，辅助变量、等多种建模技巧。
• 后处理和筛选：纠正和过滤生成的低质量数据。使用一个正则匹配函数来发现语法错误，最后需要消除重复的问题。

Results

结论部分不在多余描述，主要对比了以下几个层面

1. Data generation quality。
2. Model Finetuning and Inference。主要是一些hyper parameters参数
3. Evaluation and Baselines。
   • Evaluation Benchmarks: NL4OPT MAMO两个数据集，
   • Baselines：
     • GPT-4
     • GPT-3.5
     • GPT-3
       对比不同数据集和不同模型的准确率
4. 定制化增强: 针对MILP问题构建定50个基础问题，并将其加入seed data pool。在几轮迭代后生成了2000个训练问题。这两千个数据可以极大的提升ORLM在MILP上的表现。

更细节的对比包括不同难度数据上不同模型的表现，不同增强方法的表现对比，以及消融实验。最后展示了一些推理参数的设置对结果的影响。

Future Direction

潜在的应用场景

1. 提升优化方法在工业领域的地位：
   大模型可以避免很多优化方法现有的问题，比如：
   • 优化模型在实际场景中不够robust，无法应对额外的约束条件，当环境更换时候模型无法迅速适应。
   • 优化项目极度依赖专家来定制化目标函数和约束条件。对于某些定制化场景，优化专家与业务的沟通变得非常困难。
2. 运筹学教学
3. 数学建模竞赛
4. 减少求解器的学习成本

未来的研究热点

1. 结合RLHF来提升模型的泛化能力
2. 数据集结构重构：数据合成策略对于像 RLHF 这样的强化学习技术来说是不够的，RLHF 需要以偏好列表形式的训练数据。对于每个问题，必须根据偏好对多个响应进行排序。此外，在优化问题的背景下，将实际的最优解纳入训练集将使更多的技术成为可能。构建这样的数据集可能需要用户的反馈或开发新的数据合成方法，以更好地满足这些需求。
3. 数据精炼和利用：权衡训练开销和模型效果的工作。如果获得一种数据精炼策略，可以用少量的训练开销获得更好的模型效果，这将是一个非常有价值的研究方向。

使用litstudy进行文献自动分析

采集式学习？

由于某学院中期报告的要求，采集式学习不得不进入同学们的生活，报告要求、ppt要求、评分准则都与采集式学习的质量有关：

（4）结合项目实践和研究需要，是否开展了采集式的学习，对实践和研究是否提供了有效的支撑；

文献批量自动分析

某些综述类论文为了提升调研论文的说服力，经常会展示文献调研的算法，在github上调研也发现了一些好用的自动文献整理和文献分析工具，比如Litstudy。该仓库基于python开发，主要有五个特性：

• 从不同来源的科学文件中提取元数据。组合来自不同来源的数据，以标准化的接口呈现数据。
• 过滤、选择、删除重复数据和注释文档集合。
• 计算和绘制文档集的通用统计信息，例如关于作者、地点和出版年份的统计信息。
• 生成和绘制各种书目网络作为交互式可视化。
• 使用自然语言处理的主题发现允许自动发现热门主题。

该仓库具体支持的文献来源如下表所示

Name	Title	Authors	Venue	Abstract	Citations	References
Scopus	✓	✓	✓	✓	✓	✓
SemanticScholar	✓	✓	✓	✓	* (count only)	✓
CrossRef	✓	✓	✓	✓	* (count only)	✓
DBLP	✓	✓	✓
arXiv	✓	✓		✓
IEEE Xplore	✓	✓	✓	✓	* (count only)
Springer Link	✓	✓	✓	✓	* (count only)
CSV file	✓	✓	✓	✓
bibtex file	✓	✓	✓	✓
RIS file	✓	✓	✓	✓

同时仓库也提供了一个Jupyter应用案例。

该仓库的可视化结果非常适合我们文献调研汇报工作和PPT汇报中绘图，安装方便上手简单，希望能帮助到有开题汇报或者中期汇报需求的同学。

参考

[1] Heldens, S., Sclocco, A., & Dreuning, H. litstudy [Computer software]. https://doi.org/10.5281/zenodo.3386071