实习笔记01：从 MCP、RAG 到风机散点图

今天学的东西主要分成两个板块：一个是 AI，另一个是风电。

这两个方向没什么直接关系，只是刚好都安排在了今天。与其硬找一个共同主题，不如分开记录，各讲各的。以后回头复习时，也能更快找到自己当时学到了什么、哪些地方理解错了，以及还有哪些问题没有弄明白。

AI 学习：MCP 与 RAG

今天在 AI 这边主要学习了 MCP 和 RAG 的流程。

原本还打算继续看 Hugging Face 的教程，但公司新电脑的网络环境暂时没有配置好，只能再等几天。那就先不赶进度了，正好把今天学到的内容捋一遍。很多概念看资料时觉得自己懂了，真正尝试用自己的话写出来，才会发现有些地方其实只是“听起来熟”。

MCP 到底是什么？

MCP 的全称是 Model Context Protocol（模型上下文协议）。

刚接触时，我觉得它虽然叫“协议”，但用起来更像一套完整的流程。这个感觉不算完全错，因为从连接到调用，确实有一整套协作过程。不过严格来说，MCP 首先是一套开放协议，它规定了 AI 应用与外部服务怎样建立连接、发现能力、传递参数和返回结果。

可以把它理解成 AI 应用和各种外部工具之间的一套“通用接口”。如果没有统一标准，AI 应用每接入一个数据库、文件系统或业务服务，都可能要单独适配一遍。MCP 想解决的，就是这类重复接入的问题。

Host、Client 和 Server

MCP 中有三个经常一起出现的角色：

Host：用户真正使用的 AI 应用，比如 Codex、Claude Desktop 或其他智能体应用。它负责管理对话、调用模型和协调外部能力。
Client：Host 内部负责 MCP 通信的组件。一般来说，Host 每连接一个 MCP Server，就会创建一个对应的 Client 来维护这条连接。
Server：向外提供能力的程序。它不仅可以提供 Tools，还可以提供 Resources、Prompts 等内容。Server 可以在本地运行，也可以是远程服务，所以这里的“Server”不能简单理解成一台物理服务器。

这里有两个我一开始理解得不够准确的地方。

第一，MCP Server 不只是一个“装了很多 Tool 的工具库”。Tool 确实最容易理解，但不是 MCP Server 能提供的全部内容。

第二，CLI 不是 Host 的对立面。CLI 只是命令行这种交互形式，一个 CLI 应用本身也可以充当 MCP Host。之前把两者放在一起比较，其实是把“应用扮演的角色”和“应用长什么样”混在了一起。

一次工具调用是怎样完成的？

先忽略实现细节，一次常见的 MCP 工具调用大致会经过下面几步：

Host 中的 MCP Client 与 Server 建立连接，确认协议版本和双方支持的能力。
Client 获取 Server 提供的工具列表与说明。
用户提出需求，Host 把问题和可用工具的信息交给大语言模型。
模型判断是否需要调用工具。如果需要，它会给出工具名称和参数。
Host 通过 Client 向 Server 发送调用消息。
Server 执行工具，然后把结果返回给 Host。
Host 再把结果交给模型，由模型整理成用户能看懂的回答。

我原先把这个过程写成“模型输出 JSON 文件，然后 Host 把文件传给 Server”，这个说法不准确。这里传递的通常是符合 JSON-RPC 2.0 格式的消息，并不需要真的生成一个 .json 文件并保存下来。

模型的 Function Calling 和 MCP 也不是同一个概念。我的理解是：Function Calling 解决的是模型怎样表达“我想调用哪个工具、参数是什么”；MCP 解决的是 Host 与 Server 怎样按照统一标准通信。两者可以配合，但不能直接画等号。

RAG：让模型先查资料，再回答

RAG 的全称是 Retrieval-Augmented Generation（检索增强生成）。

名字听起来比较硬，思路其实很好理解：不要只让模型凭记忆回答，而是先找出相关资料，再让它参考资料作答。 我觉得“开卷考试”是一个很形象的比喻。

