优维大模型解密：从提示词工程到场景应用，剑指AIOps的牛刀小试

优维科技EasyOps

墨衍会员 · AI 创作全网分发码龄5年

关注

原创最新推荐文章于 2026-03-31 12:45:54 发布 880 阅读 AI 写同款· GEO 优化 ›

AIOps探索 | 基于大模型构建高效的运维知识及智能问答平台（2）案例分享运维大模型的案例分享阅读详情

莫名其妙的“涌现”袭来，就像是海上来路不明的诡异海啸，当很多人都在吹捧大模型时，优维则选择理性潜入深水区，掌握了大模型的来龙去脉，也在实际应用中获得产品经验方法论。

这篇文章旨在全面剖析优维科技在大模型应用领域的思考、布局与真实场景对接成果。

从鲁迅和周树人说起：

窥见大模型“涌现”背后的局限性

图1

图2

强大如ChatGPT，也难逃“鲁迅与周树人”的认知陷阱，对于大模型当下的局限性，我们认为至少可以总结如下几点——

缺乏领域特定信息：LLM仅基于公开数据集训练，缺乏领域特定信息、专有信息等非公开数据
容易产生幻觉：底层原理是基于概率的token by token的形式，不可避免产生“一本正经胡说八道”的情况（图1）
时效性差：模型训练完后，无法获取更新后数据集的信息（图2），且无法频繁重新训练

改进大模型，我们认为至少应该具备如下要素——

外部数据库承载专业知识：用向量数据库构建知识库；使用数据库扩展大模型的外部记忆
微调：使用少量标注数据增强特定领域能力
提示工程：添加提示词，生成更加准确的信息

带着这样的思考，我们将进入本文的第一个重点内容。

本地知识库搜索：

优维大模型的初始化实践

图3

不久之前，优维已经上线了本地知识库搜索（图3），我们的产研部门有很多同事已经用了一段时间，提到大模型，很多用户的第一反应是我要去训练，仿佛所有的东西都要训练。其实不然，我们有另外一套执行机制。

今天就针对性分享一下，优维的本地知识库是怎么做的，以及我们是怎么把本地语料与大模型结合起来的。

这里首先要引入一个概念：向量数据库。

对于这个概念，相信长期关注大模型相关资讯的朋友应该知道，它通常和大模型一起被提及。

向量数据库是用来存储和检索向量的一个数据库，其重点特性是适应数据量大、数据维度高以及相似度匹配的场景。你可以用来检索和存储文本数据，还可以用于自然语言处理领域，比如文本的分类、聚类和相似度计算等。

回归今天的主题，大家只要记住：向量数据库可以计算语义相似度。

举个例子，我们随机提出某个关于EasyCore的问题：EasyCore里的某个工具的用途？或者说我的EasyCore是怎么备份的？

向量计算就会算出这篇文章的向量和该问题的向量的最大相似度，凭着向量最大相似度，我们就能直接找到最相关的介绍文档。

图4

厘清向量数据库的特性后，接下来的问题是：向量数据库怎么用？

我们在用的文本也是通过一个模型，但请注意，它并不是大模型，而是一个把文本语料转换成向量的专用模型。基于这样一个通用的底层逻辑是，无论是文本还是图片、音视频，都可以转换成向量之后存到向量数据库，然后再去执行向量查询（图4）。

图5

优维的本地知识库是怎么做的呢？（图5）

首先，我们要把所有的文档加载进来，存到向量数据库。

文本转换存储的逻辑一分为二——原先是文本的直接存储文本；原先是PDF、word或图片的则先解析后存储，比如图片用OCR识别，PDF用PDF的解析，word用word解析……最终目的都是把所有的资料转换成文本。这是第一步。

第二步，针对某些比较大的文本，比如一篇数以万字的文章，我们会执行向量搜索。当文本偏大时可能会影响匹配的准确性，我们需要将文本按照一定的长度进行分割，例如每隔1K或两k进行分段操作，然后对每一段进行单独计算向量，完成计算后再把向量存储到数据库，这就引出另一个概念——文本向量化。

文本向量化的过程中有一个重点，就是把问题也做成一个向量，并匹配到向量数据库里，从而得到和问题语义相似度最高的文本，再把与之对应的文档全拿出来，和问题组成一个提示词打包交给大模型，我们最终会得到大模型反馈的结果。

