用亚马逊云科技 Bedrock 从零到一，打造一个“懂我”的 AI Chatbot 🤖

大型语言模型（LLM）的发展势头迅猛，以至于在技术圈，如果不涉足一些人工智能（AI）应用，似乎就有些跟不上时代。许多开发者都渴望构建一个能够智能对话的 AI 助手。然而，当打开亚马逊云科技（Amazon Web Services）的 Amazon Bedrock 服务页面时，开发者往往会面临一个普遍的难题：Claude、Llama、Cohere、Mistral 等众多顶尖模型陈列在前，总数超过百个，令人眼花缭乱。这种“选择的悖论”常常导致决策瘫痪：应该如何选择？错误的选择不仅会浪费宝贵的开发时间，甚至可能导致项目偏离预期目标。

这次实践的核心平台是 Amazon Bedrock。可以将它理解为一个庞大的“模型超市”，集中了来自 AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI 等顶级 AI 公司以及亚马逊自家 Titan 系列的多种基础模型（Foundation Models, FMs）。其核心价值不仅在于提供模型访问权限，更在于它作为一个统一的、托管式的平台，极大地简化了模型选型、集成和管理的复杂性。开发者无需逐一向各家公司申请 API 和管理多个账户，而是在一个统一的环境中，就能让所有顶尖模型同台竞技，从而有效解决了“选择困难症”这一核心痛点。

谋定而后动 - 给我们的 Chatbot 立个 Flag 🤔

在编写任何代码之前，首要任务是为项目设定清晰、可量化的目标，即“验收标准”。没有明确的目标，开发过程很容易偏离方向，最终产出的应用也可能无法满足实际需求。一个成功的生成式 AI 应用，其背后必然有一套深思熟虑的工程权衡。

对于构建 Chatbot 而言，可以从以下三个核心维度来确立目标，这三个维度共同构成了一个适用于几乎所有生成式 AI 项目的通用评估框架：

• 速度 (Latency): 响应速度是用户体验的基石。如果用户提出一个问题后需要长时间等待，体验将大打折扣。因此，一个明确的性能指标是必要的，例如，服务等级协议（SLA）要求响应时间必须在 1.5 秒以内。
• 成本 (Cost): 成本控制对于任何项目都至关重要，尤其是对于个人项目或概念验证（POC）阶段。为了避免预算超支，优先考虑“按需付费”（Pay-As-You-Go, PAYG）的无服务器（Serverless）部署模式是一种明智的策略。这种模式下，只有在实际使用时才会产生费用，非常适合流量不高的初期阶段。
• 质量 (Quality): 这是三个维度中最为核心也最复杂的一环。一个高质量的 Chatbot 必须能够提供准确的回答，而不是产生“幻觉”（一本正经地胡说八道）。一个可量化的目标是，答案的准确率至少要达到 80%。此外，质量还包括非功能性需求，比如，对话的语气应该是轻松、具有知识性，而非冷冰冰的机器语言。

“质量”的评估本身就是一个多维度的挑战。一个“好”的回答需要从多个角度来审视：内容是否事实正确？信息是否全面？逻辑是否清晰连贯？是否存在偏见或有害内容？语气是否符合预设的风格？。这些问题正是后续模型深度评测阶段需要重点解决的。理解并平衡这三者之间的关系——速度、成本与质量——是启动任何 AI 项目前的必备功课，它决定了项目的技术选型和最终成败。

大海捞针 - 在亚马逊云科技 Bedrock 上搞一场“模型选秀” 🏆

目标明确之后，接下来的任务就是从 Amazon Bedrock 提供的一百多个模型中，筛选出最具潜力的候选者。这个过程可以被设计成一个逻辑清晰的漏斗，通过逐层过滤来缩小选择范围。

以下是一个四步筛选策略的实践，它能有效地将庞大的模型库精简到一个可管理的候选名单 ：

• 第一层筛选：看“专业” (Filter 1: Specialization): 项目目标是构建一个聊天机器人，因此首先需要排除那些专用于图像生成、音乐创作等非文本对话功能的模型。筛选条件设置为“仅文本/聊天模型”（Only Text/chat models）。这一步可以将候选范围大幅缩小。
  • 候选人数量：114 → 32。
• 第二层筛选：看“身价” (Filter 2: Cost Model): 根据前述的成本控制原则，选择符合预算的部署模式。筛选条件为“仅无服务器/按需付费”（Serverless/PAYG）。
  • 候选人数量：32 → 19。
• 第三层筛选：看“年龄” (Filter 3: Recency): AI 技术迭代迅速，较新的模型通常在性能、效率和功能上都有更佳表现。因此，筛选时应优先考虑最新的模型。
  • 候选人数量：19 → 6。
