企业官网建设流程全解析

使用生成式 AI 构建聊天应用：Generative AI for Beginners 第 7 课实战指南

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners

生成式 AI 驱动的聊天应用已成为客户服务、技术支持乃至专业咨询系统的核心组件。本文以generative-ai-for-beginners仓库中第 7 课（构建聊天应用）为骨架，系统讲解从集成 SDK/API、设计对话式用户体验，到领域定制微调与质量监控的完整链路。读完本文，你将掌握聊天机器人（Chatbot）与 AI 聊天应用的本质区别、三种主流服务（OpenAI / Azure OpenAI / Microsoft Foundry Models）的接入方式，以及用指标与责任 AI 六原则保障"高质量"聊天体验的实操方法。

引言：为什么需要专门的聊天应用方法论

在完成文本生成应用的构建之后，聊天应用带来了新的复杂度。它不只是把 prompt 丢给模型，而是涉及三大核心问题：

• 构建（Building）：如何针对特定业务场景高效构建并无缝集成这些 AI 应用？
• 监控（Monitoring）：应用上线后，如何确保其在功能与责任 AI 六原则上始终保持高质量运行？

本文对应的学习路径是：先掌握高效构建与集成聊天应用的技术；再学习如何对应用施加定制（DSL）与微调（Fine-tuning）；最后掌握有效监控聊天应用质量的策略与指标。

生成式 AI 如何融入聊天应用

将生成式 AI 融入聊天应用，不只是"让它变聪明"，而是要在架构、性能与用户界面上整体优化，以交付高质量体验。无论你是将 AI 接入现有系统，还是构建独立平台，都需要同时审视架构基础、API 集成与界面设计三个层面。

聊天机器人（Chatbot）与 AI 聊天应用的本质区别

动手前必须先分清两个概念。聊天机器人的核心目标是自动化特定对话任务——比如回答常见问题、跟踪包裹，通常由规则逻辑或复杂 AI 算法驱动；而 AI 驱动的聊天应用是一个更广阔的环境，用于承载文本、语音、视频等多种数字沟通形式，其标志性特征是集成生成式 AI 模型，能基于多样化输入与上下文线索模拟类人对话、参与开放域讨论、适应不断演进的对话语境，甚至生成有创造性的复杂对白。

用 SDK 与 API 复用既有能力：第一优先级

构建聊天应用的第一步是评估"已经存在的东西"。接入文档完善的 SDK 与 API 是极具优势的策略，它能把应用战略性地置于长期成功的位置，同时解决扩展性与维护性顾虑：

• 加速开发、降低开销：复用现成能力，让你把精力投入到业务逻辑等更重要的部分，而非从零重复造轮子。
• 更好的性能：从零实现时你迟早会问"它能扛住用户激增吗？"，而维护良好的 SDK/API 通常内置了这些扩展性解决方案。
• 易于维护：大多数 API/SDK 在新版本发布时只需升级依赖库即可获得更新与改进。
• 触达前沿技术：直接利用在海量数据上微调训练过的模型，为应用赋予自然语言能力。

访问 SDK/API 能力通常需要获得使用许可，一般通过唯一 Key 或认证令牌完成。原文档给出了 OpenAI Python 库的示例（基于gpt-3.5-turbo的 Chat Completions），而当前仓库的作业 notebook 已升级为gpt-4o-mini与 Responses API，以下是仓库 OpenAI 作业 notebook 中的实际调用形态：

import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() API_KEY = os.getenv("OPENAI_API_KEY","") assert API_KEY, "ERROR: OpenAI Key is missing" client = OpenAI( api_key=API_KEY ) # Select a general purpose chat model model = "gpt-4o-mini" # Create your first prompt text_prompt = "Should oxford commas always be used?" response = client.responses.create( model=model, input = [{"role":"system", "content":"You are a helpful assistant."}, {"role":"user","content":text_prompt},], store=False,) response.output_text

注意上述代码通过os.getenv读取环境变量、并用assert显式校验 Key 是否存在——未设置 Key 会直接报错，这正是原文档强调的"API key 必须预先配置"的工程化落地。

仓库还提供了另外两种等效接入方式：

• Azure OpenAI 服务（aoai-assignment.ipynb）：客户端通过AZURE_OPENAI_ENDPOINT指向<endpoint>/openai/v1/端点，模型名取自环境变量AZURE_OPENAI_DEPLOYMENT；
• Microsoft Foundry Models（原 GitHub Models）（githubmodels-assignment.ipynb）：改用azure-ai-inference包，通过AZURE_INFERENCE_CREDENTIAL与AZURE_INFERENCE_ENDPOINT环境变量实例化ChatCompletionsClient，再以client.complete(model=..., messages=[...])发起请求。

如果你偏爱其他语言，仓库同样提供了 JavaScript 版本（基于@azure-rest/ai-inference的 ModelClient）与 TypeScript 版本，两者都演示了携带system+user多角色消息的完整调用链。TypeScript 示例还展示了控制生成长度的参数max_output_tokens: 100与store: false，可作为调用参数参考。

用户界面（UX）：机器学习组件带来的额外设计考量

通用 UX 原则同样适用于聊天应用，但由于涉及机器学习组件，以下考量变得格外重要：

• 处理歧义的机制：生成式 AI 模型偶尔会产出含糊的答案，提供"请澄清"的能力对用户非常有用。
• 上下文保留（Context Retention）：先进的生成式模型能记忆对话上下文，这是提升体验的宝贵资产。让用户能够控制、管理上下文可以改善体验，但也引入了敏感信息留存的风险——必须考虑信息保留时长（例如引入保留策略），在上下文需求与隐私之间取得平衡。
• 个性化（Personalization）：具备学习与适应能力的 AI 模型能为用户提供个性化体验，通过用户画像等特性定制体验，让用户感到被理解，并更快找到特定答案，形成更高效、更令人满意的交互。