图6

这个就是所谓的提示词，大模型的应用是否有效，写好、写对提示词至关重要。

关于如何写提示词，我们来看两个示例（图6）。

示例1主要是根据上下文来回答问题，如果内容不在上下文里则不回答，只使用上下文提供的内容即可。通常来讲，这两个示例都有广泛的借鉴性和指导性，但示例2更适用于优维的大模型案例——其中的knowledge文档，就是将我们从向量数据库匹配出来的那几篇文档，连同问题一起全部贴到这里，打包成几k大小的提示词一并提交给大模型，最终大模型会反馈我们所看到的那个回答。

以上就是大模型关联本地知识库搜索的实操案例。

如你所见，整个过程并不需要训练，它只是一个放之四海而皆准的通用大模型罢了。

自动生成Storyboard：

低代码+CMDB与大模型的无缝衔接

图7

除了本地知识库，我们还用低代码做了一个自动生成Storyboard。先看一下效果（图7）。

这个是优维EasyMABuilder低代码开发平台的其中一个版块——VisualBuilder，相信用过优维开放平台的客户中，尤其是负责低代码、前端开发的朋友应该比较熟悉。

按照过去的操作方法，我们需要先在组件库里选购组件，再根据我们的需要填写相关的属性，这是一个比较繁琐和低效的过程。于是我们在这里加了一个AI助手，通过AI助手，我们可以直接用自然语言描述生成一个表格，该表格提供实际数据，同时允许我们进一步发出更明确的指令，例如哪一列支持排序、哪一列支持搜索……总而言之，我们可以指定这个表格里的每一个属性，你指定得多详细它就能生成得多详细。

这个效果是怎么做的呢？其实就是我们前面提到的那个大模型对接逻辑，通过向量搜索和提示词工程让大模型自动生成了低代码Storyboard，构成了一个实时可用的构件。

图8

我们把Storyboard的自动生成逻辑详细化（图8）。

图中的构件需求就是我们前文的输入，目的在于告诉它我们要做什么。在生成之前需要做的准备工作是初始化向量数据库——把数百个构件的功能说明以及构件ID全部向量化并传到向量数据库，然后把构件需求匹配到向量数据库，看看哪些构件能够满足我们的需求——注意，这只是一个类似Google的搜索动作，并不准确，所以我们会搜出和需求最匹配的topK个数据来，

然后交给大模型由大模型来告诉我们应该用哪个构件来完成生成任务。我们需要从大模型返回的结果解析出构件ID，有了构件ID我们就可以到CMDB里查到构件的详细定义，再把富含示例、事件处理等属性的构件详细定义再度给回大模型，最终由大模型生成Storyboard。

图9

这里我们再重点复盘一下匹配出来的top10是怎么选择构件的（图9）。在告知大模型需求后，我们要求它只返回选择的构件，然后它以构件ID加描述的格式返回给我们，取冒号前面的一部分解析得到构件ID后即可前往CMDB查询。

图10

接下来进入关键点：从CMDB拿到构件的属性定义后如何生成Storyboard？这里的流程就相对复杂一些。

首先，我们要直接告诉它Storyboard是干什么的。通过图片我们可以看到有Storyboard的schema定义，这个schema是固定的，它定义了这个构件的基本结构。Schema下面的定义就是我们刚才查出来的定义，它包含构件属性、事件以及示例等基本条件，有了基本条件就给它提要求了（具体步骤参见图10）。

审视整个过程我们会发现，虽然用户只是在前端输入类似“我要一个表格”这样看似简单的属性，但真正交给大模型的其实是背后这一大堆东西，最终的效果就是：我们输入一个需求，然后大模型生成对应的东西供我们直接使用。

通过以上两个案例，大家或许对优维大模型有了大致的了解——就是想办法把我们日常的需求梳理好，全部喂给大模型并按我们的要求输出结果，让大模型表现得像一个智能机器人。可见，大模型并不是简单的聊天对话框里那些功能，而是可以通过提示词来实现更多的功能。

到这里，再度引出一个概念——提示词工程。

提示词工程：

构件大模型的超级基建

提示词工程的定义：指导生成式人工智能（generative AI）解决方案生成所需输出的过程。我们在前文说过：大模型的应用是否有效，写好、写对提示词至关重要。提示词工程，就是一个“过程决定结果”的大项目。

