5.14
A5竞赛务实总结：景区导览服务AI数字人
一、赛题核心要求速览
基本信息
• 赛题：景区导览服务AI数字人
• 出题企业：锐捷网络（苏州）有限公司
• 组类：A组（本科、研究生、高职）
• 答疑QQ群：1093135039
必须做的事（评审打分项）
模块 具体要求 评审怎么看
多模态交互 语音输入+文本输入，数字人用语音+表情+口型同步回答 现场演示，看延迟和自然度
智能问答 回答景区历史、文化、景点特色等问题 准确率≥90%，有测试用例验证
知识库 可上传更新景区讲解词、文史资料 后台能上传文档，问答能用到上传的内容
个性化推荐 根据兴趣推荐路线和讲解重点 能问出不同推荐结果即可
数字人形象管理 配置外观、服装、声音 能切换形象/音色就算完成
游客感受度报告 分析交互记录，生成情感趋势 有图表展示就够
数据大屏 服务人次、热门问答、满意度趋势 可视化图表，别太丑
硬性指标
• 至少使用1个多模态大模型
• 问答准确率≥90%
• 语音问答延迟≤5秒
• 口型同步自然度（专家主观评估）
初赛提交物
- 源码 2. 部署手册 3. 设计文档 4. 方案PPT 5. 演示视频≤7分钟
二、务实技术方案（直接给结论）
整体架构：单体应用，别拆微服务
┌─────────────────────────────────────────────────┐
│ 前端 │
│ 游客端(Next.js/React) │ 管理后台(Next.js/React) │
├─────────────────────────────────────────────────┤
│ 后端(Python Flask/FastAPI) │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ ASR │ │ LLM │ │ TTS │ │ 数字人│ │ RAG │ │
│ │语音识别│ │大模型 │ │语音合成│ │ 渲染 │ │知识库│ │
│ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ │
├─────────────────────────────────────────────────┤
│ 数据层(SQLite + Chroma/FAISS) │
└─────────────────────────────────────────────────┘
为什么用单体？ 你就3周时间，微服务光是配置注册中心、网关、服务间通信就耗掉1周。单体一个Flask/FastAPI全搞定，调试方便，部署简单。
推荐技术栈（逐项给结论）
模块 推荐方案 理由 备选
后端框架 FastAPI 异步支持好，自带API文档，Python生态方便接AI组件 Flask也行，看你熟哪个
前端框架 Next.js (React) SSR/SSG都支持，生态好，管理后台+游客端一套代码 Vue3+Vite也行
数据库 SQLite 零配置，够用，竞赛级数据量完全扛得住 MySQL也行但没必要
ORM SQLAlchemy Python标配 -
大模型LLM DeepSeek API 便宜（百万token约1-2元），中文强，OpenAI兼容接口 通义千问Qwen API
多模态大模型 通义千问-VL API 或 GPT-4o API 满足"至少1个多模态大模型"要求，图片理解能力强 DeepSeek-VL
语音识别ASR 浏览器Web Speech API（游客端）+ FunASR（备选） Web Speech API零配置零成本，中文识别率够用；FunASR开源可本地部署 讯飞语音API（有免费额度）
语音合成TTS Edge-TTS 微软免费服务，音色多，速度快，Python直接调，延迟低 GPT-SoVITS（需GPU，音质更好但复杂）
口型同步 Live2D + lipsync插件 2D数字人方案，资源消耗低，效果可接受，学生团队做得出来 MuseTalk（需GPU，效果更真但门槛高）
数字人形象 Live2D模型 免费素材多，浏览器直接渲染，CPU就能跑 HeyGem/Duix（需GPU+Docker，更真但更重）
知识库RAG LangChain + FAISS + BGE-small-zh 50行代码搞定，FAISS纯内存无需部署，BGE中文效果好 Chroma（稍重但支持持久化）
情感分析 调LLM做情感判断 不用训模型，prompt工程搞定，成本可忽略 SnowNLP（离线但效果一般）
数据可视化 ECharts 前端图表库，大屏和报告都能用 -
部署 Docker Compose 一键启动，评审能跑起来 本地直接跑也行
关于数字人方案的关键决策
选2D（Live2D）别选3D，选Web渲染别选本地推理。 理由：
- 3D数字人（Unreal/Unity）：模型制作周期2周+，渲染需要好显卡，学生团队大概率做不完
- 2D真人视频驱动（MuseTalk/HeyGem）：效果好但必须GPU推理，部署复杂，演示时电脑配置不够就翻车
- 2D Live2D：浏览器直接跑，任何电脑都能演示，素材现成的，口型同步用插件就行
如果你团队有GPU和深度学习经验，可以考虑MuseTalk方案（更真实），但Live2D是最稳的保底方案。
三、功能优先级与实现策略
P0：必须做好（没这些直接淘汰）
- 数字人+语音交互（核心亮点）
实现路径：
用户语音 → Web Speech API转文字 → DeepSeek生成回复
→ Edge-TTS合成语音 → Live2D播放（口型+表情同步）
关键代码思路：
• 前端：用
达到90%准确率的关键：
- 知识库内容要充分：至少准备20-30页景区资料（历史、景点、路线、门票、交通、餐饮）
- 分块策略要合理：chunksize=500，chunkoverlap=100，按段落分
- Prompt要约束："请仅根据提供的参考资料回答，如果资料中没有相关信息，请说'抱歉，我暂时无法回答该问题'"
- 测试用例要覆盖：准备50-100个问答对，覆盖各类景区问题
坑： 纯RAG准确率大概80%，要达到90%需要加"混合检索"：
• 向量检索（语义匹配）+ 关键词检索（精确匹配）
• 简单做法：同时用BM25关键词检索和FAISS向量检索，结果合并去重
• 或者更简单：把常见FAQ直接做成问答对存入向量库，FAQ覆盖率达80%以上就稳了 - 管理后台-知识库管理
最简实现：
• 上传文档（PDF/Word/TXT）→ 后端自动分块向量化 → 更新FAISS索引
• 文档列表页：展示已上传文档，支持删除
• 一个上传按钮+一个列表页，完事 - 多模态大模型（硬性要求）
最简达标方案：
• 游客端增加"拍照识景"功能：上传景点照片 → 调通义千问-VL API → 返回景点介绍
• 或者用多模态模型处理语音+文本混合输入
• 只要在系统中有1处用到了多模态大模型就算达标
P1：做好加分（能拉开差距） - 个性化推荐
最简实现：
• 游客进入时选标签：家庭游/情侣游/文化深度游/休闲游
• 不同标签对应不同的system prompt和推荐路线模板
• 例如选"家庭游"→ prompt里加"请推荐适合亲子游览的路线，重点介绍儿童感兴趣的景点"
• 路线数据直接在知识库里预设3-5条模板路线
加分实现：
• 根据对话历史推断游客兴趣（问了很多历史问题→推文化路线）
• 在LLM的system prompt里加入对话历史摘要 - 数字人形象管理
最简实现：
• 预置3-4个Live2D模型（网上有免费素材）
• 后台提供形象选择下拉框+音色选择下拉框
• 切换形象=切换Live2D模型文件，切换音色=切换Edge-TTS的voice参数
加分实现：
• 支持上传Live2D模型文件（.model3.json）
• 支持简单的换装（切换模型贴图） - 游客感受度报告
最简实现：
• 每次对话记录：时间、问题、回答、情感标签
• 情感标签：调LLM判断用户情绪（正面/中性/负面），prompt："判断以下用户消息的情感倾向：{message}，只回答：正面/中性/负面"
• 后台报表：用ECharts画情感趋势折线图、满意度饼图 - 数据大屏
最简实现：
• 一个独立页面，用ECharts展示：
◦ 服务人次（数字卡片）
◦ 热门问答Top10（横向柱状图）
◦ 满意度趋势（折线图）
◦ 实时交互数（数字卡片）
• 数据来源：后端统计接口，从SQLite聚合查询
P2：有时间就做（锦上添花） - GPS定位自动讲解
最简实现：
• 用浏览器Geolocation API获取游客位置
• 后台配置景点坐标和讲解触发半径（如50米）
• 进入范围自动推送该景点讲解
• 注意：浏览器定位精度10-50米，室内不好用，但竞赛够用 - 多轮对话上下文记忆
实现：
• 后端维护session，记录最近5轮对话
• 每次请求把历史对话拼进prompt
• SQLite存对话记录，session_id关联
四、推荐开发路线（3周排期）
第1周：搭骨架，跑通核心链路
天数 任务 交付物
Day1-2 项目初始化：FastAPI后端+Next.js前端+SQLite 能跑的空项目
Day2-3 接入DeepSeek API，实现文本问答 输入问题→返回回答
Day3-4 接入Edge-TTS，实现语音合成 输入文字→输出语音
Day4-5 前端集成Live2D，实现口型同步 数字人能跟着语音动嘴
Day5-7 串联：语音输入→ASR→LLM→TTS→Live2D播放 核心链路跑通
第1周结束必须达到： 游客能语音跟数字人对话，数字人能说话并口型同步。
第2周：做功能，满足赛题要求
天数 任务 交付物
Day8-9 RAG知识库搭建：文档上传→分块→向量化→检索→回答 知识库问答可用
Day9-10 准备景区知识库数据（至少20页），测试准确率 问答准确率≥90%
Day10-11 管理后台：知识库管理（上传/删除/列表） 后台可操作知识库
Day11-12 接入多模态大模型（拍照识景） 满足"至少1个多模态大模型"要求
Day12-14 个性化推荐 + 数字人形象切换 两个P1功能完成
第2周结束必须达到： 所有P0功能完成，P1功能基本完成。
第3周：打磨细节，准备提交
天数 任务 交付物
Day15-16 游客感受度报告 + 数据大屏 P1功能全部完成
Day16-17 GPS定位（如果还有时间） P2功能
Day17-18 全链路测试、修bug、性能优化 稳定可演示的系统
Day18-19 写设计文档、部署手册、方案PPT 三份文档
Day19-20 录演示视频（≤7分钟）、打包源码 所有提交物
人员分工建议（3-4人团队）
角色 人数 职责
全栈/后端 1人 FastAPI后端+RAG+LLM集成+数据库
前端 1人 游客端+管理后台+Live2D集成+数据大屏
AI/算法 1人 知识库搭建+问答优化+情感分析+测试
队长/文档 兼任 项目管理+设计文档+PPT+视频
3人团队的话，前端兼文档，后端兼AI。
五、踩坑预警
坑1：语音交互延迟超标（≤5秒要求）
最容易超时的地方： ASR → LLM → TTS → 播放，全串行的话可能8-10秒。
解决方案：
- LLM流式输出：必须开streaming，边生成边返回
- TTS分句合成：LLM每输出一个完整句子就立即送TTS，别等全部生成完
- 音频边合成边播放：前端收到第一段音频就立即播放
- ASR用浏览器原生：Web Speech API延迟最低，别用需要上传音频再返回的方案
目标延迟分解： ASR(0.5s) + LLM首token(1s) + TTS首句(1s) + 播放启动(0.5s) ≈ 3秒
坑2：RAG准确率达不到90%
根本原因： 景区知识太分散，检索不到相关内容。
解决方案： - 知识库内容要足：别只放3页简介，至少20页详细内容
- FAQ模式保底：把最可能被问到的50个问题写成问答对，直接存向量库
- 混合检索：向量检索+关键词检索结果合并
- Prompt约束：严格限制LLM只能基于检索结果回答，减少幻觉
- 测试驱动：先定50个测试问题，对着测试调优检索参数
坑3：Live2D口型同步效果差
原因： 默认lipsync只根据音量驱动，不够精准。
解决方案： - 用oLipsync或CubismSdkForWeb自带的lipsync功能
- 配置音素映射表（a/i/u/e/o对应不同嘴型）
- 调整灵敏度参数，嘴型幅度稍微夸张一点比太小好
- 如果实在不行，退而求其次：用简单的音量驱动，配合表情切换掩盖不自然
坑4：演示时翻车
最容易出的幺蛾子：
• 网络不好 → LLM API调不通 → 提前缓存常见问题的回答
• 浏览器不支持Web Speech API → 准备文本输入备选方案
• 知识库问答答非所问 → 演示时只问测试过的问题
• 数字人卡顿 → 降低模型复杂度，关掉不必要的动画
铁律： 演示视频一定要提前录好！现场演示只是锦上添花，视频才是保底。
坑5：GPU依赖导致部署困难
问题： 很多数字人方案（MuseTalk、GPT-SoVITS）需要GPU，评审电脑可能没有。
解决方案：
• Live2D方案全程CPU可跑，无GPU依赖
• TTS用Edge-TTS（云端API，不需要本地GPU）
• LLM用API调用（云端推理）
• 如果一定要用GPU方案，Docker部署时做好CPU fallback
坑6：多模态大模型要求理解偏差
"至少使用1个多模态大模型" ≠ 全程用多模态大模型。
• 主体问答用普通LLM（DeepSeek）就够了，快且便宜
• 多模态大模型只在1-2个功能点使用即可达标：
◦ 拍照识景（图像+文本→回答）
◦ 语音情感分析（语音+文本→情感判断）
• 推荐：通义千问-VL API，有免费额度，调用简单
六、初赛提交要点
- 源码
• GitHub仓库，README写清楚怎么跑
• requirements.txt或pyproject.toml列全依赖
• .env.example给出环境变量模板（API Key用占位符）
• 一定要能一键跑起来：docker-compose up或python main.py - 部署手册
• 写清楚：环境要求、安装步骤、配置说明、启动命令
• 别漏：API Key怎么配、知识库数据怎么导入
• 贴截图：每一步的结果截图，评审照着做能跑起来 - 设计文档
推荐结构： - 需求分析（1页）：功能清单+优先级
- 系统架构（1页）：架构图+技术选型理由
- 核心模块设计（3-4页）：知识库、数字人交互、语音链路
- 数据库设计（1页）：ER图+表结构
- 接口设计（1页）：关键API列表
- 测试报告（1页）：准确率测试、延迟测试
别写太多，10页以内，图文并茂。 评审看的是思路清晰，不是字数。 - 方案PPT
核心内容： - 赛题理解（1页）
- 方案亮点（1页）：跟别人不一样的点
- 技术架构（1页）：架构图
- 功能演示截图（3-4页）：核心功能都展示到
- 创新点/差异化（1页）
- 总结（1页）
关键： 10页以内，图多字少，讲清楚"我做了什么、怎么做的、效果如何"。 - 演示视频（≤7分钟）
推荐结构：
• 0:00-0:30 开场：项目介绍
• 0:30-2:00 核心功能：语音对话+数字人交互（最重要，多花时间）
• 2:00-3:30 知识库问答：展示准确率
• 3:30-4:30 管理后台：知识库管理+形象切换
• 4:30-5:30 数据大屏+感受度报告
• 5:30-6:30 亮点展示：个性化推荐/GPS定位/拍照识景
• 6:30-7:00 总结
录制技巧：
• 用OBS录屏，画质1080p
• 提前演练3遍，别卡壳
• 准备好演示脚本，只问测试过的问题
• 旁白用后期配音，别现场说话
七、加分项 checklist
在完成P0/P1的基础上，以下任何一项都能拉开差距：
☐ 流式语音交互：边生成边播放，延迟<3秒（不是5秒）
☐ 多轮对话：支持上下文追问，不丢失历史
☐ 情感化表达：根据内容自动调整数字人表情和语调
☐ GPS自动讲解：走到景点自动触发讲解
☐ 拍照识景：多模态大模型识别景点
☐ 多语言支持：英语/日语讲解（Edge-TTS天然支持）
☐ 数据大屏炫酷：实时数据刷新+动画效果
☐ 情感趋势分析：交互记录→情感分析→可视化报告
☐ Docker一键部署：docker-compose up全搞定
☐ 语音打断：数字人说话时用户可以插话
八、开源项目参考（别从零写，站在巨人肩膀上）
项目 地址 用途 难度
awesome-digital-human-live2d github.com/wan-h/awesome-digital-human-live2d Live2D数字人完整框架，支持Dify/Coze接入，Docker一键部署 ⭐⭐
Open Avatar Chat (HUMAN) github.com/Dingdust/HUMAN 模块化数字人对话，支持MuseTalk/Live2D/多种TTS ⭐⭐⭐
MuseTalk github.com/TMElyralab/MuseTalk 实时口型同步，单图驱动（需GPU） ⭐⭐⭐⭐
HeyGem github.com/duixcom/Duix-Avatar HeyGen开源平替，2D真人数字人（需GPU+Docker） ⭐⭐⭐
Duix-Mobile github.com/duixcom/Duix-Mobile 移动端2D数字人SDK，4核CPU可跑 ⭐⭐⭐
LangChain github.com/langchain-ai/langchain RAG框架 ⭐⭐
FunASR github.com/modelscope/FunASR 语音识别，支持中文 ⭐⭐
edge-tts pypi.org/project/edge-tts 免费TTS，Python直接pip install ⭐
建议： 直接fork awesome-digital-human-live2d 改，省1周工作量。它已经帮你搞定了Live2D渲染、TTS接入、LLM对话，你只需要加知识库和管理后台。
九、一句话总结
数字人用Live2D，问答用RAG+DeepSeek，语音用Edge-TTS，数据库用SQLite，全部API调用不自己训模型，3周稳稳搞定。
别追求炫酷，追求"能用+稳定+完成度高"。评审见过的花架子太多了，一个全功能能跑的系统比半成品的3D数字人强100倍。
浙公网安备 33010602011771号