AI和运维的故事
AIOps 与大模型知识指南
AIOps 的实现离不开现在大模型的大力发展，所以要做 AIOps 相关的业务，就需要了解并使用大模型相关知识。本次内容将从以下6个章节介绍大模型相关的知识：
- Prompt Engineering
- Chat Completions、Memory、JSON Mode
- Function Calling
- Fine-tuning
- 检索增强生成（RAG、Graph RAG）
- 本地部署常见的开源模型
Prompt Engineering
Prompt简介
Prompt Engineering 是指通过设计、优化输入给 AI 模型的“提示词”（Prompt），来引导模型生成更准确、有用或创意性输出的技术。它是一门结合语言理解、任务建模与人机交互的艺术与科学。
尽管现在的大模型具备强大的自然语言理解和生成能力，但它的行为高度依赖输入的提示词（Prompt），所以 Prompt 决定着大模型的输出质量。
当用户输入 Prompt，大模型接受到的其实是一个个 Token，这是为什么呢？在大模型中，Token 是模型处理文本的基本单位，人类是通过文本来理解内容，而大模型是通过 Token 来理解内容。它可以是一个单词、标点符号、数字，甚至是一个子词（subword）。不同模型对 Token 的划分方式略有不同，但总体上可以理解为：把一段文字切分成一小块一小块的“单元”就是 Token 。
比如，当用户输入 "Hello, world!"，会被拆分为以下几个 Token（以 GPT 模型为例）：“Hello”、“,”、" world"、“!”，所以一共是 4 个 token。当大模型接收 Token 后，会根据这些 Token 进行推理生成新的 Token，最后再把这些 Token 转换成人类可读的文本输出。
Tips：
每个模型都有最大上下文长度限制（比如 GPT-3.5 是 4096 tokens，GPT-4 可达 32768 tokens），包括你的 Prompt + 输出内容都不能超过这个限制。另外，目前商用大模型的Token免费额度都有限，如果设计的Prompt不合理，就会产生额外的费用，我们可以看看Prompt中的哪些内容对Token的数量有实质的影响。
| 类型 | 影响程度 | 说明 |
|---|---|---|
| 文字长度 | ⬆️ 高 | 内容越长，Token 越多 |
| 标点符号 | ⬆️ 中 | 逗号、句号、引号等都会单独算作Token |
| 专业术语/生僻词 | ⬆️ 中 | 某些模型可能将其拆成多个Token |
| 语言种类 | ⬆️ 中 | 英语通常比中文Token更少 |
| 编程语言 | ⬆️ 高 | 特殊符号多，Token数量上升快 |
所以，我们在设计Prompt的时候要记住 并非输入的越多，回答的就越好 。要记住设计 Prompt 的几个核心原则：
- 具体描述，避免模糊：不说 “不要遗漏重点”，而是明确 “请突出 XX、XX 两个关键信息”；
- 排序重要事项：如果有多个需求，按优先级说明，比如 “首先分析日志错误，其次统计出现频率，最后给出解决方案”；
- 使用标准格式：比如用 Markdown 的标题、列表等结构，让模型输出更规整，例如 “请用 ### 问题原因、### 解决步骤的格式整理结果”；
- 拆解任务，给出思路：复杂问题分步骤引导，比如 “先分析错误类型，再匹配历史案例，最后生成修复建议”。
Prompt的开发模式：Zero-shot 和 Few-shot
日常工作中，常用的Prompt编写模式是 Zero-shot 和 Few-shot。
- Zero-shot 模式是纯自然的描述任务，不提供具体的例子，比如仅说明识别用户意图可能涉及查询日志、指标或运维操作。
- Few-shot 模式在自然语言任务描述之外，提供参考例子，如给出三个示例，以增强大模型的推理准确性。
由于 Few-shot 模式会给大模型提供例子，这能使大模型回答的更加精准， 所以在日常使用中，我们优先采用 Few-shot 模式。但是，对于处理逻辑性比较强的任务时，单纯 Few-shot 不太够用，这时候就要引入 思维链（Chain of Thought）。
Chain of Thought
思维链是一种技巧，旨在让大模型在给出答案前进行逐步思考，并在每一步提供解释，以增强答案的解释性和提高推理的准确性。
一个典型的 CoT Prompt 包括以下几个部分：
- 问题描述
- 明确要求分步思考
- 示例演示（可选）
- 最终要求输出答案
示例Prompt：
问题：小明有 5 个苹果，吃了 2 个，又买了 3 个。他现在有多少个苹果？
请一步步思考这个问题，并写出你的推理过程，最后给出答案。
大模型可能的回答是：
- 小明最开始有 5 个苹果。
- 他吃了 2 个，剩下 5 - 2 = 3 个。
- 他又买了 3 个，所以现在有 3 + 3 = 6 个苹果。
答：小明现在有 6 个苹果。
在运维场景中，可以把专家知识库中的内容加入到系统提示语中，让大模型扮演运维专家的角色，优先以提供的知识库而非自身训练的内容回答问题，这种基于特定知识库进行问题解答可以提升回答的准确性和专业性。
Prompt 分片
Prompt 分片是指将原始 Prompt 切分为多个小块（chunks），然后分别处理这些小块内容，并最终整合输出结果的一种策略。
场景：
- 输入文本太长，超过模型最大 Token 数限制。
- 需要对文档、文章、日志等内容进行摘要、分析、问答操作。
- 提高模型对长文本的理解和处理能力。
流程：
- 拆分：将长文本按一定规则拆分成多个chunk。
- 处理：对每个chunk进行单独运行Prompt，生成中间结果。
- 整合：将所有中间结果合并，生成最终的输出。
分片方式：
| 分片方法 | 描述 | 适用场景 |
|---|---|---|
| 固定长度分片 | 每个 chunk 固定长度 | 文本较长且结构不敏感的任务 |
| 基于语义分片 | 按句子、段落、章节等 | 需保留逻辑结构的任务（论文、合同等） |
| 滑动窗口分片 | 前后chunk有重叠防丢失 | 关键信息可能跨chunk出现的场景 |
| 向量化分片 | 用向量匹配最相关chunk | RAG、智能检索、问答系统 |
- 注意事项：
- 信息丢失风险。
- Token 成本增加。
- 一致性问题。
Chat Completions、Memory、JSON Mode
Chat Completions
Chat Completions（聊天补全） 是现代大语言模型（如 OpenAI 的 GPT-3.5、GPT-4、通义千问、Claude 等）提供的一种 API 接口，专门用于处理多轮对话任务。
- 输入：消息列表，包含角色、内容等
- 输出：模型的回复
// 输入示例
{"model": "gpt-3.5-turbo","messages": [{"role": "system", "content": "你是一个翻译助手，擅长中英文互译。"},{"role": "user", "content": "请将以下中文翻译成英文：'人工智能是未来的关键技术之一。'"},{"role": "assistant", "content": "'Artificial intelligence is one of the key technologies of the future.'"},{"role": "user", "content": "谢谢！"}],"temperature": 0.7
}
// 输出示例
{"choices": [{"message": {"role": "assistant","content": "不客气！如果你还有需要翻译的内容，请随时告诉我。"}}]
}
有三大角色：
- system：系统指令，设定 AI 行为、身份或任务规则。
- user：用户输入，代表用户说的话或提问。
- assistant：模型输出，即 AI 的回答。
实现例子（Python代码，使用OpenAI API）
from openai import OpenAIclient = OpenAI(api_key="sk-xxxx", base_url="https://api.siliconflow.cn/v1")completion = client.chat.completions.create(model="deepseek-ai/DeepSeek-R1-0528-Qwen3-8B",messages=[{"role": "system", "content": "你是一个运维专家，你可以帮忙解决专业的技术运维问题"},{"role": "user", "content": "如何在Ubuntu上安装Python3，请用一句话总结"}]
)print(completion.choices[0].message.content)
- 若要让模型“记忆”历史内容，就要把所有历史消息都带上每次请求的 messages 参数。
LangChain Memory
在处理大模型记忆的时候，直接管理上下文较为复杂，因为大模型由于Token的限制无法记住所有的对话，这里就可以引入 LangChain 这种长期记忆的管理方法。
| 类型 | 描述 | 是否持久化 |
|---|---|---|
| ConversationBufferMemory | 缓冲记忆，顺序存储全部消息 | ❌ |
| ConversationBufferWindowMemory | 保留最近N条对话 | ❌ |
| ConversationTokenBufferMemory | Token长度限制的历史 | ❌ |
| ConversationSummaryMemory | 自动摘要历史对话 | ❌ |
| ConversationKGMemory | 提取实体和关系做知识图谱 | ❌ |
| RedisChatMessageHistory | 到 Redis/DB 持久存储 | ✅ |
典型使用方式
- ConversationBufferMemory …（省略具体代码）
- 推荐用 LangGraph 高级实现，对多用户/会话支持更好
JSON Mode
要求模型稳定输出 JSON 格式，方便程序自动扩展。
示例：
from openai import OpenAIclient = OpenAI(base_url="https://api.siliconflow.cn/v1", api_key="sk-xxxx")response = client.chat.completions.create(model="deepseek-ai/DeepSeek-R1-0528-Qwen3-8B",response_format={"type": "json_object"},messages=[{"role": "system", "content": '你现在是一个 JSON 对象提取专家，请参考我的JSON定义输出JSON对象，示例：{"service_name":"","action":""}，其中action可以是 get_log,restart,delete'},{"role": "user", "content": "帮我重启pay服务"}]
)
print(response.choices[0].message.content)
输出：{"service_name":"pay","action":"restart"}
Function Calling
Function Calling（函数调用） 是大型语言模型（LLM）的一项能力，允许模型根据用户的自然语言输入，识别并调用预定义的工具或 API 函数 ，从而执行特定任务。
- 与外部系统交互
- 执行计算或数据查询
- 生成结构化的输出供后续处理
示例（OpenAI Function Calling）
（Python代码略，详见原文）
- 模型识别工具，生成调用参数
- 开发者解析参数并调用实际函数
- 把结果作为对话历史继续投喂模型，实现多轮自动响应
Fine-tuning
Fine-tuning（微调） 是在预训练语言模型的基础上，结合特定领域或任务，用自有数据再训一轮，从而获得更优的表现。适合在对结果风格、专业领域表现、规则遵守有更高要求时使用。
流程：
- 准备原始数据（如日志内容及其优先级标注）
- 转成JSONL 格式
- 上传数据到模型平台，发起微调任务
- 用微调后模型进行推理
检索增强生成（RAG、Graph RAG）
RAG（Retrieval-Augmented Generation）
- 结合信息检索与生成，模型回复时可以动态查阅外部知识库，提高准确性。
步骤：
- 索引：文档加载→拆分→向量化→存储
- 检索与生成：实时检索相关分片，作为上下文交互 LLM
Graph RAG
- 把文档拆解成实体和关系形成知识图谱，结合图数据库做推理。
- 可以回答涉及关系与结构的问题。
本地部署常见的开源模型
为保障数据安全、降低使用成本，本地部署大模型成为越来越多企业的选择。
- Ollama
- LM Studio
- FastChat
- Open WebUI
过程简要：
- 安装工具
- 拉取需要的模型
- （可选）自定义 System Prompt
- 用 API/WebUI 调用本地推理
总结
本文围绕 AIOps 智能运维 与 大语言模型（LLM） 的结合展开，介绍了 Prompt Engineering、Function Calling、RAG、Graph RAG、本地模型部署等关键技术的应用方式，并通过实际示例展示了如何将这些技术用于日志分析、故障定位、智能问答和自动化运维场景。
我们看到，Prompt 是引导模型输出的核心工具，而Function Calling 和 Memory 机制 则让模型具备了“执行能力”和“记忆能力”。RAG 和 Graph RAG 的引入，使得系统能够在不微调模型的前提下，灵活接入企业知识库，提升回答的准确性与逻辑性。此外，为保障数据安全、降低使用成本，本地部署开源模型 成为越来越多企业的选择。Ollama、FastChat、Text Generation WebUI 等工具，使得本地推理变得简单高效。