什么是优质的提示词？

首先就是要清晰明确。提示词一定要简洁，尽可能减少歧义和模糊，让AI能够更清楚地知道我们想要什么，例如我们可以明确指定生成内容的类型、格式、长度、风格、语言等，也可以要求它回答中文或英文、返回用Python还是go……越明确越好，这样AI在生成的过程中就会减少其他的错误。

第二个是通用性强。就是当我们换了主体词之后一样能得到结果，例如在前面生成Storyboard的那个案例中，可以生成按钮的Storyboard，也可以生成表格的,表单的，就是一定要有通用性。

第三个是生成结果稳定。在前面的自动生成案例中，我们让它第一步做什么、第二步做什么

……其目的就是为了让生成结果稳定，确保多次生成内容的格式是一样的。

图11

怎么写好提示词？

提示词有很多写法，比如有启发式提示、有思维树提示、有思维链提示等，这里分享一个比较有趣的案例（图11）。这个案例展示了一个大模型的现象——大模型本来是不会的，但我们把思考过程告诉它，它也会学着你去这样思考。

首先看下左边的常规提示案例——

罗杰原有5个网球，后又买了2罐，每罐3个，请问他现在一共有几个网球？我们先以直接说出计算结果的方式给出了示例回答：11个。

然后再给大模型独立出题：食堂有23个苹果，用掉20个后又买了6个，请问现在有几个苹果？它给出的答案是27。

显然，大模型根据我们的示例作出的回答是错误的。

再来看右边的思维链提示案例——

还是同样的提示条件，但这次不是直接给出答案，而是告诉它我们的计算过程，于是神奇的事情发生了：大模型学习了我们的计算方法，最终得到了正确的答案。

这两个示例的差异在于，左边是直接给结果，右边是把思考的过程告诉大模型，然后它给出了正确答案。大模型的核心能力之一在于，它会按照你的提示词模式去思考，提示词的技巧是多样化的，如果我们能做到一步一步指导它去做思维和思考动作，它就会按照我们的逻辑生成更准确的内容，这就是思维链模式的提示词。

到底什么样的提示词才是最好的？没有人能说的明白，就像没有人能明白大模型突然“涌现”的能力一样。提示词工程的完善有待大家去逐步探索，吸收别人的经验，例如前文提到的启发式、思维链、思维树等提示方法均可借鉴参考，结合自己的切身需要和思考，写出场景下最好的提示词。

随大模型“涌现”的两个概念：

LLM Powered Agents与LangChain

第一个概念：LLM Powered Agents

我们称之为“大模型驱动的智能体”——Agent可以理解为人工智能概念里的智能体，随着大模型能力的“涌现”，Agent将用大模型来驱动。

图12

当用户输入自己的需求后，会启用一个AI智能体，该AI智能体可以利用大模型驱动整个任务完成，可以关联的本地文档数据库，或者执行代码、生成代码、执行任务等等（图12）。它作为一个大脑，根据用户的输入去把外部的执行工具、任务等全部调度起来，对用户来说只是一个人工智能的服务，但背后的逻辑是基于大模型、机器学习、文档、代码执行……来实现需求，是一个非常庞大的技术宇宙，是实现真正的人工智能的智能体。

图13

另外一张图则更能直观地体现“大模型即大脑”的底层逻辑（图13）——通过一个抽象的action（该action可能是工具）调接口、执行代码和外界交互，再反馈回来组成新的上下文，然后再去调度，这是一个循环交互的过程。其要传达的核心信息就是：大模型就是一个大脑控制器，你让它做什么，它就会调度能用到的工具、接口、以及代码去把这个事情完成。但无论是调工具也好，调接口也罢，其所依赖的都是我们在前文所说的提示词。

这就是所谓的大模型驱动的智能体，是关于大模型的一个相对高级的概念。

第二个概念：LangChain

LangChain是一个用来构建大模型应用的框架，它提供了一套工具、组件以及接口。运用这个框架可以很方便的去构建大模型的应用，各个方面都有对应的sdk可以直接使用，比如前面提到的文档加载、拆分、向量化、存到数据库等等都有对应的库，我们只需要选好模型和处理流程，其他基本不用管，直接调用sdk就可以把处理逻辑拼接起来。