generative-ai-for-beginners 第 7 课构建生成式 AI 驱动的聊天应用——从架构整合到监控与责任实践【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners生成式 AI 正在把聊天应用从“回答问题的小工具”升级为可以理解上下文、开展开放话题对话并融入复杂业务流程的产品形态。本课对应本仓库第 7 课源自 07-building-chat-applications系统讲解基于大语言模型的聊天应用如何选型 SDK、处理用户体验与无障碍细节、借助领域专用语言与微调适配垂直场景并给出可落地的质量指标与负责任的 AI 六原则实践框架学完后你可以在 oai-assignment.ipynb、aoai-assignment.ipynb 等练习中动手实现自己的第一个聊天提示词、文本分类与摘要应用。自定义指令是“对话个性化”的直观例子把个人信息写进 profile 后模型生成的内容会自动带上这些上下文。一、为什么要关注“AI 聊天应用”聊天应用早已融入日常生活它们不只是闲聊工具更是客户服务、技术支持乃至复杂咨询系统的一部分。把生成式 AI 引入这些平台后复杂度与挑战同步上升。围绕这门课核心要回答两个问题构建Building the app如何针对特定用例高效构建并无缝集成这类 AI 应用监控Monitoring上线之后如何持续监控并确保应用在功能性和负责任 AI 两个维度上都保持高质量理解生成式 AI 如何改变聊天应用的广度、深度与适应性是本课的底层线索。你将在本课掌握三件事高效构建与集成聊天应用的技术如何对应用做定制与微调以及有效监控聊天应用的策略与考量。二、Chatbot 还是聊天应用先分清概念动手之前先区分两个经常被混用的概念——chatbot 与“AI 驱动的聊天应用”二者承担的角色与功能截然不同。Chatbot的主要目的是把特定的对话任务自动化例如回答高频 FAQ、跟踪包裹物流。它通常由规则逻辑或相对固定的算法控制。AI 驱动的聊天应用是更庞大的环境用于承载文字、语音、视频等多种数字沟通形态其定义性特征是集成了生成式 AI 模型它模拟细腻、接近人类的对话根据广泛的输入与上下文线索生成回答可以聊开放话题、随对话语境演进、甚至产出有创意的复杂对白。Chatbot生成式 AI 驱动的聊天应用面向任务、基于规则上下文感知常被嵌入到更大的系统中可以承载一个或多个 chatbot局限于被编程的功能内置生成式 AI 模型交互专门化、结构化能进行开放话题讨论本课之后的内容均围绕右侧的“生成式 AI 驱动聊天应用”展开。三、站在巨人肩上用 SDK 与 API 复用成熟能力构建聊天应用时一个明智的起点是“先盘点市面上已有什么”。使用 SDK 和 API 之所以是长期更优的策略理由很具体加快开发、降低开销复用现成能力而不是从零自研昂贵的基础设施可以把精力投向更重要的业务逻辑。更好的性能从零实现时你迟早会问“它怎么扩容能扛住用户突然涌入吗”——维护良好的 SDK/API 通常内置了这些问题的解法。更易维护大多数 API/SDK 发布新版本时只需升级依赖库。接触前沿技术直接调用在海量数据集上训练、微调过的模型应用立刻获得自然语言处理能力。3.1 API Key 与最小可用调用访问 SDK/API 能力通常需要先取得服务许可最常见的形式是唯一的 API Key 或身份验证令牌。以下是基于 OpenAI Python 库的最简调用形态本仓库英文版 README 中的示例import os from openai import OpenAI API_KEY os.getenv(OPENAI_API_KEY, ) client OpenAI(api_keyAPI_KEY) response client.responses.create( modelgpt-4o-mini, inputSuggest two titles for an instructional lesson on chat applications for generative AI., storeFalse, ) print(response.output_text)上面的例子用 gpt-4o-mini 通过 Responses API 完成提示词补全。注意 API Key 必须在调用之前设置好——不设置会直接报错。更稳妥的做法是像练习 oai-assignment.ipynb 中那样用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)3.2 在仓库中对照三种接入形态同一套业务逻辑在本仓库里给出了多语言、多后端的实现恰好演示了“SDK 与 API”策略的具体差异OpenAI 直连oai-assignment.ipynb直接用openai库 OPENAI_API_KEY选通用聊天模型即可代码中以model gpt-4o-mini为例属于最简单的形态。Azure OpenAIaoai-assignment.ipynb客户端需要同时提供AZURE_OPENAI_API_KEY和AZURE_OPENAI_ENDPOINT并把base_url指向endpoint/openai/v1/模型名改为读取环境变量AZURE_OPENAI_DEPLOYMENT对应你部署时分配的名字例如gpt-4o-miniimport os from openai import OpenAI from dotenv import load_dotenv load_dotenv() endpoint os.environ[AZURE_OPENAI_ENDPOINT] client OpenAI( api_keyos.environ[AZURE_OPENAI_API_KEY], base_urlf{endpoint.rstrip(/)}/openai/v1/, ) # 部署名称从 .env 读取 model os.environ[AZURE_OPENAI_DEPLOYMENT]GitHub Models / Microsoft Foundry 推理端点githubmodels-assignment.ipynb改用azure-ai-inference的ChatCompletionsClient凭证与端点在项目 “Overview” 页获取模型名直接可切换如 gpt-4o-mini、Phi-4、Llama-3.2 等import os from azure.ai.inference import ChatCompletionsClient from azure.ai.inference.models import SystemMessage, UserMessage from azure.core.credentials import AzureKeyCredential token os.environ[AZURE_INFERENCE_CREDENTIAL] endpoint os.environ[AZURE_INFERENCE_ENDPOINT] client ChatCompletionsClient(endpointendpoint, credentialAzureKeyCredential(token)) model_name gpt-4o-mini response client.complete( modelmodel_name, messages[{role: system, content: You are a helpful assistant.}, {role: user, content: text_prompt}], ) response.choices[0].message.content值得注意三种后端在练习 oai-assignment.ipynbOpenAI Responses API、aoai-assignment.ipynbAzure Responses API与 githubmodels-assignment.ipynbAzure AI Inferencecomplete中都能跑出同样的“首个聊天提示词”效果——这正是“服务商抽象”给聊天应用带来的最大价值业务代码尽量少改随时可换模型供应方。仓库还提供了 TypeScript 与 JavaScript 参考实现便于对照 SDK 的端到端工程化写法TypeScript 版 main.ts 使用openai官方 TypeScript 客户端构造system user角色消息并指定max_output_tokens、store: false配套 package.json 用ts-nodenodemon开发运行、tsc构建展示了一条可移植到真实项目的工程链路。JavaScript 版 js-githubmodels/app.js 走 Azure AI Inference REST 路径/chat/completions并在启动时对AZURE_INFERENCE_CREDENTIAL与AZURE_INFERENCE_ENDPOINT做强制校验可作为“生产级启动检查”的样板。.NET 学习者可以参考 notebook-azure-openai.dib。四、用户体验UX聊天应用特有的设计考量通用 UX 原则当然适用于聊天应用但由于涉及机器学习组件有几个额外的考量会变得格外重要。处理歧义的机制生成式 AI 偶尔会产出含糊的回答。提供“请解释 / 再说清楚点”的能力能在用户遇到歧义时兜底。上下文保留Context Retention先进模型能记住对话内的上下文这是体验的必要资产。让用户有能力查看与管控上下文能提升体验但也引入了“长期留存敏感用户信息”的风险。引入数据保留策略retention policy之类的手段可以在“需要上下文”与“保护隐私”之间取得平衡。个性化Personalization能学习与适应的 AI 模型天然可以给出千人千面的体验。借助用户画像user profiles等机制定制体验既让用户感到“被理解”也能帮用户更快地找到想要的答案。4.1 实例ChatGPT 的自定义指令个性化的典型例子就是 OpenAI ChatGPT 的 “Custom Instructions”自定义指令设置——你可以提交关于自己的信息作为提示词的上下文。下图演示了一条自定义指令告诉 ChatGPT 你是“有 12 年以上编程经验、正在做算法教学的高中教师”。注意回答质量的关键ChatGPT 会结合用户背景生成比其他通用请求“更深入”的教学计划——这就是上下文个性化带来的可感知差异。4.2 Microsoft 的大语言模型系统提示框架要给 LLM 生成高质量回复Microsoft 官方指引建议把系统提示system message拆成四个板块来写定义模型的服务对象面向谁以及它的能力与限制定义模型输出格式提供能示范模型预期行为的具体例子提供额外的行为护栏guardrails。仓库代码里就有现成的多角色消息范例。在 TypeScript 版 main.ts 中可以看到system与user角色混排的用法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, }); console.log(result.output_text);这里把“身份定义”与“情景约束”都放在 system 消息里最后用 user 消息抛出任务——正是“框架第 1、2 条”的落地写法。4.3 无障碍Accessibility无论用户是视障、听障、运动障碍还是认知障碍设计良好的聊天应用都应对所有人可用。按障碍类型划分常见的增强特性包括针对视觉障碍高对比度主题、可调字号、兼容屏幕阅读器。针对听觉障碍文本转语音与语音转文本、音频通知的可视化提示。针对运动障碍键盘导航支持、语音命令。针对认知障碍提供简化语言选项。在构建 UX 时把这些当成一等公民而不是上线前的“加分项”正是本课反复强调的工程态度。五、针对垂直领域的定制DSL 模型与微调想象一个能听懂你公司行话、并预判用户常见问题的聊天应用。让通用模型具备领域能力通常有两条路线利用 DSL 模型或做微调fine-tuning。DSLDomain-Specific Language领域专用语言模型针对特定领域、行业或主题训练或微调过的模型能理解该领域的概念与场景。使用 DSL 模型的方式可以从零训练也可以直接经由 SDK/API 使用现成者。微调Fine-tuning用特定数据对模型进行追加训练的过程。当预训练模型在某个专门领域或任务上力不从心时微调通常是首选方案。5.1 场景推演医疗垂直应用设想一个辅助医疗从业者的聊天应用——快速给出治疗指南、药物相互作用或最新研究结果的参考。这类问答复杂且极度依赖上下文医生做诊断依赖生活习惯、既往病史甚至要引用最新医学期刊来验证。在这种情况下通用 AI 聊天应用很难成为可靠来源它可能在以下环节失手高度专业或复杂的病例。例如神经科医生问“目前儿童耐药性癫痫的最佳管理实践是什么”缺乏最新进展。通用模型难以及时给出包含神经学与药理学最新成果的回答。针对这类场景用专业医学数据集做微调能显著提升模型回答复杂医学问题的准确性与可靠性。当然前提是你能拿到足够大、足够相关、能代表领域真实难题与高频问题的数据集。想动手体会“微调”到底是什么可继续阅读本仓库第 18 课 18-fine-tuning那里给出了用 JSONL 训练数据做微调并观察效果差异的完整流程。六、打造高质量 AI 聊天体验指标与负责任实践所谓“高质量”不应是口号而应落到两件事上采集可行动的指标以及遵守负责任使用 AI 的框架。6.1 关键指标一览下面这张指标表覆盖了系统可用性、模型质量与用户体验三个层面。它同时给出“指标定义”与“聊天应用开发者该反问自己的问题”——用问题驱动选型比死记指标名更有价值。指标定义聊天开发者要思考的问题正常运行时间Uptime应用可被用户访问并工作的时间占比如何把停机时间降到最低响应时间Response Time应用回复一次用户查询所花时间如何优化查询处理以改善响应时间精确率Precision真正例预测数占全部正预测数的比例如何验证模型的精确率召回率 / 灵敏度Recall / Sensitivity真正例预测数占实际正例数的比例如何测量并提高召回率F1 分数F1 Score精确率与召回率的调和平均平衡两者取舍目标 F1 是多少如何平衡精确率与召回率困惑度Perplexity模型预测的概率分布与数据真实分布的契合程度如何把困惑度压下去用户满意度指标用户对应用的主观感知通常通过问卷采集多久收集一次反馈如何据其迭代错误率Error Rate模型在理解或输出上犯错的比率有哪些降低错误率的策略重训周期Retraining Cycles模型纳入新数据与新洞察的更新频率多久重训一次什么事件触发一次重训异常检测Anomaly Detection识别不符合预期行为之异常模式的工具与技术遇到异常如何响应注意官方文档里指标表不止于“埋点”它还是一种“可观测性设计”——每一个指标都对应一个应该被回答的运营问题何时重训、如何降错、异常怎么兜底这正是第 14 课 LLMOps 生命周期讨论的工程化主题在单课内的前奏。6.2 在聊天应用中落地负责任的 AI 六原则Microsoft 的负责任 AI 框架提炼出六条指导 AI 开发与使用的原则。下面把“原则定义”“聊天开发者要做什么”“为什么重要”三列对齐原则Microsoft 定义聊天开发者的落地动作为什么重要公平性 FairnessAI 系统应当公平对待所有人确保聊天应用不基于用户数据歧视任何人在用户中建立信任与包容规避法律风险可靠性与安全性 Reliability SafetyAI 系统应当可靠且安全地运行实施测试与故障兜底fail-safes把错误和风险降到最低保障用户满意度防止潜在伤害隐私与安全 Privacy SecurityAI 系统应当安全并尊重隐私实施强加密与数据保护措施保护敏感用户数据合规于隐私法规包容性 InclusivenessAI 系统应当赋能并吸纳所有人面向多元人群设计可访问、易用的 UI/UX让更广泛的人群都能高效使用应用透明性 TransparencyAI 系统应当可被理解为 AI 回答提供清晰的文档与理由说明用户理解决策机制后更愿意信任系统问责 Accountability人应当对 AI 系统负责建立审计与改进 AI 决策的清晰流程支持持续改进出错时有纠正手段进一步研读可参考本仓库第 3 课 03-using-generative-ai-responsibly 中的缓解循环与分层治理图而在聊天应用里“系统提示 输出格式约束 行为护栏”那套 系统提示框架正是把“可靠性与安全、透明性”落到工程上的第一道防线。七、动手练习跟着练习跑一遍完整用例本课作业在 07-building-chat-applications/python 目录会带着你从“跑出第一个聊天提示词”一路走到文本分类、文本摘要与产品名生成。练习以多语言、多后端形式提供方便对照OpenAIoai-assignment.ipynb完整版、oai-assigment-simple.ipynb精简入门版Azure OpenAIaoai-assignment.ipynb含 Embeddings 与 CNN 新闻文章相似度对比等扩展、aoai-assigment-simple.ipynbGitHub Models / Foundrygithubmodels-assignment.ipynb、githubmodels-assignment-simple.ipynb另有TypeScriptchat-completions-app、JavaScriptjs-githubmodels与.NETnotebook-azure-openai.dib等语言版本。几个值得在练习中重点观察的现象重复调用同一提示词练习中设计了对同一请求连发两次的步骤oai-assignment.ipynb输出会有差异——这直观展示了 LLM 的采样随机性也引出“温度/采样参数”对一致性的影响。摘要、分类与命名三个用例同一个“system 助手 user 指令”骨架可以复用到Tl;dr摘要、[Pricing, Hardware Support, Software Support]三分类、基于种子词的“HomeShaker”类产品命名等场景说明聊天 API 本质是通用的文本指令引擎。多后端差异OpenAI 用client.responses.create(model..., input[...])GitHub Models 用client.complete(model..., messages[...])——消息结构几乎一一对应迁移成本被 SDK 压得很低。八、小结与下一步本课完成了四件事明确了 chatbot 与 AI 聊天应用的本质差异论证了为什么应该优先用 SDK/API 而非自研给出了用户体验、系统提示与无障碍的设计清单并提供了用关键指标与负责任 AI 六原则把“高质量”工程化的框架。DSL 模型与微调则在通用模型不足以覆盖垂直领域如医疗时提供了进阶路径。继续学习的推荐路径深入提示词设计第 4 课 04-prompt-engineering-fundamentals 与第 5 课 05-advanced-prompts从聊天到文本生成第 6 课 06-text-generation-apps想让应用更懂你的私有数据第 8 课开始讲构建搜索应用引入向量检索后续第 15 课 RAG 与向量数据库 会完整展开。读完第 8 课你就能学会“让聊天应用在回答时引用真实数据”的关键一招。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 generative-ai-for-beginners 第 7 课：构建生成式 AI 驱动的聊天应用——从架构整合到监控与责任实践
generative-ai-for-beginners 第 7 课构建生成式 AI 驱动的聊天应用——从架构整合到监控与责任实践【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners生成式 AI 正在把聊天应用从“回答问题的小工具”升级为可以理解上下文、开展开放话题对话并融入复杂业务流程的产品形态。本课对应本仓库第 7 课源自 07-building-chat-applications系统讲解基于大语言模型的聊天应用如何选型 SDK、处理用户体验与无障碍细节、借助领域专用语言与微调适配垂直场景并给出可落地的质量指标与负责任的 AI 六原则实践框架学完后你可以在 oai-assignment.ipynb、aoai-assignment.ipynb 等练习中动手实现自己的第一个聊天提示词、文本分类与摘要应用。自定义指令是“对话个性化”的直观例子把个人信息写进 profile 后模型生成的内容会自动带上这些上下文。一、为什么要关注“AI 聊天应用”聊天应用早已融入日常生活它们不只是闲聊工具更是客户服务、技术支持乃至复杂咨询系统的一部分。把生成式 AI 引入这些平台后复杂度与挑战同步上升。围绕这门课核心要回答两个问题构建Building the app如何针对特定用例高效构建并无缝集成这类 AI 应用监控Monitoring上线之后如何持续监控并确保应用在功能性和负责任 AI 两个维度上都保持高质量理解生成式 AI 如何改变聊天应用的广度、深度与适应性是本课的底层线索。你将在本课掌握三件事高效构建与集成聊天应用的技术如何对应用做定制与微调以及有效监控聊天应用的策略与考量。二、Chatbot 还是聊天应用先分清概念动手之前先区分两个经常被混用的概念——chatbot 与“AI 驱动的聊天应用”二者承担的角色与功能截然不同。Chatbot的主要目的是把特定的对话任务自动化例如回答高频 FAQ、跟踪包裹物流。它通常由规则逻辑或相对固定的算法控制。AI 驱动的聊天应用是更庞大的环境用于承载文字、语音、视频等多种数字沟通形态其定义性特征是集成了生成式 AI 模型它模拟细腻、接近人类的对话根据广泛的输入与上下文线索生成回答可以聊开放话题、随对话语境演进、甚至产出有创意的复杂对白。Chatbot生成式 AI 驱动的聊天应用面向任务、基于规则上下文感知常被嵌入到更大的系统中可以承载一个或多个 chatbot局限于被编程的功能内置生成式 AI 模型交互专门化、结构化能进行开放话题讨论本课之后的内容均围绕右侧的“生成式 AI 驱动聊天应用”展开。三、站在巨人肩上用 SDK 与 API 复用成熟能力构建聊天应用时一个明智的起点是“先盘点市面上已有什么”。使用 SDK 和 API 之所以是长期更优的策略理由很具体加快开发、降低开销复用现成能力而不是从零自研昂贵的基础设施可以把精力投向更重要的业务逻辑。更好的性能从零实现时你迟早会问“它怎么扩容能扛住用户突然涌入吗”——维护良好的 SDK/API 通常内置了这些问题的解法。更易维护大多数 API/SDK 发布新版本时只需升级依赖库。接触前沿技术直接调用在海量数据集上训练、微调过的模型应用立刻获得自然语言处理能力。3.1 API Key 与最小可用调用访问 SDK/API 能力通常需要先取得服务许可最常见的形式是唯一的 API Key 或身份验证令牌。以下是基于 OpenAI Python 库的最简调用形态本仓库英文版 README 中的示例import os from openai import OpenAI API_KEY os.getenv(OPENAI_API_KEY, ) client OpenAI(api_keyAPI_KEY) response client.responses.create( modelgpt-4o-mini, inputSuggest two titles for an instructional lesson on chat applications for generative AI., storeFalse, ) print(response.output_text)上面的例子用 gpt-4o-mini 通过 Responses API 完成提示词补全。注意 API Key 必须在调用之前设置好——不设置会直接报错。更稳妥的做法是像练习 oai-assignment.ipynb 中那样用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)3.2 在仓库中对照三种接入形态同一套业务逻辑在本仓库里给出了多语言、多后端的实现恰好演示了“SDK 与 API”策略的具体差异OpenAI 直连oai-assignment.ipynb直接用openai库 OPENAI_API_KEY选通用聊天模型即可代码中以model gpt-4o-mini为例属于最简单的形态。Azure OpenAIaoai-assignment.ipynb客户端需要同时提供AZURE_OPENAI_API_KEY和AZURE_OPENAI_ENDPOINT并把base_url指向endpoint/openai/v1/模型名改为读取环境变量AZURE_OPENAI_DEPLOYMENT对应你部署时分配的名字例如gpt-4o-miniimport os from openai import OpenAI from dotenv import load_dotenv load_dotenv() endpoint os.environ[AZURE_OPENAI_ENDPOINT] client OpenAI( api_keyos.environ[AZURE_OPENAI_API_KEY], base_urlf{endpoint.rstrip(/)}/openai/v1/, ) # 部署名称从 .env 读取 model os.environ[AZURE_OPENAI_DEPLOYMENT]GitHub Models / Microsoft Foundry 推理端点githubmodels-assignment.ipynb改用azure-ai-inference的ChatCompletionsClient凭证与端点在项目 “Overview” 页获取模型名直接可切换如 gpt-4o-mini、Phi-4、Llama-3.2 等import os from azure.ai.inference import ChatCompletionsClient from azure.ai.inference.models import SystemMessage, UserMessage from azure.core.credentials import AzureKeyCredential token os.environ[AZURE_INFERENCE_CREDENTIAL] endpoint os.environ[AZURE_INFERENCE_ENDPOINT] client ChatCompletionsClient(endpointendpoint, credentialAzureKeyCredential(token)) model_name gpt-4o-mini response client.complete( modelmodel_name, messages[{role: system, content: You are a helpful assistant.}, {role: user, content: text_prompt}], ) response.choices[0].message.content值得注意三种后端在练习 oai-assignment.ipynbOpenAI Responses API、aoai-assignment.ipynbAzure Responses API与 githubmodels-assignment.ipynbAzure AI Inferencecomplete中都能跑出同样的“首个聊天提示词”效果——这正是“服务商抽象”给聊天应用带来的最大价值业务代码尽量少改随时可换模型供应方。仓库还提供了 TypeScript 与 JavaScript 参考实现便于对照 SDK 的端到端工程化写法TypeScript 版 main.ts 使用openai官方 TypeScript 客户端构造system user角色消息并指定max_output_tokens、store: false配套 package.json 用ts-nodenodemon开发运行、tsc构建展示了一条可移植到真实项目的工程链路。JavaScript 版 js-githubmodels/app.js 走 Azure AI Inference REST 路径/chat/completions并在启动时对AZURE_INFERENCE_CREDENTIAL与AZURE_INFERENCE_ENDPOINT做强制校验可作为“生产级启动检查”的样板。.NET 学习者可以参考 notebook-azure-openai.dib。四、用户体验UX聊天应用特有的设计考量通用 UX 原则当然适用于聊天应用但由于涉及机器学习组件有几个额外的考量会变得格外重要。处理歧义的机制生成式 AI 偶尔会产出含糊的回答。提供“请解释 / 再说清楚点”的能力能在用户遇到歧义时兜底。上下文保留Context Retention先进模型能记住对话内的上下文这是体验的必要资产。让用户有能力查看与管控上下文能提升体验但也引入了“长期留存敏感用户信息”的风险。引入数据保留策略retention policy之类的手段可以在“需要上下文”与“保护隐私”之间取得平衡。个性化Personalization能学习与适应的 AI 模型天然可以给出千人千面的体验。借助用户画像user profiles等机制定制体验既让用户感到“被理解”也能帮用户更快地找到想要的答案。4.1 实例ChatGPT 的自定义指令个性化的典型例子就是 OpenAI ChatGPT 的 “Custom Instructions”自定义指令设置——你可以提交关于自己的信息作为提示词的上下文。下图演示了一条自定义指令告诉 ChatGPT 你是“有 12 年以上编程经验、正在做算法教学的高中教师”。注意回答质量的关键ChatGPT 会结合用户背景生成比其他通用请求“更深入”的教学计划——这就是上下文个性化带来的可感知差异。4.2 Microsoft 的大语言模型系统提示框架要给 LLM 生成高质量回复Microsoft 官方指引建议把系统提示system message拆成四个板块来写定义模型的服务对象面向谁以及它的能力与限制定义模型输出格式提供能示范模型预期行为的具体例子提供额外的行为护栏guardrails。仓库代码里就有现成的多角色消息范例。在 TypeScript 版 main.ts 中可以看到system与user角色混排的用法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, }); console.log(result.output_text);这里把“身份定义”与“情景约束”都放在 system 消息里最后用 user 消息抛出任务——正是“框架第 1、2 条”的落地写法。4.3 无障碍Accessibility无论用户是视障、听障、运动障碍还是认知障碍设计良好的聊天应用都应对所有人可用。按障碍类型划分常见的增强特性包括针对视觉障碍高对比度主题、可调字号、兼容屏幕阅读器。针对听觉障碍文本转语音与语音转文本、音频通知的可视化提示。针对运动障碍键盘导航支持、语音命令。针对认知障碍提供简化语言选项。在构建 UX 时把这些当成一等公民而不是上线前的“加分项”正是本课反复强调的工程态度。五、针对垂直领域的定制DSL 模型与微调想象一个能听懂你公司行话、并预判用户常见问题的聊天应用。让通用模型具备领域能力通常有两条路线利用 DSL 模型或做微调fine-tuning。DSLDomain-Specific Language领域专用语言模型针对特定领域、行业或主题训练或微调过的模型能理解该领域的概念与场景。使用 DSL 模型的方式可以从零训练也可以直接经由 SDK/API 使用现成者。微调Fine-tuning用特定数据对模型进行追加训练的过程。当预训练模型在某个专门领域或任务上力不从心时微调通常是首选方案。5.1 场景推演医疗垂直应用设想一个辅助医疗从业者的聊天应用——快速给出治疗指南、药物相互作用或最新研究结果的参考。这类问答复杂且极度依赖上下文医生做诊断依赖生活习惯、既往病史甚至要引用最新医学期刊来验证。在这种情况下通用 AI 聊天应用很难成为可靠来源它可能在以下环节失手高度专业或复杂的病例。例如神经科医生问“目前儿童耐药性癫痫的最佳管理实践是什么”缺乏最新进展。通用模型难以及时给出包含神经学与药理学最新成果的回答。针对这类场景用专业医学数据集做微调能显著提升模型回答复杂医学问题的准确性与可靠性。当然前提是你能拿到足够大、足够相关、能代表领域真实难题与高频问题的数据集。想动手体会“微调”到底是什么可继续阅读本仓库第 18 课 18-fine-tuning那里给出了用 JSONL 训练数据做微调并观察效果差异的完整流程。六、打造高质量 AI 聊天体验指标与负责任实践所谓“高质量”不应是口号而应落到两件事上采集可行动的指标以及遵守负责任使用 AI 的框架。6.1 关键指标一览下面这张指标表覆盖了系统可用性、模型质量与用户体验三个层面。它同时给出“指标定义”与“聊天应用开发者该反问自己的问题”——用问题驱动选型比死记指标名更有价值。指标定义聊天开发者要思考的问题正常运行时间Uptime应用可被用户访问并工作的时间占比如何把停机时间降到最低响应时间Response Time应用回复一次用户查询所花时间如何优化查询处理以改善响应时间精确率Precision真正例预测数占全部正预测数的比例如何验证模型的精确率召回率 / 灵敏度Recall / Sensitivity真正例预测数占实际正例数的比例如何测量并提高召回率F1 分数F1 Score精确率与召回率的调和平均平衡两者取舍目标 F1 是多少如何平衡精确率与召回率困惑度Perplexity模型预测的概率分布与数据真实分布的契合程度如何把困惑度压下去用户满意度指标用户对应用的主观感知通常通过问卷采集多久收集一次反馈如何据其迭代错误率Error Rate模型在理解或输出上犯错的比率有哪些降低错误率的策略重训周期Retraining Cycles模型纳入新数据与新洞察的更新频率多久重训一次什么事件触发一次重训异常检测Anomaly Detection识别不符合预期行为之异常模式的工具与技术遇到异常如何响应注意官方文档里指标表不止于“埋点”它还是一种“可观测性设计”——每一个指标都对应一个应该被回答的运营问题何时重训、如何降错、异常怎么兜底这正是第 14 课 LLMOps 生命周期讨论的工程化主题在单课内的前奏。6.2 在聊天应用中落地负责任的 AI 六原则Microsoft 的负责任 AI 框架提炼出六条指导 AI 开发与使用的原则。下面把“原则定义”“聊天开发者要做什么”“为什么重要”三列对齐原则Microsoft 定义聊天开发者的落地动作为什么重要公平性 FairnessAI 系统应当公平对待所有人确保聊天应用不基于用户数据歧视任何人在用户中建立信任与包容规避法律风险可靠性与安全性 Reliability SafetyAI 系统应当可靠且安全地运行实施测试与故障兜底fail-safes把错误和风险降到最低保障用户满意度防止潜在伤害隐私与安全 Privacy SecurityAI 系统应当安全并尊重隐私实施强加密与数据保护措施保护敏感用户数据合规于隐私法规包容性 InclusivenessAI 系统应当赋能并吸纳所有人面向多元人群设计可访问、易用的 UI/UX让更广泛的人群都能高效使用应用透明性 TransparencyAI 系统应当可被理解为 AI 回答提供清晰的文档与理由说明用户理解决策机制后更愿意信任系统问责 Accountability人应当对 AI 系统负责建立审计与改进 AI 决策的清晰流程支持持续改进出错时有纠正手段进一步研读可参考本仓库第 3 课 03-using-generative-ai-responsibly 中的缓解循环与分层治理图而在聊天应用里“系统提示 输出格式约束 行为护栏”那套 系统提示框架正是把“可靠性与安全、透明性”落到工程上的第一道防线。七、动手练习跟着练习跑一遍完整用例本课作业在 07-building-chat-applications/python 目录会带着你从“跑出第一个聊天提示词”一路走到文本分类、文本摘要与产品名生成。练习以多语言、多后端形式提供方便对照OpenAIoai-assignment.ipynb完整版、oai-assigment-simple.ipynb精简入门版Azure OpenAIaoai-assignment.ipynb含 Embeddings 与 CNN 新闻文章相似度对比等扩展、aoai-assigment-simple.ipynbGitHub Models / Foundrygithubmodels-assignment.ipynb、githubmodels-assignment-simple.ipynb另有TypeScriptchat-completions-app、JavaScriptjs-githubmodels与.NETnotebook-azure-openai.dib等语言版本。几个值得在练习中重点观察的现象重复调用同一提示词练习中设计了对同一请求连发两次的步骤oai-assignment.ipynb输出会有差异——这直观展示了 LLM 的采样随机性也引出“温度/采样参数”对一致性的影响。摘要、分类与命名三个用例同一个“system 助手 user 指令”骨架可以复用到Tl;dr摘要、[Pricing, Hardware Support, Software Support]三分类、基于种子词的“HomeShaker”类产品命名等场景说明聊天 API 本质是通用的文本指令引擎。多后端差异OpenAI 用client.responses.create(model..., input[...])GitHub Models 用client.complete(model..., messages[...])——消息结构几乎一一对应迁移成本被 SDK 压得很低。八、小结与下一步本课完成了四件事明确了 chatbot 与 AI 聊天应用的本质差异论证了为什么应该优先用 SDK/API 而非自研给出了用户体验、系统提示与无障碍的设计清单并提供了用关键指标与负责任 AI 六原则把“高质量”工程化的框架。DSL 模型与微调则在通用模型不足以覆盖垂直领域如医疗时提供了进阶路径。继续学习的推荐路径深入提示词设计第 4 课 04-prompt-engineering-fundamentals 与第 5 课 05-advanced-prompts从聊天到文本生成第 6 课 06-text-generation-apps想让应用更懂你的私有数据第 8 课开始讲构建搜索应用引入向量检索后续第 15 课 RAG 与向量数据库 会完整展开。读完第 8 课你就能学会“让聊天应用在回答时引用真实数据”的关键一招。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考