从零构建AI卖货主播：大模型微调、RAG与多模态工程实践

1. 项目概述：一个全栈AI卖货主播系统的诞生

去年，我还在CV领域深耕，眼看着大模型技术像潮水一样涌来，心里那股“再不学点新东西就要被拍在沙滩上”的焦虑感越来越强。于是，我决定跳出舒适圈，一头扎进大模型的世界。学了一堆理论后，总觉得纸上谈兵不过瘾，得亲手做个东西出来，把知识串起来，看看这“炼丹炉”里到底能炼出什么宝贝。

琢磨了很久，我盯上了直播带货这个场景。想想看，一个不知疲倦、知识渊博、还能实时互动的主播，对商家来说吸引力太大了。但市面上的方案要么是简单的问答机器人，要么是成本高昂的定制方案，离一个“能用、好用、敢用”的智能主播还有距离。我的目标很明确：打造一个从文案生成、语音合成到数字人呈现，全链路自动化、可本地部署、且能深度理解商品的AI卖货主播系统。这就是“Streamer-Sales 销冠”项目的起点。

这个项目不是一个简单的聊天机器人套壳。它的核心是一个经过指令微调的大语言模型（基于InternLM2），让它真正具备“卖货”的思维和话术。在此基础上，我集成了检索增强生成（RAG）来保证回答不跑偏，能紧扣商品说明书；接入了语音识别（ASR）和语音合成（TTS）来实现自然对话；引入了智能体（Agent）来查询快递、天气等实时信息；最后，还用数字人生成技术给这个虚拟主播赋予了形象。整个系统采用前后端分离的微服务架构，用Docker Compose一键部署，力求在功能完备性和工程可用性上找到一个平衡点。

从最初的一个想法，到数据集构建、模型训练、多模块集成，再到最终形成一个开源项目，我踩了无数的坑，也收获了许多宝贵的经验。接下来，我就把这套系统的设计思路、实现细节以及那些“只有做过才知道”的实操心得，毫无保留地分享给大家。

2. 核心设计思路：如何让AI学会“卖货”

做一个AI主播，最核心的问题不是让它“能说话”，而是让它“会卖货”。这涉及到从认知到表达的全链条设计。我的思路可以拆解为三个层次：角色塑造、知识注入和交互增强。

2.1 角色塑造：不止是模型，更是“人设”

一个成功的主播，鲜明的个人风格是吸引粉丝的关键。对于AI主播，我们需要在模型层面就注入这种“人设”。我选择在InternLM2-chat-7B这个优秀的开源基座模型上进行指令微调（Instruction Tuning）。

为什么是InternLM2？它在中文对话、逻辑推理和指令遵循方面表现均衡，且7B的参数量在效果和部署成本之间取得了很好的平衡，适合作为我们定制化任务的起点。

微调的关键在于数据。我并没有采用传统的问答对格式，而是设计了一套生成“主播模拟对话”的流程。核心思路是：给定一个商品（如“漱口水”）和它的几个核心卖点（如“深度清洁”、“口感舒适”），让大模型（如通义千问、文心一言）扮演一个特定性格的主播（如“乐乐喵”——甜美可爱，爱用网络梗，称呼观众为“家人们”），生成一段完整的直播带货脚本，并模拟观众可能提出的问题及其专业解答。

# 数据集生成配置片段 (conversation_cfg.yaml) conversation_setting: system: “现在你是一位金牌带货主播，你的名字叫{role_type}，你的说话方式是{character}。你能够根据产品信息讲解产品并且结合商品信息解答用户提出的疑问。” first_input: “我的{product_info}，你需要根据我给出的商品信息撰写一段直播带货口播文案。你需要放大商品的亮点价值，激发用户的购买欲。”

这样生成的数据，每一轮对话都天然地包含了主播的角色设定、商品信息以及符合销售场景的互动逻辑。模型在训练过程中，不仅学习了商品知识，更内化了“乐乐喵”这个角色的语言风格和沟通技巧。这是让AI从“通用助手”转变为“专业主播”的第一步。

实操心得：数据生成的“坑”与“技巧”直接用大模型生成严格格式的JSON数据非常容易出错，一个标点符号不对就会导致整个数据条目报废，浪费API费用。我的经验是：让模型生成结构清晰的文本，然后用正则表达式或简单的解析器来提取所需字段。比如，要求模型输出时用明确的标记如“【文案开始】...【文案结束】”、“Q: ... A: ...”，这样后期处理既稳定又高效。

