generative-ai-for-beginners 第 07 课实战:构建生成式 AI 聊天应用——SDK 集成、UX 设计与负责任 AI 指标

generative-ai-for-beginners 第 07 课实战:构建生成式 AI 聊天应用——SDK 集成、UX 设计与负责任 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 仓库第 07 课《Building Generative AI-Powered Chat Applications》(含保加利亚语译本 translations/bg/07-building-chat-applications/README.md) 编写,系统讲解如何把生成式 AI 集成进聊天应用:从"聊天机器人 vs 聊天应用"的架构辨析、SDK/API 快速接入、用户体验与系统消息框架,到 DSL 模型与微调策略,再到上线后的关键质量指标与六大负责任 AI 原则。读完后,你可以独立完成一个可运行的聊天补全应用,并掌握评估与监控它的完整方法体系。

课程定位与学习目标

在掌握了文本生成应用(第 06 课)之后,本课把视角转向聊天应用。聊天应用早已深入客户服务、技术支持乃至专业顾问系统;随着生成式 AI 的接入,系统的复杂度与随之而来的挑战都在增加。课程聚焦两个核心问题:

• 构建(Building):如何为特定用例高效地构建并无缝集成这些 AI 驱动的应用?
• 监控(Monitoring):部署之后,如何持续观察应用,确保其在功能性与负责任 AI 原则两方面都保持最高质量?

课程覆盖三块内容:高效构建与集成聊天应用的技术、对应用进行个性化与微调的方法、以及有效监控聊天应用的策略与考量。

完成本课之后,你应当能够:

• 描述将聊天应用构建并集成到既有系统中的各项考量;
• 针对特定用例定制聊天应用;
• 识别用于有效监控、维护 AI 聊天应用质量的关键指标;
• 确保聊天应用负责任地(AI responsibly)使用人工智能。

聊天机器人(Chatbot)还是聊天应用(Chat Application)?

在动手之前,先厘清两个常被混用的概念——它们的角色与功能并不相同:

• 聊天机器人(Chatbot)的主要目的是自动化特定对话任务,例如回答常见问题、查询快递状态。它通常由基于规则的逻辑或复杂的 AI 算法驱动。
• AI 驱动的聊天应用则是一个更广阔的载体,用来承载文本、语音、视频等多种人机/人人数字通信形式。其标志性特征是集成了生成式 AI 模型:模型模拟细腻的类人对话,基于多样的输入与上下文信号生成回复,能够参与开放域讨论、适应不断演化的对话语境,甚至产出创造性或复杂的对话。

两者的关键差异对照如下(继承自课程原文档):

用 SDK 和 API 复用现成功能

构建聊天应用时的第一步,是评估"市面上已经有什么"。使用 SDK 和 API 来搭建聊天应用是一种高价值策略,课程原文档给出了四条理由:

• 加速开发、降低开销:复用成熟功能而非从零自建,让你可以把精力放在业务逻辑等更重要的部分;
• 更好的性能:自建功能时你迟早要问"它能横向扩展吗?能扛住流量尖峰吗?"——维护良好的 SDK 和 API 往往内置了这些问题的答案;
• 更省心的维护:版本升级通常只需要更新一个库依赖;
• 触达前沿技术:使用在大规模语料上预训练、微调过的模型,可直接为你的应用带来自然的语言理解与生成能力。

接入模式:先拿到密钥,再调用对话接口

访问 SDK 或 API 的功能,通常需要凭一个唯一的密钥或认证令牌获得服务授权。课程原文档以 OpenAI Python Library 为例:

import os from openai import OpenAI API_KEY = os.getenv("OPENAI_API_KEY", "") client = OpenAI( api_key=API_KEY ) chat_completion = client.chat.completions.create( model="gpt-3.5-turbo", messages=[{"role": "user", "content": "Suggest two titles for an instructional lesson on chat applications for generative AI."}] )

注意 API 密钥必须先于调用注入:如果密钥未设置,请求会直接报错。

仓库实战:本仓库中的三种接入姿势

课程配套代码同时提供了 Python 与 JavaScript/TypeScript 实现,可以对照查看当前仓库中真实可运行的接入方式。

1) Python 笔记本:OpenAI / Azure OpenAI / Microsoft Foundry 三套方案

本仓库的课堂练习位于 07-building-chat-applications/python/ 目录,包含成对的完整版与简化版笔记本:

• oai-assignment.ipynb(OpenAI)与 oai-assigment-simple.ipynb
• aoai-assignment.ipynb(Azure OpenAI)与 aoai-assigment-simple.ipynb
• githubmodels-assignment.ipynb(Microsoft Foundry Models)

以 oai-assignment.ipynb 为例,它展示了从"安装依赖 → 加载密钥 → 选择模型 → 设计 Prompt → 提交请求"的完整闭环。其中值得注意的两点:

第一,凭证管理使用python-dotenv从.env加载,并对缺失的密钥做硬断言:

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)

第二,仓库中的调用已迁移到 Responses API,用input消息数组替代了传统的messages字段,并显式关闭服务端存储(store=False):

model = "gpt-4o-mini" response = client.responses.create( model=model, input=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Should oxford commas always be used?"}, ], store=False, ) response.output_text

该笔记本随后演示了三个典型聊天场景:文本摘要(在段落末尾追加 "tl;dr:" 触发总结)、文本分类(把客户咨询分到[Pricing, Hardware Support, Software Support]类别)、以及基于种子词的产品命名(并调高 temperature 以增加创造性)。这正好印证了上文"SDK/API 让你直接获得前沿语言能力"的判断——几个 Prompt 就能覆盖摘要、分类、创意生成。

2) TypeScript 示例:Azure OpenAI 的多系统消息会话

07-building-chat-applications/typescript/chat-completions-app/src/main.ts 是一个独立的 Node 工程,演示了把 OpenAI SDK 指向 Azure OpenAI 的兼容端点。客户端构造的关键在于把baseURL指向<endpoint>/openai/v1/(main.ts):

const endpoint = process.env.AZURE_OPENAI_ENDPOINT || ''; const azureApiKey = process.env.AZURE_OPENAI_API_KEY || ''; const client = new OpenAI({ apiKey: azureApiKey, baseURL: `${endpoint.replace(/\/$/, '')}/openai/v1/`, });

其请求体(main.ts)连续下发两条system消息再追加一条user消息,是"多系统消息塑造角色"的一个直观样例,并对输出长度设了max_output_tokens: 100的上限:

const result = await client.responses.create({ model: deploymentName, input: [ { role: "system", content: "You're the president of France" }, { role: "system", content: "You have just resigned" }, { role: "user", content: "What tasks needs doing?" } ], max_output_tokens: 100, store: false, });

运行方式同样朴素:依赖openai与dotenv(package.json),npm run build走rimraf build && tsc,npm start则用 nodemon + ts-node 监听src目录热启动。

3) JavaScript 示例:Azure AI Inference SDK 与显式环境变量校验

js-githubmodels/app.js 展示了另一条路径——通过@azure-rest/ai-inference的ModelClient直接 POST/chat/completions。它在仓库中体现了一个良好的生产习惯:对必需的环境变量做启动期硬校验,缺任何一个就快速失败(app.js):

const token = process.env["AZURE_INFERENCE_CREDENTIAL"]; if (!token) { throw new Error("AZURE_INFERENCE_CREDENTIAL environment variable is required. ..."); } const endpoint = process.env["AZURE_INFERENCE_ENDPOINT"]; if (!endpoint) { throw new Error("AZURE_INFERENCE_ENDPOINT environment variable is required. ..."); }

调用部分(app.js)同样使用了"两条 system 消息 + 一条 user 消息"的会话结构,并在注释中列出了 Foundry 模型目录里可直接切换的模型家族(Llama、Mistral、Phi、gpt-4o-mini 等)——这也正是"换一行modelName就能换模型"的 SDK 优势所在。

用户体验(UX):为机器学习组件加上的特殊考量

通用 UX 原则当然适用,但生成式 AI 的引入让以下三点格外重要(课程原文档的完整清单):

• 不清晰内容的处理机制:生成式模型偶尔会产出含糊的回答,提供"要求澄清"的功能可以帮助用户走出歧义;
• 上下文保留(Context retention):先进模型能在会话内记忆上下文,这是体验的必要资产。把控制权交给用户(管理/清除上下文)能提升体验,但也引入敏感信息被留存的隐私风险——例如引入数据保留策略(retention policy),在"需要上下文"与"保护隐私"之间取得平衡;
• 个性化(Personalization):模型具备学习与适应能力,用户画像之类的个性化功能既让用户感到"被理解",也能帮助其更快找到确切答案。