OpenAI ChatGPT 中的"自定义指令（Custom instructions）"就是个性化的典型例子——它允许你提供对 prompt 而言重要的背景信息：

这份"画像"促使 ChatGPT 生成一份关于链表的课程计划。注意 ChatGPT 会结合用户的使用经历，推断出用户可能想要更深入的课程计划：

Microsoft 大语言模型系统消息框架

Microsoft 将"如何为 LLM 写出有效系统消息"归纳为 4 个领域：

1. 定义模型的受众、能力与局限；
2. 定义模型的输出格式；
3. 提供能展示模型预期行为的具体示例；
4. 提供额外的行为护栏（guardrails）。

在仓库的 JS 示例 中可以看到系统消息的实际用法——通过连续两条system消息（"你是法国总统"、"你刚刚辞职"）为对话设定角色与情境，再以user消息提问，这正是"定义模型身份与行为"的直观体现。

可访问性：让所有用户都能使用

无论用户是否有视觉、听觉、运动或认知障碍，设计良好的聊天应用都应人人可用：

• 面向视觉障碍：高对比度主题、可缩放文本、屏幕阅读器兼容；
• 面向听觉障碍：文本转语音与语音转文本功能、音频通知的视觉提示；
• 面向运动障碍：键盘导航支持、语音命令；
• 面向认知障碍：简化语言选项。

领域专属语言模型的定制与微调

设想一个能听懂公司行话、并能预判用户群体常见问题的聊天应用。这背后有两条值得关注的路径：

• 利用 DSL 模型：DSL 指领域特定语言（Domain Specific Language），可以调用针对特定领域训练过的模型来理解其概念与场景；
• 应用微调（Fine-tuning）：用特定数据对模型进行进一步训练的过程。

定制方案一：使用 DSL 模型

领域特定语言模型通过提供专业化、语境相关的交互来提升用户参与度。它是经过训练或微调、能够理解并生成某个领域/行业/学科文本的模型。使用 DSL 模型的选择从"从零训练"到"通过 SDK/API 使用现成模型"各不相同，微调则是对既有预训练模型做领域适配的另一种选项。

定制方案二：应用微调

当预训练模型在专业领域或特定任务上表现不足时，就应考虑微调。以医疗场景为例：医疗问题复杂且需要大量上下文，专业医生诊断患者时依赖生活方式、既有病史等多种因素，甚至要参考最新医学期刊来验证诊断——在这种微妙场景下，通用 AI 聊天应用无法成为可靠的信息来源。

场景：医疗应用

假设要为医疗从业者设计一款聊天应用，用于快速查阅治疗指南、药物相互作用或最新研究结论：

通用模型回答基础医疗问题、给出一般性建议或许足够，但会在以下方面力不从心：

• 高度特定或复杂的病例：例如神经科医生询问"儿童患者耐药性癫痫管理的最新最佳实践是什么？"；
• 缺乏最新进展：通用模型难以提供融合神经学与药理学最新进展的当前答案。

这类情况下，用专业医疗数据集微调模型，能显著提升其准确、可靠地处理复杂医疗询问的能力——前提是能够获得代表领域挑战与问题的、大规模且相关的数据集。

打造高质量 AI 聊天体验：指标与责任 AI

"高质量"聊天应用的标准包括：捕获可操作的指标，并遵守负责任地使用 AI 技术的框架。

关键指标：衡量质量与体验

要维持应用的高质量表现，持续追踪关键指标必不可少。它们不仅确保应用功能正常，也用于评估 AI 模型质量与用户体验。下表覆盖基础、AI 与用户体验三类指标：

聊天应用中的责任 AI 实践

Microsoft 的责任 AI 方法确立了指导 AI 开发与使用的六项原则。下表给出原则、定义、聊天开发者应考量的要点，以及严肃对待它们的理由：

动手实践：仓库配套作业与多语言实现

原文档建议从"运行第一个聊天 prompt"出发，依次完成文本分类、摘要等系列练习，并强调作业提供了多种编程语言版本。具体入口如下：

• Python 作业：OpenAI 版、Azure OpenAI 版、Microsoft Foundry Models 版，以及对应的"简化版"（*-simple.ipynb）；
• JavaScript 作业：js-githubmodels/app.js；
• TypeScript 作业：chat-completions-app/src/main.ts。

作业覆盖的典型用例包括：文本摘要（在 prompt 末尾追加tl;dr触发模型提炼要点）、文本分类（在 prompt 中给出候选类别如[Pricing, Hardware Support, Software Support]后让模型归类）、以及生成新产品名（给出产品描述与种子词，配合提高 temperature 增加创意输出）。值得注意的是仓库 notebook 特意安排"对同一 prompt 重复调用"的环节，让读者直观感受生成式模型的非确定性——这也侧面印证了"质量监控指标"章节的必要性：同样的输入并不保证同样的输出，正因如此，响应时间、错误率与异常检测等运维指标才至关重要。

完成本课之后，可以继续进入第 8 课，学习构建搜索应用，把聊天能力与检索增强能力结合起来。

适用前提说明：本文涉及的环境变量（OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT、AZURE_INFERENCE_CREDENTIAL等）均需读者在各自服务控制台申请；gpt-4o-mini、gpt-3.5-turbo等模型名以仓库 notebook 当前配置为准，实际运行时以你所使用的服务目录中可用的部署名为准。

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners