我们的内部文档分散在多个平台上。我们主要在 Confluence 中组织信息，将其划分为与特定领域（例如人力资源、IT、财务和产品）相对应的各种空间。除此之外，我们还使用 Google Drive 来满足额外的存储和文档需求，并经常在我们的 Confluence 页面中链接这些资源。对于内部沟通，Slack 是我们首选的平台，其中的众多渠道都包含可以重新利用或引用的宝贵知识。
意识到员工经常在 Slack 频
道中提出问题，我们发现可以通过集成 Slack 机器人来简化信息检索。该机器人将充当连接 Confluence 和 Google Drive 的接口，从而可以直接从 Slack 无缝访问内部知识库。
然而，我们面临着一个重大挑战：我们的知识数据高度非结构化，分散在不同的工具中。早期 秘鲁手机号码 评估表明，构建一个能够回答任何问题的基于检索增强生成 (RAG) 的广泛知识代理可能会产生次优结果。为了解决这个问题，我们将策略转向开发领域特定代理。这些代理专注于更窄的范围，在其专业领域内提供更准确、更可靠的答案。为了有效地管理查询，我们引入了一个路由代理，旨在对传入的问题进行分类并将其定向到适当的领域特定代理。
例如，Aircall 在法国、英国、西班牙、印度和美国等多个国家设有办事处。人力资源政策、员工福利和休假指南可能因地区而异。通过专注于这些特定用例，我们可以确保所提供的信息准确可靠，从而强化代理作为可靠事实来源的作用。
在为该项目选择技术架构时，我们的主要目标之一是使生成式 AI 在整个公司内普及使用。我们 快速连接 之所以选择Amazon Bedrock，是因为它的设置要求极低，且上手速度快。使用 Amazon Bedrock 的另一个优势是可以灵活地尝试多种基础模型。这使我们能够快速迭代自定义和配置，从而高效地微调性能。
构建代理
在构建我们的模型时，Claude 3.5 是 Bedrock 中最新的生成模型，并且也为我们提供了最佳性能，特别是在基于推理的问题上（例如，找出下一个假期，这需要模 WhatsApp 号码 型计算相对于当前日期的下一个假期）。我们对底层知识实施了语义分块，并使用了 OpenSearch 向量数据库。我们分别存储用户问题、响应和日志，以便进行调试、评估和架构比较。
实验与学习
1. 处理图像
我们意识到很多信息（尤其是技术文档）都是通过图像（例如建筑文档）捕获的。由于我们使用的矢量数据库不允许输入图像，因此我们决定使用另一个 LLM 来描述这些图像并将这些描述存储到我们的矢量数据库中。
由于 Amazon Bedrock 中提供的默认 Confluence 连接器默认不索引图像，因此我们决定切换到 S3 作为源。为此，我们构建了自己的Confluence 抓取工具，用于抓取 Confluence 数据并将其存储在 S3 中。
然而，我们的实验表明，当使用 LLM 翻译的图像数据作为源时，出现幻觉的概率会增加，并且我们希望我们的代理偏向准确性而不是覆盖率，因此，我们最终决定不使用图像输入进行矢量嵌入。