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 模型:模型模拟细腻的类人对话,基于多样的输入与上下文信号生成回复,能够参与开放域讨论、适应不断演化的对话语境,甚至产出创造性或复杂的对话。两者的关键差异对照如下(继承自课程原文档):聊天机器人生成式 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_keyAPI_KEY ) chat_completion client.chat.completions.create( modelgpt-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.ipynbaoai-assignment.ipynb(Azure OpenAI)与 aoai-assigment-simple.ipynbgithubmodels-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_keyAPI_KEY)第二,仓库中的调用已迁移到 Responses API,用input消息数组替代了传统的messages字段,并显式关闭服务端存储(storeFalse):model gpt-4o-mini response client.responses.create( modelmodel, input[ {role: system, content: You are a helpful assistant.}, {role: user, content: Should oxford commas always be used?}, ], storeFalse, ) 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: Youre 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 撰写有效系统消息的官方指导,将其归纳为四个维度:定义模型为谁服务,以及它的能力与局限;定义模型的输出格式;提供展示期望行为的具体示例;给出额外的行为护栏(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 的框架两部分。关键指标(原文档表格全量继承)指标定义聊天应用开发者需思考的问题正常运行时间(Uptime)应用可被用户正常访问的时长你将如何把停机时间降到最低?响应时间(Response Time)应用回复用户查询所花的时间如何优化查询处理以提升响应速度?精确率(Precision)真正例预测数占所有正例预测的比例你将如何验证模型的精确率?召回率(Recall/Sensitivity)真正例预测数占实际正例总数的比例你将如何度量并提升召回率?F1 分数精确率与召回率的调和平均,平衡两者取舍你的目标 F1 是多少?如何平衡两者?困惑度(Perplexity)模型预测的概率分布与实际数据分布的吻合程度你将如何降低困惑度?用户满意度用户对应用的感知,通常通过调查采集多久收集一次反馈?如何据其迭代?错误率(Error Rate)模型在理解或输出上犯错的比率你有哪些降低错误率的策略?再训练周期(Retraining Cycles)模型吸纳新数据与新认知的更新频率多久再训练一次?什么事件触发再训练?异常检测(Anomaly Detection)识别不符合预期行为的异常模式的工具与技术你如何应对检测到的异常?保加利亚语译本的表格仅保留了表头与异常检测一行,完整十项指标以英文原版 07-building-chat-applications/README.md 为准;上表已做全量恢复,便于按基础指标 / AI 模型指标 / 用户体验指标三个层面建监控看板。在聊天应用中落实负责任 AI 六原则微软的负责任 AI(RI)方法论提出六项原则,课程原文档逐条给出了聊天开发者视角的落地要点与重要性,此处完整继承:原则微软的定义聊天应用开发者的考量为什么重要公平性(Fairness)AI 系统应公平地对待所有人确保应用不因用户数据而产生歧视建立用户信任与包容性,规避法律风险可靠性与安全性(Reliability Safety)AI 系统应可靠、安全地运行实施测试与故障保护机制,最小化错误与风险保障用户满意,防止潜在伤害隐私与安全(Privacy Security)AI 系统应安全且尊重隐私实施强加密与数据保护措施保护敏感用户数据,满足隐私法规包容性(Inclusiveness)AI 系统应赋能每个人设计对多样化受众都易用的 UI/UX让更广泛的人群能高效使用应用透明性(Transparency)AI 系统应可被理解为 AI 的回答提供清晰的文档与推理说明用户理解决策过程,才更可能信任系统问责性(Accountability)人应对 AI 系统负责建立审计与改进 AI 决策的清晰流程出错时能持续改进并采取纠正措施课后实战与延伸练习入口:课程配套练习集中在 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考