文档举了一个真实产品级的例子:ChatGPT 的"自定义指令"设置。用户预先提供关于自己的信息,这些信息会成为后续所有 Prompt 的隐含上下文。上图中这个"开发者画像"让 ChatGPT 在收到"写一个链表课程计划"的请求时,自动推断出用户希望获得更深入的方案,而不是面向新手的浅层讲解。

系统消息(System Message)的四要素框架

课程引用了微软关于"如何为 LLM 撰写有效系统消息"的官方指导,将其归纳为四个维度:

1. 定义模型为谁服务,以及它的能力与局限;
2. 定义模型的输出格式;
3. 提供展示期望行为的具体示例;
4. 给出额外的行为护栏(behavioral guardrails)。

仓库中的两个示例应用恰好是这个框架的活注释:main.ts 与 app.js 都通过叠加系统消息来约束角色(法国总统/刚刚辞职),属于第 1、4 条;而 Python 笔记本中统一的"You are a helpful assistant."则是最小化的第 1 条实践。

可访问性(Accessibility)

无论用户存在视觉、听觉、运动还是认知障碍,设计良好的聊天应用都应可供所有人使用。课程原文档按障碍类型列出了具体功能点:

• 视觉障碍:高对比度主题、可缩放文本、屏幕阅读器兼容;
• 听觉障碍:文字转语音(TTS)与语音转文字(ASR)、针对音频通知提供视觉提示;
• 运动障碍:键盘导航支持、语音命令;
• 认知障碍:简化语言选项。

面向领域语言模型的定制与微调

设想一个能理解公司行话、并预判用户群体高频问题的聊天应用。课程原文档给出两条路径:

• 使用 DSL 模型(Domain-Specific Language,领域专用语言):使用在特定领域上训练过的模型,使其理解该领域的概念与场景;
• 应用微调(Fine-tuning):用特定数据对模型做进一步训练。

关于 DSL 模型的落地,选项谱系很宽:从零训练一个、通过 SDK/API 使用现成模型,或对已有的预训练模型做微调以适配特定领域。

何时需要微调:一个医疗场景

当预训练模型在某个专业领域或具体任务上力不从心时,就轮到微调登场。文档用医疗场景说明了"通用模型的天花板":

诊断依赖生活方式、既往病史等多重因素,甚至需要最新医学文献佐证——在这样的细腻场景下,通用 AI 聊天应用不能作为可靠信息源。假设我们构建一个为医疗从业者提供治疗指南、药物相互作用与最新研究快速检索的聊天应用,通用模型在以下情况会露出短板:

• 高度特定或复杂的病例:例如神经科医生问"儿童患者药难治性癫痫当前的最佳管理实践是什么?";
• 缺少最新进展:通用模型难以给出融合了神经学与药理学最新进展的现时答案。

此时,用规模足够大、且能代表该领域典型挑战与问题的专业医疗数据集对模型做微调,可以显著提升其处理这类复杂医学查询的准确性与可靠性。

高质量 AI 聊天体验:关键指标与负责任实践

"高质量"聊天应用的判定标准,包括可采集的量化指标与负责任使用 AI 的框架两部分。

关键指标(原文档表格全量继承)

保加利亚语译本的表格仅保留了表头与"异常检测"一行,完整十项指标以英文原版 07-building-chat-applications/README.md 为准;上表已做全量恢复,便于按"基础指标 / AI 模型指标 / 用户体验指标"三个层面建监控看板。

在聊天应用中落实负责任 AI 六原则

微软的负责任 AI(RI)方法论提出六项原则,课程原文档逐条给出了"聊天开发者视角"的落地要点与重要性,此处完整继承:

课后实战与延伸

• 练习入口:课程配套练习集中在 07-building-chat-applications/python/,覆盖从运行第一个聊天 Prompt,到文本分类、摘要的系列步骤,且按 OpenAI / Azure OpenAI / Foundry Models 三种后端各有一套;另有 TypeScript 版 chat-completions-app 与 JavaScript 版 js-githubmodels/app.js 可对照学习。运行前请先按各示例注释配置相应环境变量(如OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT、AZURE_INFERENCE_CREDENTIAL等),密钥缺失时代码会显式报错——这正是本课强调的"先授权、后调用"模式。
• 继续学习:完成本课后可进入第 08 课,了解如何构建检索(Search)应用,见 08-building-search-applications/README.md;保加利亚语译本中亦有对应指引。

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