在开发内部Copilot的过程中，我们克服了重重困难，也推动了我们对 GenAI 潜力的认知边界。
译自 Building an Extensible GenAI Copilot: What We Learned，作者 Rajat Tiwari。
我们的 生成式 AI (GenAI) 之旅始于一个简单的用例：如何让我们的客户更容易地浏览我们平台中庞大的文档和功能？
对于我们的用户来说，能够快速访问和理解他们使用我们的企业平台所需的产品信息至关重要。因此，我们的产品团队要求我们的开发团队开发一个解决方案来简化此过程并增强整体用户体验。
几个月前，我们推出了 Rafay Copilot，一个由 GenAI 驱动的机器人，旨在实现这一目标。这绝非易事。在构建 Copilot 时，我们遇到了许多障碍——从克服 AI 领域的陡峭学习曲线到确保响应的准确性和与我们现有系统的无缝集成。这些障碍迫使我们重新思考和改进我们的方法，突破了我们对 GenAI 可能性的认知。
然而，这些挑战为我们提供了宝贵的见解。当我们努力克服创建 Rafay Copilot 的复杂性时，我们开始看到 Gen AI 的更广泛潜力。我们解决的问题和取得的突破让我们意识到，我们开发的东西可以扩展到其最初范围之外，并应用于我们平台的其他领域。
定义Copilot架构
GenAI 有可能应用于我们产品中的许多用例，因此在定义 Rafay Copilot 架构时，一个主要目标是确保它可以轻松扩展以支持其他用例。这种架构应该灵活且可扩展，以支持更高级的用例，例如代理或其他类型的Copilot。
我们使用 LangChain 框架来链接请求，然后再将它们发送到 大型语言模型 (LLM)。Qdrant 充当我们的向量数据库，有效地存储和检索文本嵌入。为了监控系统的行为和性能，我们依赖 Langfuse，它帮助我们有效地跟踪成本和调试 AI 服务。
检索增强生成 (RAG) 允许聊天机器人访问和检索特定私有数据，例如公司文档或专有知识，以提供更准确和上下文相关的响应。Langfuse 是我们用于监控和调试 AI 应用程序的 可观测性 平台。
LangGraph 虽然目前尚未实施，但有可能用于创建更复杂的多步骤 AI 工作流。LangSmith 是 LangChain 生态系统中的另一个工具，它为 LLM 应用程序提供调试和测试功能，我们可能会在未来的迭代中探索它。
API 网关和 AI 服务层
所有传入 Rafay Copilot 的请求都通过一个集中式 API 网关，我们称之为 rafay-hub。该网关的主要职责是处理身份验证并标准化我们上游服务的 API 请求，确保只有授权用户才能访问系统。一旦经过身份验证和标准化，请求将被转发到 AI 服务，它是我们所有代理的代理。
AI 服务的主要作用是决定哪个代理服务应该处理请求。我们设计了它，以便我们将来可以轻松地扩展系统。例如，我们有一个专门用于与 OpenAI 的 API 交互的代理服务，用于我们的 GenAI 聊天机器人。但是，此层的模块化设计允许我们根据需要添加新的代理，无论它们涉及其他生成式 AI 模型还是完全不同类型的 AI 服务。
代理服务和 LLM 集成
一旦 AI 服务确定了合适的代理，请求将被发送到相应的代理服务。该代理直接与底层的 LLM 交互。指导这些交互的提示存储在 Kubernetes (K8s) 配置映射中，这使我们能够根据系统性能或用户反馈快速调整它们。这种配置驱动的方案使快速迭代和微调成为可能，确保我们的聊天机器人为用户提供最佳的响应。
向量数据库和可观测性
为了从我们的文档中提供准确和最新的信息，我们实施了一个 Kubernetes cron 作业，该作业定期从我们的 GitHub 存储库中提取数据，所有文档都以 Markdown 格式存储在那里。该作业处理数据并将其存储在我们的向量数据库 Qdrant 中，使聊天机器人能够快速轻松地检索相关信息。
为了可观测性，我们将 Langfuse 集成到代理服务中作为回调。这种集成使我们能够实时监控系统，提供与 Copilot 交互时的成本、响应和客户反馈的洞察。
总之，Rafay Copilot 架构经过精心设计，以满足我们用户不断变化的需求。它专注于灵活性和可扩展性，并易于未来扩展。
克服挑战
尽管上面的架构图可能使该过程看起来很简单，但在构建 Rafay Copilot 时，我们遇到了多个障碍。开发带来了重大挑战，我在下面列出了这些挑战，以便您更清楚地了解情况。
- 陡峭的学习曲线：对于任何开始其 AI 之旅的组织来说，了解 AI 领域都存在一个陡峭的学习曲线。
- 评估 LLM 选项：随着生成式 AI 的兴起，有大量 LLM 可用，包括来自云提供商和开源社区的 LLM。决定哪种 LLM 最适合您的业务具有挑战性，做出错误的选择会严重影响您的结果。
- 治理：
- 成本管理：由于 GenAI 应用程序根据令牌使用情况收费，因此必须制定治理措施来监控和控制成本。管理员需要能够在每天、每周或每月为用户或团队分配令牌限制。
- 护栏：安全是另一个关键方面。在与 LLM 交互时，尤其是基于云的 LLM，用户无意中泄露敏感数据的风险始终存在。
- 密钥管理：在企业环境中管理 API 密钥可能很复杂，尤其是在涉及多个用户的情况下。需要一个网关来安全地处理此问题。
- 访问管理：在使用多个模型的组织中，适当的访问管理至关重要，以便管理员可以控制谁可以访问哪些模型以及哪些数据集。
- 提示评估：与 LLM 评估类似，提示评估对于 AI 应用程序的成功至关重要。即使是措辞的细微变化也会导致完全不同的响应，这使得这项任务至关重要但也具有挑战性。
- 可观测性：与任何生产就绪的应用程序一样，AI 应用程序需要强大的可观测性。将 LangSmith、Langfuse 和 LangGraph 等工具集成到 GenAI 应用程序中需要时间和精力，更不用说站点可靠性工程 (SRE) 团队所需的持续维护了。
结论
构建 GenAI 应用程序可能听起来很简单，因为目前有大量开发工具和框架可用。这可能适用于早期实验阶段。
但是，构建企业级 GenAI 应用程序并在生产环境中部署它们存在许多挑战，包括找到合适的 LLM、管理成本、制定数据访问控制、部署提示护栏和维护可观测性。我们利用从构建 Rafay Copilot 中获得的见解来开发 GenAI Playgrounds，这是一个用于开发人员快速原型设计和构建 GenAI 应用程序的集成开发环境 (IDE)。您可以在 Rafay 的网站上免费试用。
企业平台团队必须仔细考虑所有安全、数据和成本相关的因素，并采用企业级策略来解决这些挑战，然后才能在组织中广泛采用 Gen AI。建议企业平台团队构建内部解决方案或使用商业工具来解决这些挑战，并加速 GenAI 应用程序的开发和部署。