2.2 知识注入：RAG让回答永不“脱轨”

微调让模型有了“卖货”的意识和风格，但它对具体商品的认知仍然来源于训练数据，是静态且有限的。当用户上传一个全新的商品，比如一款最新型号的“筋膜枪”，模型很可能一无所知，或者开始“胡言乱语”。

为了解决这个问题，我引入了检索增强生成（RAG）。它的原理很简单：将商品的详细说明书（Markdown格式）转换成向量，存入向量数据库（如FAISS）。当用户提问时，系统先从向量数据库中检索出与问题最相关的说明书片段，然后将这些片段作为“参考材料”和用户问题一起提交给大模型，让模型基于可靠的资料生成回答。

这样做有几个巨大优势：

1. 知识实时更新：无需重新训练模型，只需更新向量数据库，AI主播就能立刻掌握新商品的所有信息。
2. 回答精准可靠：答案有据可查，大幅减少了模型“幻觉”（即编造信息）的风险，这对于商品参数、价格、售后政策等关键信息至关重要。
3. 降低训练成本：我们可以用相对通用的“卖货话术”数据微调模型，而将具体的商品知识外挂到RAG系统中，解耦了“销售能力”和“商品知识”。

在实现上，我借鉴了InternLM社区优秀项目“茴香豆”的思路，使用text2vec模型将说明书文本转化为向量，用FAISS建立索引。整个流程在项目启动时自动完成，对用户透明。

2.3 交互增强：从文字到多模态体验

一个合格的现代主播，不能只停留在文字聊天。为了提升体验和实用性，我集成了多个模块：

• ASR（语音识别）：用户可以直接用语音提问，更符合直播间的互动场景。我选用的是阿里的FunASR，它对中文的识别准确率高，且对嘈杂环境有一定鲁棒性。
• TTS（语音合成）：将AI生成的文案转换成带有情感的语音。这里我使用了GPT-SoVITS，它可以通过少量样本进行声音克隆，并且能根据文本内容注入一定的情感。我为“乐乐喵”准备了不同情绪（如激动、亲切）的参考音频，让合成的声音更生动。
• 数字人生成：这是体验的终极形态。我利用ComfyUI工作流，结合Stable Diffusion和SadTalker等技术，将TTS生成的语音与一个静态人物形象合成一段口型匹配、带有轻微表情和肢体动作的短视频。虽然目前还达不到电影级真实感，但对于产品讲解视频、自动客服等场景已经足够有吸引力。
• Agent（智能体）：让AI主播不仅能“说”，还能“做”。我接入了快递查询和天气查询的API。当用户问“我的快递到哪了？”或“北京明天天气怎么样？”时，AI会识别出这类需要外部信息的意图，自动调用对应的Agent工具查询网络并整合信息回答，实现了功能的闭环。

架构上的考量：所有这些功能模块，我均设计为独立的微服务（TTS服务、ASR服务、LLM服务、数字人服务、中台服务）。通过Docker Compose进行编排。这样做的好处是解耦和弹性伸缩。例如，TTS比较耗CPU，我可以将其部署在CPU服务器上；LLM服务吃显存，就独占一张GPU卡。某个服务崩溃也不会导致整个系统宕机，维护和升级也变得更加方便。

3. 从零构建：数据集生成与模型训练实战

有了清晰的设计图，下一步就是动手实现。整个过程就像搭积木，但每一块“积木”都需要精心打磨。我们从最基础的“原材料”——数据开始。

3.1 自动化构建高质量对话数据集

手动编写成千上万条带货对话是不现实的。我的策略是利用现有大模型的生成能力，批量生产高质量数据。

第一步：设计数据生成流水线。脚本gen_dataset.py是这个流水线的核心。它读取一个精心设计的YAML配置文件（conversation_cfg.yaml），这个文件定义了：

• 角色库：目前有“乐乐喵”（萝莉风），未来可以扩展“霸道总裁”、“专业导购”等。
• 商品库：按大类（个人护理）、子类（口腔护理）、具体商品（漱口水）三级划分，并为每个商品预定义了6个核心卖点。
• 用户问题类型：总结了价格、质量、售后、物流等10大类消费者常问的问题。
• 生成模板：规定了每轮对话的生成格式，确保数据结构统一。

