使用生成式 AI 构建聊天应用：从架构设计、SDK 集成到监控与负责任的 AI 实践
【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners
本指南基于 generative-ai-for-beginners 课程第 7 课，系统讲解如何将生成式 AI 集成到聊天应用中：从「聊天机器人 vs AI 聊天应用」的架构定位、借助 SDK/API 快速接入大模型，到用户体验（UX）设计、领域定制（DSL 与微调）、关键质量指标监控，以及 Microsoft 负责任的 AI 六原则落地。读完本文，你将掌握一套可复制、可运行的聊天应用构建与维护方案，并能直接在本仓库的 Python / TypeScript / JavaScript 示例与作业 Notebook 中动手验证。
引言：为什么聊天应用需要生成式 AI
聊天应用早已融入日常生活，它不只是休闲对话的载体，更是客户服务、技术支持乃至复杂咨询系统的重要组成部分。当把生成式 AI 这样的先进技术集成进这些平台时，系统的复杂度与挑战也随之上升。围绕构建与运维，有两个核心问题必须回答：
- 构建应用：如何针对特定使用场景高效地构建并无缝集成 AI 驱动的应用？
- 监控应用：部署之后，如何监控并确保应用在功能层面和遵循负责任的 AI 六项原则的层面都保持最高质量水准？
本章节将探讨支撑这类复杂系统的架构要素、针对领域任务进行定制与微调的方法论，以及确保负责任地部署 AI 所必需的指标与考量。
学习目标
完成本课学习后，你将能够：
- 描述将聊天应用构建并集成进现有系统时的关键考量；
- 针对特定使用场景定制（customize）聊天应用；
- 识别有效监控与维护 AI 聊天应用质量的关键指标；
- 确保聊天应用负责任地使用 AI。
集成生成式 AI：聊天机器人与聊天应用的架构定位
用生成式 AI 提升聊天应用，不只是让它们"更聪明"，更是围绕架构、性能与用户界面进行整体优化，以交付高质量的用户体验。这涉及架构基础、API 集成与界面设计三个层面，无论你是把能力插入现有系统，还是从零搭建独立平台，本节都提供一份完整路线图。
聊天机器人还是聊天应用？
在动手之前，先厘清两个经常被混用的概念：「聊天机器人（chatbot）」与「AI 驱动的聊天应用（AI-powered chat application）」，它们承担着截然不同的角色与功能。
- 聊天机器人的核心目标是自动化特定对话任务，例如回答常见问题（FAQ）或跟踪包裹物流。它通常由基于规则（rule-based）的逻辑或复杂 AI 算法驱动。
- AI 驱动的聊天应用则是一个更为广阔的交互环境，用于承载人类用户之间多种形式的数字通信（文本、语音、视频）。其标志性特征是集成了生成式 AI 模型——根据各种输入与上下文线索生成细腻、近似人类语言的回复。它能够参与开放域对话、适应不断演变的对话上下文，甚至产出有创意的复杂对话。
下表从四个维度对比两者的差异，便于理解它们在数字通信中的独特定位：
| 聊天机器人 | 生成式 AI 驱动的聊天应用 |
|---|---|
| 面向任务、基于规则 | 具备上下文感知能力 |
| 常被集成进更大的系统 | 可能承载一个或多个聊天机器人 |
| 局限于预设功能 | 内置生成式 AI 模型 |
| 专精化、结构化的交互 | 可进行开放域讨论 |
用 SDK 与 API 复用现成能力
构建聊天应用时，明智的第一步是评估市面上已有的能力。使用 SDK 与 API 构建聊天应用是极具优势的战略选择，将应用定位在长期可扩展、可维护的轨道上：
- 加速开发、降低开销：依赖现成功能而非昂贵的自研，让你能把精力放在更重要的部分（如业务逻辑）上；
- 更好的性能：从零构建功能时迟早要问"它能撑住多少并发？突然涌入大量用户怎么办？"——维护良好的 SDK/API 通常内置了这些问题的解决方案；
- 更易维护：大多数 API/SDK 在发布新版本时只需升级对应库即可获得更新与改进；
- 接触前沿技术：复用经过大规模数据集训练与微调的模型，等于为应用直接注入自然语言处理能力。
调用 SDK/API 功能通常需要获得服务使用许可，最常见的形式是唯一的密钥或认证令牌。下面以 OpenAI Python 库为例展示这一过程。你也可以在本仓库对应的作业 Notebook 中自行尝试：OpenAI 作业 Notebook 与 Azure OpenAI 作业 Notebook。
import os from openai import OpenAI API_KEY = os.getenv("OPENAI_API_KEY","") client = OpenAI( api_key=API_KEY ) response = client.responses.create(model="gpt-5-mini", input="Suggest two titles for an instructional lesson on chat applications for generative AI.", store=False) print(response.output_text)上面的示例使用 GPT-5 mini 模型 + Responses API 完成提示词补全。注意：API 密钥必须预先通过环境变量OPENAI_API_KEY设置好，否则会直接报错——密钥缺失是新手最常见的失败点之一。
从仓库源码可以看到，同一套思路在不同语言/服务上有三种落地方式，便于你按环境选择：
- OpenAI / Azure OpenAI 官方 SDK（Responses API）：在 TypeScript 示例中，客户端通过
baseURL: ${endpoint}/openai/v1/指向 Azure OpenAI（Microsoft Foundry）的 v1 端点，模型名取自定义的部署名（默认gpt-5-mini），请求体用input数组按role（system/user）组织对话消息；Python 版见 aoai-assignment.ipynb，通过AZURE_OPENAI_ENDPOINT、AZURE_OPENAI_API_KEY、AZURE_OPENAI_DEPLOYMENT三个环境变量完成鉴权与模型选择。 - Azure AI Inference SDK（Microsoft Foundry Models / Chat Completions）：在 githubmodels-assignment-simple.ipynb 中，使用
ChatCompletionsClient(endpoint, AzureKeyCredential(token))并传入AZURE_INFERENCE_CREDENTIAL与AZURE_INFERENCE_ENDPOINT，通过client.complete(model=..., messages=[...])提交带角色的对话；对应的 JavaScript 版见 js-githubmodels/app.js，其代码注释中还给出了 Microsoft Foundry 模型目录中可选的模型清单（OpenAI 的 gpt-5-mini/gpt-4o、Microsoft 的 Phi-4、Meta 的 Llama 3.x、Mistral 等）。 - GitHub Models 用户：仓库中的 githubmodels-assignment.ipynb 提供了 Microsoft Foundry Models API 的快速上手路径，体验免费的模型目录与一致的 Azure AI Inference SDK。
无论走哪条路，消息结构都遵循同一约定：system消息定义模型的行为角色，user消息携带用户输入，assistant消息承载历史回复——这正是聊天应用维持多轮上下文的基础。
用户体验（UX）：为 AI 交互设计的附加考量
通用 UX 原则同样适用于聊天应用，但由于引入了机器学习组件，以下三点变得尤其关键：
- 歧义处理机制：生成式 AI 模型偶尔会生成模棱两可的答案。提供让用户请求澄清（ask for clarification）的功能，可以在遇到此类问题时显著改善体验。
- 上下文保留：先进模型能在对话中记住上下文，这是用户体验的宝贵资产。赋予用户控制与管理上下文的权力能改善体验，但也带来保留敏感用户信息的风险。引入保留策略（retention policy）明确信息存储时长，可以在上下文需求与隐私之间取得平衡。
- 个性化：凭借学习与适应能力，AI 模型能为用户提供千人千面的体验。通过用户画像（user profiles）等特性定制体验，不仅让用户感到被理解，还能帮他们更快找到具体答案，形成更高效、更满意的交互。
案例：ChatGPT 的 Custom Instructions
个性化的典型例子是 OpenAI ChatGPT 的「Custom instructions」设置。它允许你提供关于自身的信息，作为提示词的重要上下文。下图展示了一条自定义指令的效果：
这份"画像"让 ChatGPT 生成一份关于链表的教案。注意，ChatGPT 会根据这位用户的经验背景，主动给出更深入、更详尽的教案——这正是个性化带来的上下文感知价值：
Microsoft 面向大语言模型的系统消息框架
Microsoft 为编写有效的系统消息（system message）提供了官方指导，可归纳为 4 个领域，用于在从 LLM 生成回复时框定模型行为：
- 定义模型面向谁，以及它的能力与局限；
- 定义模型的输出格式；
- 提供具体示例，演示模型的预期行为；
- 提供额外的行为护栏（guardrails）。
这 4 点同样能在仓库示例中找到呼应：js-githubmodels/app.js通过两个连续 system 消息（"你是法国总统" + "你刚刚辞职"）精确框定角色与情境，再以 user 消息提问"接下来需要处理哪些事务？"，让模型在受限的人格设定内作答——这就是"定义能力边界 + 行为护栏"的代码化表达。
可访问性
无论用户存在视觉、听觉、运动还是认知障碍，设计良好的聊天应用都应人人可用。针对不同障碍类别，可以落地以下特性：
- 视觉障碍：高对比度主题、可缩放文本、屏幕阅读器兼容；
- 听觉障碍：文本转语音（TTS）与语音转文本（STT）功能、音频通知的可视化提示；
- 运动障碍：键盘导航支持、语音命令；
- 认知障碍：简化语言选项。
定制与微调：让模型理解你的领域
想象一个聊天应用，它听得懂你公司的行话，还能预判用户群体常问的问题。有两条值得关注的路径：
- 使用 DSL 模型：DSL 指领域特定语言（Domain Specific Language）。可以借助在特定领域训练过的 DSL 模型，让它理解该领域的概念与场景；
- 应用微调（fine-tuning）：微调是用特定数据对模型进行进一步训练的过程。
定制方案一：使用领域特定语言模型（DSL）
领域特定语言模型（DSL 模型）通过提供专业化、上下文相关的交互来提升用户参与度。它是在特定领域、行业或主题上训练或微调、以理解和生成相关文本的模型。使用 DSL 模型的方式多样：从零开始训练一个，到通过 SDK/API 直接复用现成模型，再到对已有预训练模型做领域适配（即微调）。
定制方案二：应用微调（fine-tuning）
当预训练模型在某个专门领域或具体任务上表现欠佳时，微调通常是首选方案。
以医疗场景为例：医疗查询往往复杂且依赖大量上下文。医生诊断患者时要综合生活方式、既往病史等多种因素，甚至可能查阅最新医学期刊来验证判断。在这种细致入微的场景里，通用型 AI 聊天应用难以成为可靠信息来源。
场景推演：医疗应用
设想一个辅助医疗从业者的聊天应用，为其快速提供治疗指南、药物相互作用或最新研究结果。
通用模型或许足以回答基础医学问题或给出一般性建议，但在以下情况中会力不从心：
- 高度特定或复杂的病例：例如神经科医生提问"儿童耐药性癫痫目前的最佳管理实践是什么？"；
- 缺乏最新进展：通用模型可能无法给出融合神经学与药理学最新突破的当下答案。
此时，用专门的医疗数据集对模型进行微调，能显著提升其准确、可靠地处理这类复杂医学问题的能力。前提是能获取一个足够大且相关的数据集，覆盖该领域需要解决的特定挑战与问题。
高质量 AI 聊天体验的考量
本部分界定"高质量"聊天应用的标准，包括可落地的指标采集，以及负责任地使用 AI 技术的框架。
关键指标
要保持应用的高质量运行，必须持续跟踪关键指标。这些度量不仅保障应用的功能，还评估 AI 模型质量与用户体验。下表覆盖基础、AI 与用户体验三类指标，并给出聊天应用开发者应思考的问题：
| 指标 | 定义 | 对聊天开发者的考量 |
|---|---|---|
| 运行时间（Uptime） | 应用保持运行、用户可访问的时间比例 | 如何将停机时间降到最低？ |
| 响应时间（Response Time） | 应用从收到用户查询到回复所花的时间 | 如何优化查询处理以改善响应时间？ |
| 精确率（Precision） | 真正例预测数占全部阳性预测数的比例 | 如何验证模型的精确率？ |
| 召回率（Recall/Sensitivity） | 真正例预测数占实际阳性样本数的比例 | 如何度量并提升召回率？ |
| F1 分数 | 精确率与召回率的调和平均，平衡二者权衡 | 目标 F1 是多少？如何平衡精确率与召回率？ |
| 困惑度（Perplexity） | 模型预测的概率分布与数据真实分布的对齐程度 | 如何最小化困惑度？ |
| 用户满意度指标 | 用户对应用的主观感受，常通过问卷采集 | 多久收集一次用户反馈？如何据此调整？ |
| 错误率（Error Rate） | 模型在理解或输出上出错的频率 | 有哪些降低错误率的策略？ |
| 重训练周期（Retraining Cycles） | 模型纳入新数据与新洞察而更新的频率 | 多久重训一次模型？什么触发重训？ |
| 异常检测（Anomaly Detection） | 识别不符合预期行为的异常模式的工具与技术 | 遇到异常如何响应？ |
在聊天应用中落地负责任的 AI 实践
Microsoft 的负责任 AI 方法确立了六项应指导 AI 开发与使用的原则。下表列出各原则、官方定义、聊天应用开发者应做的考量，以及重视它们的原因：
| 原则 | Microsoft 的定义 | 对聊天开发者的考量 | 为什么重要 |
|---|---|---|---|
| 公平（Fairness） | AI 系统应公平对待所有人 | 确保聊天应用不基于用户数据产生歧视 | 建立用户间的信任与包容性；避免法律后果 |
| 可靠与安全（Reliability and Safety） | AI 系统应可靠、安全地运行 | 实施测试与故障兜底（fail-safes）以最小化错误与风险 | 保障用户满意度，防止潜在伤害 |
| 隐私与安全（Privacy and Security） | AI 系统应安全并尊重隐私 | 实施强加密与数据保护措施 | 保护敏感用户数据，遵守隐私法律 |
| 包容（Inclusiveness） | AI 系统应赋能每一个人并让人参与进来 | 设计对多元受众可用、易用的 UI/UX | 确保更广泛的人群能有效使用应用 |
| 透明（Transparency） | AI 系统应可被理解 | 为 AI 回复提供清晰的文档与理由说明 | 用户理解决策过程后更可能信任系统 |
| 问责（Accountability） | 人应对 AI 系统负责 | 建立审计与改进 AI 决策的清晰流程 | 支持持续改进，出错时可纠正 |
动手实践：作业与进阶路径
本课在 07-building-chat-applications/python 目录下提供了系列练习，带你从运行第一条聊天提示词开始，逐步完成文本分类、摘要生成等任务，并进一步覆盖产品命名生成、嵌入（embeddings）与分类器微调。值得注意：
- 多语言覆盖：作业同时提供 Python 版 Notebook（OpenAI、Azure OpenAI、Microsoft Foundry 三套）与 JavaScript/TypeScript 版应用。例如 aoai-assignment.ipynb 内还包含提示词设计的三条基本原则——"展示与讲述（show and tell）"、"提供高质量数据"、"检查参数设置（temperature 与 top_p 控制确定性而非"聪明度"）"——这些可直接指导你的提示词调优；
- 本地运行前提：运行 Notebook 前需按仓库要求安装依赖并配置环境变量（OpenAI 路径为
OPENAI_API_KEY；Azure 路径为AZURE_OPENAI_ENDPOINT/AZURE_OPENAI_API_KEY/AZURE_OPENAI_DEPLOYMENT；Foundry 路径为AZURE_INFERENCE_CREDENTIAL/AZURE_INFERENCE_ENDPOINT）； - 前后课衔接：第 7 课聚焦聊天应用的构建与监控，完成后可继续学习第 8 课，了解如何开始构建搜索应用，将对话能力与检索能力组合成更完整的系统。
小结
构建生成式 AI 驱动的聊天应用是一个贯穿「架构选型 → SDK/API 接入 → UX 设计 → 领域定制 → 指标监控 → 负责任 AI」的完整闭环：先用 SDK/API 快速复用大模型能力并保持可扩展性，再通过 system message、上下文管理与个性化设计打磨体验，必要时用 DSL 或微调适配专业领域，最后用精确率、召回率、响应时间等指标持续监控质量，并始终以公平、可靠、隐私、包容、透明、问责六原则约束应用行为。你可以在本仓库的 Python Notebook 与 TypeScript/JavaScript 示例中逐行对照本文所述实现，直接跑通第一条聊天提示词。
【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