• 第四层筛选：看“情商” (Filter 4: Optimization): 一个优秀的 Chatbot 需要具备良好的对话能力，能够理解上下文、对话流程和沟通礼仪。因此，最后一层筛选标准是选择那些“为聊天优化的 LLM”（Chat-optimized LLMs）。
  • 候选人数量：6 → 4。

经过这四轮的系统性筛选，最初庞大的模型列表变得清晰明了。最终，有四位“选手”脱颖而出，成功进入下一轮的深度“面试”环节。

是骡子是马，拉出来遛遛 - 模型深度横评 🔬

筛选出决赛圈的选手后，接下来的问题是如何对它们进行公平、高效的比较。简单地在多个终端窗口中手动输入相同问题进行测试，不仅效率低下，而且难以进行直观的横向对比。为了实现专业、系统的评估，需要一个专门的“比武场”。

AWS Marketplace 上提供了一个名为 Datasaur LLM Labs 的第三方工具，它支持免费试用，能够让开发者在一个统一的界面中方便地并排比较多个 LLM 的性能表现，是执行深度横评的理想选择。评估过程可以分为两个阶段：定性手动评估和定量自动评估。

第一阶段：主观感受测试 (定性/手动评估)

这个阶段的目标是凭直观感受，评估模型在真实对话场景中的表现。

1. 搭建测试环境： 首先，在 Datasaur 控制台中创建一个“沙盒”（Sandbox），然后将筛选出的四个候选模型（如 Claude 3 Sonnet 等）作为四个独立的“应用”（Application）添加进去。

1. 配置模型参数： 为每个模型应用配置“超参数”（Hyperparameters），例如调整 temperature 来控制回答的创造性或严谨性。在初期测试中，可以先使用默认配置。
2. 进行并排测试： 最核心的功能在于，开发者可以在一个界面中编写一个提示（Prompt），然后一键发送给所有四个模型。它们的回答会并排显示出来，优劣一目了然。

在这个阶段，评估的重点在于主观感受，观察哪个模型的回答更流畅、相关性更高、逻辑更清晰，以及语气是否符合预设要求。例如，可以测试模型对复杂问题的理解能力，或者通过连续提问来检验其上下文记忆能力。

第二阶段：客观指标测试 (定量/自动评估)

主观感受虽然重要，但决策不能仅凭感觉。为了做出更科学的选择，需要引入客观的数据指标。自动化评估能够为每个模型生成一份量化的“成绩单”。

1. 选择评估指标： 业界存在一些公认的评估器，可以用来对模型的输出进行打分。以下是四个关键的评估指标，它们从不同维度衡量模型的质量 ：
   1. Langchain – Answer Correctness (答案正确性): 负责评估回答内容的“事实准确性”，并给出一个 1 到 10 的分数，分数越高代表越可靠。
   2. Deepeval’s Answer relevance (答案相关性): 用于判断回答是否“答非所问”，确保输出与输入问题高度相关。
   3. Deepeval’s Bias (偏见): 检查回答中是否存在基于性别、种族等方面的偏见内容，这对于维护品牌安全至关重要。
   4. Deepeval’s Toxicity (毒性): 检测回答中是否包含攻击性、不健康或有害的语言。
2. 这些指标不仅仅是技术分数，它们直接关联到最终产品的商业风险和用户信任度。例如，“答案正确性”和“相关性”低会导致用户流失，而“偏见”和“毒性”高则可能引发严重的公关危机，损害品牌声誉。因此，自动化评估本质上是一种在产品上线前进行风险管理和质量保证的关键流程。
3. 执行自动评估： 准备一个包含各种典型或刁钻问题的小型问答数据集，并将其上传。随后，在 Datasaur 中启动自动化评估流程，让上述几位“考官”为四个候选模型打分。
4. 分析评估结果： 评估完成后，系统会生成一份详细的报告，清晰地展示每个模型在“准确性”、“相关性”等多个维度上的得分情况。
5. 深入分析： 平台最强大的功能之一是允许开发者深入查看每一个问题的具体得分以及详细的“判分理由”。这对于理解模型的优势和短板、并进行针对性优化非常有价值。

通过结合定性与定量两阶段的评估，开发者可以获得对候选模型的全面认知，从而做出数据驱动的、最符合项目需求的选择。

不止于闲聊 - 给 Chatbot 装上一个“专属知识大脑” 🧠

经过前述的严格横评，开发者可以选出综合表现最佳的模型。然而，这个模型依然存在一个固有的局限性：它通晓天下事，却对特定领域的“私有知识”一无所知。例如，如果询问关于某家公司的内部产品手册或最新的财务数据，它将无法提供准确答案。

要解决这个问题，需要为模型“外挂”一个专属的知识库。实现这一目标的核心技术被称为检索增强生成（Retrieval-Augmented Generation, RAG） 。其工作原理可以通俗地理解为：当用户提问时，系统首先从开发者提供的私有资料库（如公司文档、产品 FAQ、PDF 文件等）中检索最相关的信息片段，然后将这些信息片段与用户的原始问题一起组合成一个更丰富的提示，最后将这个组合后的提示“喂”给大模型，让它基于这些给定的上下文来生成回答。

在过去，实施 RAG 是一个复杂且繁琐的工程任务，需要开发者自行处理文档解析与切片、文本向量化（Embeddings）、搭建和维护向量数据库（Vector Database）以及编写复杂的检索与排序逻辑。然而，亚马逊云科技通过 Knowledge Bases for Amazon Bedrock 这项全托管服务，将这些繁重的“脏活累活”全部自动化了。

这项服务极大地降低了构建企业级、上下文感知 AI 应用的技术门槛。过去需要一个专业机器学习团队才能完成的工作，现在单个开发者也能轻松实现。这不仅仅是一项便利的功能，更是一次技术的“民主化”，它将强大的 AI 能力交到了更多开发者手中，从而加速创新。

使用 Knowledge Bases for Amazon Bedrock 的流程非常简单 ：

1. 数据注入 (Ingestion): 开发者只需将自己的文档（如 PDF、Word、HTML 等格式）上传到 Amazon S3 存储桶。然后，通过调用 StartIngestionJob API，Bedrock 就会自动启动数据处理流水线。它会使用内置的 Amazon Titan Embedding 模型将文档内容分割成块（chunks），并将每一块转换为向量表示，最后将这些向量存入一个完全托管的向量索引中。
2. 检索与生成 (Retrieval & Generation): 当 Chatbot 收到用户提问时，开发者只需调用一次 RetrieveAndGenerate API。该 API 会在后台自动完成所有工作：将用户的问题转换为向量，在向量数据库中进行相似性搜索以找到最相关的文档片段，将这些片段与原始问题智能地组合成一个优化的提示，并调用选定的大模型来生成最终答案。
3. 引用与溯源 (Attribution): 该服务一个非常贴心的设计是，生成的答案会自动附带“引用来源”。它会明确指出信息源自哪个文档的哪个部分，这不仅极大地减少了模型产生“幻觉”的风险，也显著增强了回答的可信度和透明度。

让你的 Chatbot 掌握多国语言！👋

现在，我们的 Chatbot 不仅聪明，还拥有了专属领域的知识。但如果应用需要面向全球用户，他们可能会使用中文、英文、日文、印尼语等多种语言进行交流，这时该怎么办？为每一种语言都构建和维护一个独立的知识库和模型显然是不现实的。

这正是亚马逊云科技生态系统强大之处的体现。开发者可以像搭乐高积木一样，将多个 AWS 服务组合起来，轻松实现强大的多语言支持功能。以下是一个基于 中描述的架构蓝图，它展示了如何通过组合服务来构建一个多语言 Chatbot：

1. 语言侦测 (Language Detection): 当用户使用任何语言发起提问时，第一步是将问题发送给 Amazon Comprehend 服务。该服务能够实时、准确地识别出用户所使用的主导语言（例如，识别出是印尼语或中文）。
2. （可选）翻译问题 (Optional: Translate Query): 如果后台的知识库主要是用单一语言（例如英文）构建的，而用户的提问是另一种语言（例如中文），此时可以调用 Amazon Translate 服务，在后台将用户的中文问题无缝翻译成英文。
3. 知识检索 (Knowledge Retrieval): 使用翻译后的英文问题，在第四部分中构建的 Knowledge Base for Amazon Bedrock 中执行检索操作。系统会找到与问题最相关的英文信息片段。
4. 生成答案 (Generate Answer): 这是最巧妙的一步。将上一步检索到的英文上下文信息，连同用户的“原始问题”（例如中文），一起发送给 Amazon Bedrock 中的大模型。同时，在提示中额外添加一条指令：“请使用问题的原始语言（即中文）来回答”。
5. 返回答案 (Return Response): 大模型会遵循指令，基于英文的上下文信息，生成一段流利、准确的中文回答。整个过程中，用户完全感受不到后台发生的语言识别和翻译操作，从而获得一种无缝、连贯的母语交流体验。

通过这种可组合的云原生架构，开发者无需对 Chatbot 的核心逻辑进行任何修改，仅仅通过集成 Amazon Comprehend 和 Amazon Translate 这两个“插件”，就为其赋予了强大的多语言能力，能够轻松应对来自不同国家和地区用户的需求。

以上就是本文的全部内容啦。最后提醒一下各位工友，如果后续不再使用相关服务，别忘了在控制台关闭，避免超出免费额度产生费用～