> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 构建内部AI助手值得吗？ - URL: https://www.hubwiz.com/blog/is-it-worth-building-an-internal-ai-assistant/ - Published: 2026-02-27T15:29:01.000Z - Updated: 2026-02-27T15:29:01.000Z - Description: 公司正在迅速采用 AI 解决方案。问题不再是要使用 AI。更有趣（也更难）的问题是构建自己的东西是否有意义，还是依赖外部解决方案。 - Author: admin - Tags: APPLICATION, #Import 2026-10-14 14:41 今年我加入 IBM 作为实习实习生，几乎立即被指派构建一个 AI 助手来分析配置文件并确定是否从 IBM 软件的一个版本升级到另一个版本会为客户引入破坏性变更。在那之前，我对 AI 的经历是……使用 ChatGPT 进行研究，偶尔要求它帮助我调试大学作业。这就是我的 "AI 工程" 背景的程度 任务本身似乎可以完成，特别是所有 "三步构建你自己的 AI！" 的材料都在那里。潜在的好处很明确：遍历配置文件通常（正如我很快发现的）需要几天时间 — 一个人需要具备适当的 IBM 软件产品知识。目标是将整个软件套件的这一时间减少 80-90% ## 1、初始想法 初始工作流程在很大程度上将模拟人类如何处理相同的问题。我设置了一个 MCP 服务器（模型上下文协议，一种以受控方式获取结构化外部数据并将其传递给 LLM）来检索 IBM MQ 配置。想法很简单：拉取配置，要求 LLM 查找相关的 IBM 文档和社区内容，比较所有内容，然后生成升级建议，如 "此参数的行为发生变化" 或 "此对象类型已被弃用" ![None](https://www.hubwiz.com/blog/content/images/2026/02/1-Hfs2HcKzLIZkw4jeGtIFWw.png) 图 1：脑海中包含 MCP 逻辑的初始架构 ### 1.1 Token 管理 起初，一切都很好。我们有一些简单的代码可以开始，由（令人愉快地）另一个 AI 编写，设置了 MCP 服务器，它正在正常地检索配置，并获得了访问 IBM watsonx 来处理输入。在那时，这需要大约每次运行 10,000 个令牌，而免费的 "Lite" 计划每月只提供 300,000 个令牌，因此我们很快就用完了令牌。在某个时候，单次运行花费了 60,000 个令牌。这就是当它停止感觉像一个很酷的实验并且资源管理问题开始出现的时候 > 学到的教训 Token 是大型语言模型的原子计费单位，提示中的每个单词和输出中的每个单词都被令牌化并相应计费 当 Token 成为问题时： - Token 变成 **资源管理问题**：它们非常快地耗尽，而且你不太可能免费获得无限数量的它们（反正总要有人付费）。这就是我们找到 **Ollama** 的方式，这是一个开源工具，允许你本地部署模型 - 使用我的本地笔记本电脑资源 。**优点**：无限令牌 ；**缺点**：运行时间从 10 秒增加到 2 小时 ### 1.2 LLM 本身不会浏览互联网 重要的是要区分 AI 助手与 LLM 不同。AI 助手通常通过额外的工程来访问实时数据，抓取页面，或调用 API，然后将其反馈给模型 这种发现能力并非模型本身固有的 — 它只是一个接受输入并生成输出的算法。在我们的案例中，由于我们使用的是本地托管的模型，除非我们明确地进行工程设计，否则不会获取任何外部内容。当我们在提示中添加链接时，我们基本上希望它能够去并从这些 URL 获取内容。然而，独立的 LLM 不会浏览互联网，而是根据其训练数据和你明确在提示中提供的任何信息生成响应。无论我们是添加还是删除链接，幻觉的数量都没有变化，我们意识到某种形式的检索增强生成（RAG）需要使我们的 LLM 能够从外部数据中检索并整合新信息 幸运的是对我们来说，IBM 开发实验室的人们也在探索 AI 能提供什么，从他们我们发现了关于统一搜索团队，该团队使用 Milvus 在向量数据库中创建了 IBM 文档的集合 **优点**：现在我们的工具肯定能够访问文档；我们注意到幻觉数量减少了，输出变得更加精确 **缺点**：引入检索意味着向系统架构添加另一个移动部分。即使它被包装在一个调用中，模型也不再只是将配置与已知行为进行比较；它还必须解释检索的文档并在同一上下文窗口内协调重叠的来源。这增加了令牌使用，并使输出对检索的块中的措辞小变化更加敏感。检索减少了幻觉，但它也创建了对检索准确性和最终输出质量之间更紧密的依赖关系，这并不总是容易控制 ## 2、重新思考 MCP 方法 MCP 服务器结果并不是要成为答案，正如我们的解决方案所暗示的，客户会允许我们访问他们的内部系统，这是不太可能的。它被替换为提取配置并手动上传到工具中。长期来看，我不知道我们是否会觉得足够安全，可以让 AI 访问并潜在地更改生产系统。目前，由于幻觉和对客户数据的潜在影响，这似乎有风险 作为这一学习的结果，我们采取了迭代步骤来简化我们正在使用的架构，如图 2 所示。 ![None](https://www.hubwiz.com/blog/content/images/2026/02/1-_Muwl3Ofv3k0GOpWoOfMEA.png) 图 2：简化的架构 这是我第一次经历一些东西在理论上看起来很酷，但在将概念投入生产时面临挑战 ## 3、它只是……还不够好（还） 随着我们进一步进展，唯一真正的问题是答案只是不够……好。我们不断调整一个长提示，这有时会导致不可预测的行为：有时 Ollama（在那时我们把它当作一个活着的实体）会忽略一半的配置，有时它会过度关注一种对象类型而忘记其他所有东西。这就是我读到关于 **提示链接** 的地方，这是一种将复杂任务分解为多个顺序提示的技术，将一个阶段的输出传递到下一个阶段，而不是试图将所有内容放入一个巨大的指令块中。为什么这很重要？ > 上下文窗口限制 由于我们仍然试图将所有内容放入一个提示中，我遇到了上下文窗口限制。LLM 的上下文窗口，本质上就是模型的"工作记忆"，决定了它一次可以处理多少信息。它可能非常大（截至 2026 年 2 月，Google 的 Gemini 1.5 Pro 提供 200 万令牌的上下文窗口）。有趣的是，这种规模引入了其他约束，并不意味着自动获得更好的推理。更大的上下文窗口需要显著更多的计算能力，同时仍然失去连贯性，并难以处理任务优先级 提示链接开始有意义的地方。不再试图将所有指令强制放入一个勉强能放入上下文窗口的巨大提示中，我们可以将推理分解为更小的步骤。每个提示将处理一个特定任务，并将结构化输出传递到下一个，有效地解决上下文限制而不是不断与之斗争 即使使用链接，我们仍然不得不增加上下文窗口大小（Ollama 的默认值是每个提示 4096 个令牌，记住，包括输入、输出和系统指令，这还不够）到 12,228（这是没有让我的笔记本电脑冻结的数字）。但现在，不是一个过载的提示，我们可以有多个相互链接的提示，每个都在可管理的上下文边界内操作 > 你可以在 Ollama 中查找 Modelfiles，它允许你调整参数，如上下文窗口大小和微调那里的模型\* ## 4、工作流程扩展 所以现在工作流程被分解为 5 个阶段： - 生成我们要升级的版本之间的一般更改列表 - 为每个对象生成特定更改的列表（这是后来添加的，因为"一般"更改太一般） - 上传配置 - 将每个对象与一般更改和对象特定更改进行比较 - 生成关于每个对象需要关注哪些更改的建议 在这一点上，我们从 1 次调用到 3 次（当我们在流程中有 3 个阶段时有一个中间阶段），整个分析大约需要 30 次调用。我实现了一个算法，无论配置多大，都按对象过滤它并将其分块，以便它与所有比较信息一起放入上下文窗口（这就是为什么调用数量增加；虽然我怀疑即使有更大的上下文窗口它也不会有多大帮助，某种形式的过滤和分块对于 Ollama 不在路上的某处产生幻觉仍然是必要的） 这就是我认为术语"黑盒子"在 LLM 上下文中真正开始有意义的地方。作为用户，我们通常不会考虑为了产生结果而在后台发生的事情，既在使用的术语方面，也关于输出是如何生成的（尽管后者对开发人员来说仍然有些不清楚） ## 5、Bob 比较 现在，几个月后，关于 IBM Bob 的讨论开始流传，IBM 的 AI 驱动开发助手，它可以在盒子之外做同样的工作（大部分）。我们决定运行三个比较：AI 升级分析工具、Bob 和一名 SME，并将它们发送给客户，询问他们更喜欢哪一个，而不透露哪一个是哪一个是哪个 这里的结果相当可预测，在我看来：Bob 赢了（有趣的是，当我们要求 Bob 选择最佳分析时，他选择了自己，显然）。当你考虑它时，这是有道理的 Bob 已经在 IBM 数据上进行了训练，并针对特定任务和请求进行了微调，具有对文档、模式和真实示例的内置熟悉程度。仅那个上下文就给了它一个强大的优势。然而，它仍然依赖于结构良好的提示，并且仍然需要使用接地数据进行额外的微调以减少幻觉并提高一致性 区别不是它没有局限性，而是那些局限性已经由一个团队管理，该团队的全职工作是改进它。构建和维护你自己的 AI 工具与使用整个团队支持的某种东西之间的权衡，在那个角度来看是一个相当可预测的结果 ## 6、结束语 公司正在迅速采用 AI 解决方案。问题不再是要使用 AI。更有趣（也更难）的问题是构建自己的东西是否有意义，还是依赖外部解决方案。维护内部 AI 解决方案结果比我最初预期的要复杂得多，因为它很快就变得清楚，这不仅仅是关于"调用模型"并得到答案回来，而是关于设计并持续维护它周围的整个系统。模型本身只是一个组件，围绕它的一切，检索逻辑、提示结构、上下文管理、编排、基础设施，都必须随之发展 同时，我不会说构建自己的工具是错误的方法，我认为这样构架它是不公平的。拥有自己的系统有一些根本价值 当你自己构建时，你不依赖于供应商关于哪些模型被弃用或替换、它在什么数据上受过训练（以及它有多最新）或幕后发生了什么变化的决定。如果你设法让它与开源模型可靠地工作，它甚至可以在长期内变得更具成本效益。你选择何时升级，你定义检索如何工作，你理解每一个设计决定，因为是你自己做的。有一个透明度和灵活性的水平，你在使用托管服务时根本无法获得 另一方面，使用像 Bob 这样的东西意味着我们受益于已经完成的大量工作。Bob 已经在 IBM 数据和内部文档上进行了训练，这实际上使它从第一天起就是微调后的 IBM 专家。这不是你可以轻易地在小项目中复制的东西，质量优势不仅仅是关于架构，而是关于累积的上下文和幕后维护 简单总结，它看起来像这样： ![None](https://www.hubwiz.com/blog/content/images/2026/02/1-rpS0FN1R5ELoUNgF79kSJg.png) 图 3：内部和托管 AI 解决方案之间的比较 如果你的目标只是以最少的额外工作实现尽可能最好的输出，那么对于使用一个已经由整个团队维护的成熟、良好支持的平台有一个强有力的案例。但如果你的目标是灵活性、独立性、长期的成本控制，以及真正理解表面之下发生了什么，那么构建自己的工具就变成了一条有趣的探索路径。 --- 原文链接: [Is building a custom AI assistant worth it?](https://medium.com/@margarita.lozyan/is-building-a-custom-ai-assistant-worth-it-7098b00eac3c?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处