大语言模型虽然学过很多通用知识，但它不会天然知道公司的内部资料，也不一定掌握某个专业领域的全部细节。如果把整个知识库一次性塞进上下文，内容太多、成本太高，还会混入大量与问题无关的信息。

所以更实际的做法是：用户问什么，系统就先从知识库中找出最相关的几段内容，再把这些内容交给模型。

查询之前：先准备知识库

常见的准备流程包括：

清洗数据：处理乱码、重复内容和多余格式。
切分文档：把长文档拆成大小合适的文本块，同时尽量保证语义完整。
生成向量：使用 Embedding 模型把文本转换成向量表示。
建立索引：保存文本、向量和来源等信息，方便之后快速检索。

不过，RAG 并不等于向量数据库。向量检索只是常见方案之一，实际项目中也可以使用关键词检索，或者把关键词检索和向量检索结合起来。

用户提问之后：召回、重排和生成

召回做的是“先捞一批可能有用的内容”。如果使用向量检索，系统会把用户的问题转换成向量，再从知识库中找出相似度较高的文本块。这个阶段面对的数据量很大，所以重点是快，而且要尽量别漏掉真正相关的内容。

重排是在召回结果中进一步精挑细选。常见做法是使用 Cross-Encoder，把问题和每一段候选文本放在一起判断相关程度，再重新排序。它通常更准确，但计算也更慢，所以适合处理召回后的小批候选内容，而不是直接扫描整个知识库。

最后，系统把最相关的内容整理成上下文，连同问题一起交给大语言模型，由模型生成答案。

我原先认为召回和重排都会使用 Embedding 模型，只是一个粗略、一个精细。这个理解也需要修正：向量召回通常使用 Bi-Encoder 分别生成问题和文档的向量，而 Cross-Encoder 重排器会同时读取问题和候选文本，直接输出相关性分数。 它不是简单地再算一次向量相似度。

当然，并不是每套 RAG 系统都必须加入重排。数据量不大、问题比较简单时，一次检索可能就够了。工程方案还是要看实际需求，没必要为了让流程显得完整而硬加步骤。

AI 板块小结

MCP 和 RAG 经常一起出现在 AI 应用开发的讨论中，但它们解决的不是同一个问题：

MCP 关心的是：AI 应用怎样用统一方式连接外部服务和工具。
RAG 关心的是：AI 怎样从知识库找到相关资料，并参考资料回答问题。

两者也可以组合起来。例如，一个 MCP Server 可以提供知识库检索工具，而这个工具背后运行的就是一套 RAG 系统。

今天算是把基本流程捋顺了，但离真正掌握还差得远。等网络环境配置好以后，我还是得把 Hugging Face 的教程补上，再自己动手做一个简单的 RAG 项目。概念看十遍，可能都不如亲手跑一遍来得实在。

风电学习：第一次认真看风机运行散点图

风电这边，在马靖皓老师，也就是马哥的带领下，我接触了一些数据处理后会产出的分析报告，也开始认识报告里常见的专业名词和散点图。

以前看到这种图，第一感觉就是一大片密密麻麻的点。横轴和纵轴的名称都认识，但真要解释这些点为什么会形成这样的趋势，就说不上来了。今天把功率、风速、桨距角和发电机转速放在一起看之后，终于有了一点整体感觉。

风机运行数据的四类散点图

功率—风速曲线

功率—风速曲线用来观察风速发生变化时，风机输出功率怎样变化。

最直观的想法是“风越大，发电越多”，但实际运行不是一条无限向上的直线。风速太低时，风机还达不到正常发电条件；达到切入风速后，功率才开始明显上升。接近额定风速时，风机已经达到设计功率，控制系统会尽量把输出限制在额定功率附近。如果风速高到超过安全范围，风机还可能停机，以保护设备。

真实数据也不会像课本里的理论曲线一样光滑。湍流、空气密度、限功率策略、设备状态和测量误差等因素，都会让散点出现一定程度的离散。分析时不但要看整体趋势，也要留意有没有异常分支或不正常的空缺。