第二步：调用API批量生成。脚本会遍历角色和商品组合，调用通义千问或文心一言的API，按照模板生成数据。对于“漱口水”这个商品，结合“乐乐喵”的角色，API可能会生成如下对话：

{ “conversation”: [ { “system”: “现在你是一位金牌带货主播...名字叫乐乐喵...说话方式是甜美、可爱...”， “input”: “我的商品名是[漱口水]，商品的亮点是[深度清洁、口感舒适、旅行装方便]...”， “output”: “家人们，大家好呀！今天咱们要聊聊的是一款超级棒的生活好物哦...这款漱口水，深度清洁效果超级棒！...口感也超级舒适呢！...还是旅行装哦！小巧玲珑，放在包包里超级方便...” }, { “input”: “这款漱口水的包装怎么样？有没有附件？”， “output”: “家人们，这款漱口水的包装超级可爱哦！小巧玲珑的旅行装...每一瓶都配有一个便携式的小盖子，真的超级贴心呢！” } // ... 更多QA对 ] }

第三步：数据清洗与格式化。API生成的数据难免会有格式错误或噪音。merge_dataset.py脚本负责清洗数据，比如过滤掉JSON解析失败的条目，合并多个来源的数据，并统一转换成XTuner训练所需的jsonl格式。同时，它还会自动生成一批“自我认知”数据（如“你是谁？”、“介绍下你自己”），确保模型能牢固记住自己的主播身份。

避坑指南：API成本与稳定性

1. 预算控制：在生成前，先用少量数据测试prompt的效果，确保生成质量后再大规模运行。可以设置生成数量的上限。
2. 错误处理：API调用网络超时、频率限制是常事。脚本中必须加入重试机制和指数退避策略。
3. 格式校验：不要完全信任API返回的JSON。在写入最终文件前，一定要用json.loads()进行严格校验，将无效数据记录到日志中另行处理，避免污染训练集。

3.2 使用XTuner进行高效模型微调

数据准备好后，就可以开始“教导”模型了。我选用上海人工智能实验室的XTuner工具，因为它对InternLM系列模型支持友好，且配置灵活。

关键配置解析：在internlm2_chat_7b_qlora_custom_data.py配置文件中，有几个参数需要重点关注：

• pretrained_model_name_or_path：指向你下载的InternLM2-chat-7b模型路径。
• data_path：指向上一步生成的jsonl格式训练数据。
• batch_size和max_length：这是显存消耗的“阀门”。在24G显存的RTX 4090上，batch_size=2, max_length=2048是安全的起点。如果OOM（显存溢出），优先降低batch_size。
• pack_to_max_length：设置为True，XTuner会自动将多条短样本拼接成长序列，提高训练效率，这对于处理大量对话数据非常有用。

启动训练命令：

xtuner train ./finetune_configs/internlm2_chat_7b/internlm2_chat_7b_qlora_custom_data.py --deepspeed deepspeed_zero2

这里使用了DeepSpeed的ZeRO-2优化策略，它可以大幅降低模型训练时的显存占用，让我们能在消费级显卡上微调7B模型。

训练过程监控：训练开始后，关注Loss曲线的下降情况。一个健康的训练过程，Loss应该稳步下降并逐渐趋于平缓。可以使用TensorBoard或简单的日志输出进行监控。通常，在几百到上千个迭代步（iteration）后，模型就能较好地学习到带货话术。

3.3 模型合并、量化与加速推理

训练完成后，我们得到的是LoRA权重（适配器），需要将其与原始基座模型合并，得到一个完整的、独立的新模型。

# 1. 将训练得到的.pth检查点转换为Hugging Face格式 xtuner convert pth_to_hf ./finetune_configs/...py ./work_dirs/.../iter_340.pth ./hf_adapter # 2. 合并LoRA权重到基座模型 xtuner convert merge /path/to/internlm2-chat-7b ./hf_adapter ./merged_model

现在你得到了一个完整的“乐乐喵-7B”模型。但直接部署这个模型对显存要求很高（约16G）。为了降低部署门槛，我进行了4-bit量化。

# 使用LMDeploy进行AWQ量化（一种高效的4-bit量化方法） lmdeploy lite auto_awq ./merged_model --work-dir ./quantized_model_4bit

量化后的模型大小缩小约4倍，显存占用降至6.5G左右，使得在24G显存的显卡（如RTX 4090）上部署成为可能，且推理速度有显著提升。

速度对比实测：我使用一个固定的脚本对原始Transformer推理、LMDeploy加速、以及4bit量化后的LMDeploy推理进行了速度测试，结果如下：

可以看到，经过LMDeploy的Turbomind引擎优化和4bit量化后，推理速度提升了5倍以上。这对于需要实时交互的直播场景至关重要。

4. 工程化部署：构建高可用微服务系统

模型训练好了，但如何让它成为一个稳定、易用的服务？这是工程上的挑战。我采用了前后端分离的微服务架构，并用Docker Compose实现一键部署。

4.1 服务拆分与通信设计

整个系统被拆分为六个核心服务，各司其职：

1. LLM服务：承载微调后的“乐乐喵”大模型，提供文本生成核心能力。这是最吃显存的服务。
2. TTS服务：基于GPT-SoVITS，将LLM生成的文案转换为带情感的语音。
3. ASR服务：基于FunASR，将用户上传的语音转换为文本。
4. 数字人服务：接收TTS生成的音频，结合预设的人物形象图片，生成口型同步的数字人视频。
5. 中台服务（Base Service）：这是系统的“大脑”。它接收前端的请求，协调调用LLM、RAG、Agent、TTS、ASR等各个子服务，处理业务逻辑，并与数据库交互。
6. 前端服务：基于Vue 3的Web界面，提供用户操作界面。

服务间通过HTTP API（RESTful）进行通信。中台服务是唯一的调度中心，这种星型结构简化了服务间的依赖关系。所有接口都遵循RESTful规范，并使用JWT进行身份验证，保证了安全性和规范性。

4.2 Docker Compose一键部署详解

为了屏蔽环境差异，我强烈推荐使用Docker Compose部署。项目根目录下的docker-compose.yml文件定义了所有服务。

version: '3.8' services: llm-service: build: . image: streamer-sales:v0.10.0 command: bash deploy.sh llm deploy: resources: reservations: devices: - driver: nvidia device_ids: ['0'] # 指定使用第一张GPU capabilities: [gpu] volumes: - ./weights:/app/weights # 挂载模型权重目录 networks: - streamer-sales-net tts-service: build: . image: streamer-sales:v0.10.0 command: bash deploy.sh tts # TTS服务对GPU依赖较低，可以部署在CPU机器或共享GPU # ... # ... 其他服务类似配置 networks: streamer-sales-net: driver: bridge

部署步骤：

1. 构建镜像：docker build -t streamer-sales:v0.10.0 -f docker/Dockerfile .这个命令会根据Dockerfile创建一个包含所有Python依赖的基础镜像。
2. 启动服务：docker-compose up -d。-d参数让服务在后台运行。
3. 查看日志：docker-compose logs -f llm-service可以查看特定服务的日志，监控模型下载和启动过程。

部署常见问题与解决：

• 问题：服务启动后互相连接失败（Connection Refused）。
  • 原因：这是微服务部署的典型问题。由于Docker Compose会同时启动所有服务，而LLM服务需要下载数GB的模型文件，启动速度最慢。当其他服务（如中台服务）启动完成并尝试连接LLM服务时，后者可能还在下载模型，端口尚未监听。
  • 解决：耐心等待几分钟，然后使用docker-compose restart base-service重启中台服务即可。更健壮的做法是在服务启动命令中加入健康检查（healthcheck）和依赖等待逻辑，项目后续版本会考虑加入。
• 问题：显存不足（OOM）。
  • 解决：修改docker-compose.yml中device_ids，将LLM、TTS、数字人等GPU服务分散到不同的显卡上。如果只有一张卡且显存不足（如24G），请使用4bit量化模型启动LLM服务（命令改为bash deploy.sh llm-4bit），并考虑不启动对显存要求较高的ASR服务。

4.3 前端配置与数据库初始化

前端是一个独立的Vue项目。部署前需要配置环境变量，主要是设置后端API的基地址（指向中台服务）。

数据库使用PostgreSQL。在首次启动中台服务前，需要运行数据库初始化脚本（项目文档doc/database/README.md中有详细说明），创建所需的表结构，用于存储用户对话历史、商品信息等。

关键环境变量配置（用于中台服务）：

# 在启动前设置，或写入.env文件 export DELIVERY_TIME_API_KEY=“你的快递鸟EBusinessID,你的快递鸟APIKey” # 用于Agent快递查询 export WEATHER_API_KEY=“你的和风天气APIKey” # 用于Agent天气查询 export POSTGRES_PASSWORD=“你的数据库密码” # export POSTGRES_SERVER=“db” # 在Docker Compose网络中，数据库服务名就是hostname

这些配置确保了Agent功能可用，并且服务能正确连接到数据库。

5. 核心功能模块深度解析与调优

系统跑起来了，但每个模块都有其精妙之处和可优化空间。这里我挑几个核心模块，分享一些深入的实现细节和调优经验。

5.1 RAG检索增强生成：效果与效率的平衡

RAG听起来高大上，但实现起来核心就两步：建库和检索。

建库（Indexing）：

1. 文本预处理：将商品说明书（Markdown）按章节或段落切分成大小合适的“块”（Chunk）。块太大，检索不精准；块太小，信息碎片化。我通常按自然段落切分，并设置一个最大长度（如512字符）。
2. 向量化：使用text2vec这类句子嵌入模型，将每个文本块转换为一个高维向量（例如768维）。这个向量就是文本的“数学指纹”。
3. 构建索引：将所有向量存入FAISS这类向量数据库。FAISS提供了高效的最近邻搜索算法，能在毫秒级从百万级数据中找出最相似的几个向量。

检索与生成（Retrieval & Generation）：

1. 用户提问时，先将问题本身也向量化。
2. 在FAISS中搜索与问题向量最相似的K个文本块（例如K=3）。
3. 将这K个文本块作为“参考上下文”，与用户问题一起拼接成一个新的Prompt，送给大模型。

   请基于以下商品信息回答问题： [检索到的商品说明书片段1] [检索到的商品说明书片段2] [检索到的商品说明书片段3] 问题：[用户的问题] 回答：

调优心得：

• 检索质量：text2vec模型的选择很重要。我测试过几个开源模型，text2vec-base-chinese在中文商品描述上的表现比较均衡。如果领域特殊（如医疗、法律），可以考虑用领域数据微调嵌入模型。
• 块大小与重叠：简单的按段落切分有时会割裂关键信息。可以采用滑动窗口的方式，让相邻的块有部分重叠（例如重叠50个字符），确保关键信息不被切断。
• 重排序（Re-ranking）：初步检索出Top K个结果后，可以用一个更精细但更慢的模型（如交叉编码器）对它们进行重新排序，选出最相关的前2-3个，能进一步提升最终答案的质量。当前版本为了速度暂未引入，可作为高级优化点。

5.2 语音合成（TTS）与数字人生成：情感与唇形的魔法

让AI主播“有声有色”是提升体验的关键。

TTS情感化： 原始的TTS听起来像机器人。我采用GPT-SoVITS，它的一大优势是少量样本声音克隆和情感控制。

1. 准备参考音频：我为“乐乐喵”录制了几段不同情绪的音频，如“激动-列车巡游银河，我不一定...”、“亲切-家人们，欢迎来到直播间...”。文件名格式严格遵循情绪-文本.wav。
2. 推理时指定：当LLM生成一段文案后，中台服务会分析文案的情绪（一个简单的基于关键词的规则，如包含“惊喜”、“爆炸”则判断为“激动”），然后调用TTS服务时，附带情绪参数。TTS服务会根据情绪选择对应的参考音频，从而合成出带有相应情感的语音。
3. 效果对比：对比普通的TTS，GPT-SoVITS在语调起伏、停顿节奏上更接近真人，特别是当参考音频的情感与文本匹配时，效果提升非常明显。

数字人生成流程： 这是一个多步流水线，我将其封装为一个服务：

1. 输入：TTS生成的.wav音频文件 + 一张预设的“乐乐喵”静态形象图片。
2. 唇形同步：使用SadTalker或MuseTalk这类模型，根据音频驱动图片中人物的嘴部动作，生成一个初步的视频。这一步是关键，唇形是否自然直接影响观感。
3. 画面增强（可选）：可以使用Stable Diffusion等工具对每一帧进行轻微的重绘或超分辨率处理，提升画面质量，消除口型生成可能带来的面部模糊或扭曲。
4. 背景与合成：将生成的人物视频与一个合适的直播间背景模板进行合成。
5. 输出：最终生成一个.mp4视频文件。

避坑指南：数字人生成的资源与时间

• 显存消耗：数字人生成，尤其是画面增强步骤，非常消耗显存（轻松超过8G）。建议为数字人服务单独分配一张显卡。
• 生成延迟：生成一段10秒的视频，在A100上可能需要20-30秒。这不是实时流式生成，而是异步任务。在前端设计上，当用户触发数字人生成后，应显示“视频生成中”的提示，并通过轮询或WebSocket在后端生成完成后通知前端播放。
• ComfyUI工作流：项目开源了完整的ComfyUI工作流配置图。ComfyUI的节点式编程非常灵活，但调试复杂。建议先使用我提供的标准工作流，确保能跑通后再尝试自定义人物形象或背景。

5.3 Agent智能体：让AI主播“联网”

Agent功能让AI主播突破了知识的时间限制，能获取实时信息。我以“快递查询”为例，拆解其实现逻辑：

1. 意图识别：当用户输入“我的快递123456到哪了？”或“到杭州要多久？”，LLM在生成回复前，会先判断是否需要调用外部工具。这可以通过在系统Prompt中明确告知模型：“当你需要查询实时快递信息或天气时，请输出特定的JSON格式，例如{“action”: “query_express”, “number”: “123456”}”。
2. 动作解析：中台服务接收到LLM的回复，首先检查是否包含预定义的Action JSON。如果包含，则中断正常的文本回复流程。
3. 调用外部API：根据Action类型，中台服务调用对应的第三方API（如快递鸟API）。这里需要注意错误处理（网络超时、API限流）和敏感信息（API Key）的管理。
4. 结果整合：将API返回的原始数据（可能是一大段JSON）进行提炼和总结，然后再次交给LLM，让它以“乐乐喵”的口吻组织成一段流畅的回复。

   LLM第一次输出: {“action”: “query_express”, “number”: “123456”} 中台调用快递API，得到: “{‘status’: ‘运输中’, ‘location’: ‘上海转运中心’}” 中台将信息给LLM: “请根据以下快递信息，以乐乐喵的口吻回复用户：快递123456当前状态为‘运输中’，最新位置在‘上海转运中心’。” LLM第二次输出: “家人们，我帮您查啦！您的宝贝快递123456正在快马加鞭地运输中，现在已经到上海转运中心啦，很快就能飞到您手上哦，再耐心等一下下~”

5. 回复用户：将最终生成的、包含实时信息的回复返回给前端。

这个模式可以扩展到任何需要实时数据的场景，如股票查询、新闻播报等，是提升AI主播实用性的强大扩展点。

6. 常见问题排查与性能优化实录

在实际部署和运行中，你肯定会遇到各种各样的问题。这里我记录了一些最典型的情况和我的解决思路。

6.1 模型服务相关

问题一：LLM服务启动失败，提示CUDA out of memory(OOM)。

• 排查步骤：
  1. 运行nvidia-smi查看GPU显存占用。确认是否有其他进程占用了大量显存。
  2. 检查启动命令。如果是完整7B模型，需要约16G显存。确保你的显卡足够（如A100、RTX 4090 24G）。
  3. 如果显存紧张，务必使用4bit量化模型启动：bash deploy.sh llm-4bit。这会将显存需求降至约6.5G。
  4. 调整LMDeploy的KV Cache比例。通过环境变量export KV_CACHE=0.05，可以限制用于缓存Attention键值的显存，为其他模块腾出空间（但可能会轻微影响生成速度）。
• 根治方案：对于资源有限的机器，4bit量化是必选项。同时，在docker-compose.yml中为llm-service单独分配一张显卡，避免与其他GPU服务竞争。

问题二：模型回复质量下降，出现胡言乱语或不符合主播人设。

• 排查步骤：
  1. 检查RAG：首先确认用户的问题是否触发了RAG检索。可以在中台服务日志中查看检索到的文本片段。如果检索结果不相关，问题可能出在向量模型或文本分块上。
  2. 检查系统Prompt：确保每次请求都正确传入了包含角色设定的系统Prompt。在前后端分离架构中，这个Prompt可能由前端或中台服务添加，需要检查传输链路。
  3. 检查温度（Temperature）参数：过高的温度（如>1.0）会增加生成的随机性，可能导致偏离人设。在web_configs.py中，将LLM_TEMPERATURE调低（如0.7-0.9）可以使输出更稳定、更可控。
  4. 回顾训练数据：如果普遍性回答不佳，可能是训练数据质量或数量不足。考虑增加更多样化的商品和更丰富的对话数据重新微调。

6.2 音频视频服务相关

问题三：TTS生成的语音没有情感，或者情感不对。

• 排查步骤：
  1. 检查参考音频：确认./weights/gpt_sovits_weights/star/参考音频/目录下的音频文件命名是否正确（情绪-文本.wav），并且音频内容清晰。
  2. 检查配置文件：查看server/web_configs.py中的TTS_INF_NAME变量，是否指向了正确的参考音频文件名（不含路径）。
  3. 查看TTS服务日志：启动TTS服务时，控制台会打印出加载的模型和参考音频路径，确认是否加载成功。
  4. 情感判断逻辑：检查中台服务中，分析文本情绪的逻辑是否过于简单。可以引入一个轻量级的情感分类模型来更准确地判断文本情绪，从而匹配更合适的参考音频。

问题四：数字人生成视频口型对不上，或者画面卡顿。

• 排查步骤：
  1. 音频长度匹配：确认输入给数字人生成服务的音频长度与最终视频长度是否一致。检查音频处理流程有无被意外裁剪或延长。
  2. 检查ComfyUI工作流：确保使用的SadTalker/MuseTalk节点配置正确，特别是输入图片的人脸检测是否成功。可以先用ComfyUI界面手动测试同一张图片和音频。
  3. 资源瓶颈：数字人生成是计算密集型任务。检查GPU利用率（nvidia-smi）和CPU负载。如果资源饱和，会导致处理帧率下降，从而口型不同步或卡顿。考虑升级硬件或优化生成参数（如降低输出分辨率、跳帧处理）。
  4. 异步处理确认：确保前端在请求生成视频后，是在轮询结果，而不是同步等待。生成10秒视频可能需要30秒，同步等待会导致前端请求超时。

6.3 系统与部署相关

问题五：Docker Compose启动后，前端页面无法访问，或提示“服务不可用”。

• 排查步骤：
  1. 检查服务状态：运行docker-compose ps查看所有容器是否都处于Up状态。如果有Exit或Restarting的，用docker-compose logs [服务名]查看具体错误日志。
  2. 检查网络：确保所有服务都在同一个Docker网络（streamer-sales-net）下。在容器内使用ping命令测试服务间连通性（如从中台容器ping llm-service）。
  3. 检查端口映射：确认前端服务（如frontend:80）是否正确映射到了宿主机的某个端口（如8080:80）。在宿主机上用curl http://localhost:8080测试。
  4. 检查模型下载：首次启动时，LLM等服务需要从网上下载模型，耗时很长。在此期间服务可能不健康。等待一段时间（视网络情况，可能10-30分钟）后，尝试重启中台服务：docker-compose restart base-service。

问题六：Agent查询快递/天气失败。

• 排查步骤：
  1. 检查API Key：确认环境变量DELIVERY_TIME_API_KEY和WEATHER_API_KEY已正确设置，并且格式无误（快递鸟的Key是EBusinessID,APIKey逗号分隔）。
  2. 查看中台日志：日志中会记录Agent调用的请求和响应。查看是否有网络错误、API限流错误或Key无效的错误信息。
  3. 测试API：直接在宿主机上用curl命令测试第三方API是否本身可用，排除网络策略问题（如服务器无法访问外网）。
  4. 检查意图识别：在日志中查看LLM第一次的回复，是否正确输出了包含action字段的JSON。如果没有，可能需要优化系统Prompt中关于Agent调用的指令描述。

6.4 性能优化速查表

这个项目从零到一的构建过程，充满了挑战也充满了乐趣。它不仅仅是一个技术Demo，更是一个完整的、可投入生产环境试用的工程系统。我开源了所有代码、模型权重和详细文档，就是希望它能成为一个起点，帮助更多开发者快速进入AIGC应用开发领域，也期待大家能基于它创造出更酷、更有价值的应用。如果在使用中遇到任何问题，或者有新的想法，欢迎到GitHub仓库提交Issue一起讨论。