功率—桨距角散点图

这里先纠正一个术语：原笔记中的“浆矩角”应该是 桨距角。

可以先用一个不太严谨但比较直观的比喻来理解：桨距角有点像叶片迎风姿态的调节旋钮。

风速较低时，风机希望尽量多地捕获风能；风速变高以后，如果完全不加控制，功率、转速和载荷都可能超过安全范围。这时控制系统就会调整叶片角度，减少叶片从风中吸收的能量。

所以在功率—桨距角散点图中，接近额定运行区域后，通常能看到桨距角发生比较明显的变化。

我原先把它简单理解成“达到最大功率以后开始变桨，防止叶片超速”。大方向没错，但说得太绝对。不同风机的控制策略并不完全相同，有些机组在达到额定功率以前就可能开始变桨；限功率、启停和故障等状态，也会形成不同的散点分支。

桨距角—风速曲线

在正常发电的部分负荷区域，桨距角通常维持在较小值附近，让叶片尽量有效地利用风能。进入额定运行区域后，随着风速继续升高，控制系统往往会逐渐增大桨距角，用来限制功率、转速和设备载荷。

从图形上看，常见趋势就是前面比较平，后面逐渐向上展开。

不过，我之前记录的“没有达到最大功率时，桨距角一直为 0”并不严谨。实际数值是不是 0°，还要结合具体机型、桨距角零位定义和控制策略判断。做数据分析时，最好少用“永远”和“一定”这种词，尤其是在还没有确认机型与工况的时候。

功率—发电机转速曲线

对于常见的变速风机，在部分负荷区域，发电机转速升高时，输出功率通常也会跟着增加。因此在散点图上，能够看到两者一起上升的趋势。

但发电机转速不可能一直增加。进入额定运行区域以后，控制系统会把转速限制在允许范围内，功率也会保持在额定值附近。

所以“转速越高，功率越高”只能描述一部分运行区间，不能当成风机在所有工况下的固定规律。看到功率—转速图时，应该先判断散点属于哪个控制区域，再去解释两者之间的关系。

这条稀疏的散点分支，可以直接忽略吗？

桨距角散点中的稀疏分支

图中能看到一条比较稀疏的散点分支。当时的初步判断是，它可能来自没有完全清理掉的历史控制策略，也可能只是少量数据异常。

不过回头想想，“点不多，所以不用管”这个判断还是太快了。

少量散点不一定代表设备故障。它可能来自控制策略切换，也可能出现在启机、停机、限功率或其他短暂工况中；但它同样可能来自传感器误差、数据质量问题，甚至是真正的设备异常。

更稳妥的做法，是先找到这些散点对应的时间，再结合运行状态码、报警记录、风速、功率和其他测点一起分析。如果这些点总是在某种正常状态切换时出现，那大概率可以解释；如果它们持续存在，并且伴随其他指标异常，就值得继续往下查。

散点少，只能说明这种情况出现得少，不能直接说明它不重要。

风电板块小结

今天最大的收获，不是记住了四张图分别叫什么，而是开始知道该怎样顺着控制逻辑看数据：

风速发生变化后，功率为什么会这样变化？
接近额定工况时，控制系统做了什么？
桨距角和转速的变化，能不能与功率曲线对应起来？
偏离主要趋势的散点，是正常工况、数据问题，还是设备异常？

目前的理解还比较基础，有些规律也只适用于常见的变速、变桨风机，不能直接套在所有机型上。之后如果继续接触实际数据，我希望能把状态码和时间序列也放进来一起分析。只看一张静态散点图，可以发现现象；把前后的运行信息补齐，才更有可能解释现象。

今天就记到这里

今天的 AI 和风电是两个完全不同的学习方向，所以不强行把它们总结成一个大道理了。

对我来说，写这篇记录最实际的作用就是把几个理解得不够准确的地方及时改过来。当天学完、当天整理，至少以后再看到 MCP、RAG 或风机散点图时，不至于又从零开始。