企业官网建设流程全解析

1. 从数字人到知识引擎：这套组合拳到底在解决什么问题

第一次接触腾讯这套数字人加知识引擎的方案时，我脑子里冒出来的第一个念头是：这不就是把一个会说话的虚拟形象，接上一个能查资料的大脑吗？但真正拆开来看，里面的门道比表面复杂得多。数字人负责“表现层”，知识引擎负责“认知层”，两者之间的数据流转、意图识别、内容召回和生成控制，每一步都有大量工程细节需要打磨。

先说数字人这一侧。腾讯的数字人产品线覆盖了从2D真人克隆到3D卡通形象的多种形态，核心能力集中在三个方向：形象生成、驱动控制和交互表达。形象生成依赖少量样本视频完成面部建模，驱动控制则通过语音、文本或动作指令实时驱动口型、表情和肢体，交互表达则涉及多轮对话中的情绪适配和话术策略。这套东西放在客服、培训、导览、直播等场景里，能显著降低真人出镜的成本，同时保持品牌形象的一致性。

再说大模型知识引擎。这个名字听起来很宏大，但拆开看就是三件事：知识入库、语义检索、答案生成。知识入库要把PDF、Word、网页、数据库记录等异构内容切成可检索的片段，再通过嵌入模型转成向量存进向量数据库。语义检索负责在用户提问时，从海量片段里找出最相关的几条。答案生成则交给大模型，把检索结果和用户问题一起塞进提示词，输出自然语言回答。腾讯混元大模型在这里扮演的是“生成器”和“理解器”的双重角色，既要把问题解析清楚，又要把答案组织得像人话。

这两套东西合在一起，解决的是一个很具体的痛点：传统数字人只能念稿，问它稍微偏一点的问题就卡壳；传统知识库只能关键词匹配，用户换个说法就搜不到。把数字人接上知识引擎之后，用户可以用自然语言随便问，数字人能从知识库里找到依据，再用自己的“嘴”说出来。这个链路打通之后，数字人就不再是花瓶，而是真正能干活的生产力工具。

适合谁来参考这套方案？我梳理了一下，大致是三类人：一是企业里负责客服、培训、营销的技术选型人员，他们需要评估这套东西能不能替代或辅助现有系统；二是做AIGC应用开发的工程师，他们关心的是接口怎么调、向量库怎么选、提示词怎么设计；三是对数字人和大模型结合感兴趣的产品经理，他们想搞清楚能力边界在哪里，哪些场景能落地，哪些场景还只是demo。这篇文章就围绕这三类人的实际需求，把整套方案的架构、选型、实操和避坑经验掰开揉碎讲清楚。

2. 整体架构拆解：数字人、大模型、向量库是怎么串起来的

2.1 三层架构的职责划分与数据流向

这套方案在工程上可以拆成三层：交互层、认知层、数据层。交互层就是数字人前端，负责接收用户输入（语音或文字）、驱动形象做出反应、播放合成后的语音和动画。认知层是大模型和知识引擎的核心逻辑，包括意图识别、查询改写、向量检索、重排序、答案生成。数据层是向量数据库和原始知识库，负责存储和索引所有可检索的内容。

数据流向是这样的：用户对着数字人说话，语音先经过ASR转成文本，文本进入认知层。认知层先做意图判断，如果是闲聊就直接走大模型生成，如果是知识型问题就触发检索流程。检索时，查询文本被嵌入模型转成向量，在向量数据库里做相似度搜索，返回Top-K个相关片段。这些片段和原始问题一起组成提示词，送给混元大模型生成答案。答案文本再经过TTS转成语音，同时驱动数字人的口型和表情，最终呈现给用户。

这个链路里有两个关键设计决策值得展开说。第一个是“检索增强生成”的引入。纯大模型生成的问题在于容易胡说，尤其是企业场景里涉及具体产品参数、政策条款、操作流程时，模型没有依据就会编。RAG的思路是先检索再生成，让模型基于真实文档说话，幻觉率能降一个数量级。第二个是“查询改写”环节。用户问“你们那个退款怎么搞”，直接拿这句话去检索可能效果很差，因为知识库里写的是“退货退款流程说明”。查询改写模块会把口语化问题转成更规范的检索语句，或者生成多个变体查询，提升召回率。

2.2 为什么选向量数据库而不是传统全文索引

传统全文索引比如Elasticsearch的倒排索引，擅长关键词精确匹配，但对付语义相似度就力不从心。用户问“怎么退钱”，文档里写的是“退款申请流程”，关键词对不上，全文索引就搜不到。向量数据库把文本转成高维向量，语义相近的文本在向量空间里距离更近，即使用词不同也能召回。这是选择向量库的核心原因。

腾讯这套方案里，向量数据库的选型比较灵活，官方文档里提到了对多种向量库的适配，包括Milvus、Chroma、Qdrant等。Milvus适合大规模生产环境，支持分布式部署和多种索引类型；Chroma轻量易用，适合快速原型验证；Qdrant在过滤检索和负载均衡上有优势。选哪个取决于数据规模、查询并发和运维能力。我个人的经验是，如果知识库文档在十万级片段以内，Chroma单机就能扛住；上了百万级，就得考虑Milvus集群或者Qdrant的分布式方案。

2.3 混元大模型在链路中的双重角色

混元大模型在这套方案里不是单纯做生成，它承担了两个关键职能。第一个是“理解器”：把用户模糊的、口语化的、甚至带错别字的问题，解析成结构化的查询意图。比如用户说“我昨天买的那个东西不想要了咋整”，模型要能识别出这是退货意图，并提取出“退货”这个核心概念。第二个是“生成器”：拿到检索回来的文档片段后，模型要判断哪些片段真正相关，怎么组织语言才能既准确又自然，还要控制回答长度和语气风格。

这两个职能对模型能力的要求不一样。理解器需要强语义解析能力，生成器需要强语言组织和事实一致性能力。混元作为腾讯自研的通用大模型，在这两个维度上都有不错的表现，尤其是中文场景下的语义理解，比很多开源模型更贴合国内用户的表达习惯。实际调优时，可以通过提示词工程和少量微调来强化特定领域的理解能力，比如医疗、金融、政务等垂直场景。

3. 知识引擎核心细节：从文档切片到答案生成的完整链路

3.1 文档预处理与切片策略的实操要点

知识入库的第一步是文档预处理。企业里的知识来源五花八门：PDF产品手册、Word操作指南、网页帮助中心、Excel参数表、甚至聊天记录里的常见问答。这些格式要先统一转成纯文本，再清洗掉页眉页脚、广告水印、乱码字符。这一步看起来简单，但实际做起来坑很多。比如PDF里的表格，直接转文本会变成一堆错位的数字，需要专门用表格解析工具处理。再比如扫描件PDF，得先走OCR，OCR的准确率直接影响后续检索效果。

切片策略是知识引擎里最容易被忽视但影响最大的环节。切得太粗，一个片段里混了好几个主题，检索时噪音大；切得太细，一个完整流程被拆成七八段，模型拼不回去。我的经验是，按语义段落切，每段控制在300到500字之间，同时保留一定的重叠窗口。具体做法是先用规则按标题和段落切，再用语义分割模型判断相邻段落是否属于同一主题，如果主题变了就断开。重叠窗口的作用是防止关键信息刚好落在切割边界上被截断，一般设置50到100字的重叠。

还有一个细节是元数据的保留。每个片段除了文本内容，还要带上来源文档名、章节标题、页码、更新时间等元信息。这些元数据在检索时可以用来做过滤，比如用户问“最新版的退款政策”，就可以只检索更新时间在最近三个月内的片段。元数据还能在答案生成时作为引用来源展示给用户，增加可信度。

3.2 嵌入模型选型与向量化质量把控

嵌入模型负责把文本转成向量，它的质量直接决定检索的准确率。选嵌入模型时主要看三个指标：语义相似度任务的评测分数、推理速度、以及是否支持中文。腾讯方案里默认用的是混元自带的嵌入接口，但也可以替换成其他开源模型比如BGE、M3E、Text2Vec等。BGE在中文语义相似度榜单上表现一直不错，M3E对长文本的处理更稳，Text2Vec轻量适合资源受限的场景。

向量化质量把控有几个实操要点。第一是归一化，把向量长度统一到1，这样余弦相似度计算就等价于内积，检索速度更快。第二是维度选择，嵌入模型输出的维度从384到1024不等，维度越高表达能力越强但存储和计算成本也越高。一般768维是个平衡点。第三是批量处理，向量化是计算密集型操作，用GPU批量推理比单条处理快几十倍。第四是版本管理，嵌入模型一旦更换，所有历史向量都要重新生成，否则新旧向量不在同一空间里，检索会乱套。所以生产环境里要固定嵌入模型版本，升级时走全量重建流程。

3.3 检索策略：从Top-K召回到重排序的精细控制

检索环节的核心参数是Top-K，也就是返回多少个候选片段。K值太小，可能漏掉关键信息；K值太大，噪音多且增加生成成本。一般设置K在5到10之间，具体取决于知识库的密度和问题的复杂度。如果知识库很稠密，一个主题有很多相似片段，K可以小一点；如果知识库稀疏，K就要大一点。

光靠向量相似度召回还不够，因为向量检索有时会把语义相近但实际不相关的片段排前面。这时候需要重排序模型来精排。重排序模型通常是交叉编码器，把查询和候选片段一起输入，输出一个相关性分数，按分数重新排序。交叉编码器比双编码器（嵌入模型）精度高但速度慢，所以只对Top-K的候选做重排，不做全量。腾讯方案里重排序是可选的，如果对准确率要求极高就开启，如果追求低延迟就跳过。

还有一个进阶技巧是混合检索，把向量检索和关键词检索的结果融合。向量检索擅长语义匹配，关键词检索擅长精确匹配。两者结合能覆盖更多场景。融合方式可以是加权求和，也可以是倒数排名融合。我实测下来，混合检索在专业术语密集的场景里提升明显，比如法律条文、医疗术语、产品型号这些，纯向量检索容易把相似但不同的术语搞混。

3.4 提示词工程与答案生成的质量控制

检索回来的片段怎么用，全看提示词怎么写。提示词里要明确几件事：角色设定（你是一个专业的客服助手）、任务描述（根据提供的参考资料回答用户问题）、约束条件（如果参考资料里没有答案，就说不知道，不要编造）、输出格式（分点回答，每点不超过50字）。这些约束能显著降低幻觉率。

我踩过的一个坑是提示词里参考资料放太多，模型反而抓不住重点。后来改成只放最相关的3到5条，并且给每条片段加上编号和来源标注，模型引用时会更准确。另一个坑是模型倾向于把参考资料里的所有内容都塞进答案，导致回答冗长。解决办法是在提示词里加一句“只回答用户问到的内容，不要展开无关信息”，效果立竿见影。

答案生成后还可以加一层后处理，比如敏感词过滤、格式校验、引用来源附加。如果数字人场景对实时性要求高，生成阶段可以限制最大token数，避免模型长篇大论导致延迟飙升。

4. 数字人侧的关键技术：形象驱动、语音合成与交互设计

4.1 2D与3D数字人的选型逻辑与成本对比

腾讯数字人产品线里，2D和3D是两条不同的技术路线。2D数字人基于真人视频克隆，生成一个看起来像真人的虚拟形象，适合品牌代言、客服坐席、新闻播报等需要真实感的场景。3D数字人是纯计算机生成的卡通或写实形象，适合游戏、社交、教育等需要个性化表达的场景。

选型时主要考虑三个因素：成本、周期、可控性。2D数字人的制作成本相对低，一段几分钟的真人视频就能完成建模，周期在一到两周。但2D形象的动作和表情受限于原始视频，灵活性差一些。3D数字人制作成本高，需要美术建模和绑定，周期可能一个月以上，但动作和表情可以完全程序化控制，适合需要大量动画交互的场景。

从技术实现上看，2D数字人的核心是面部关键点检测和口型同步。系统从输入语音里提取音素序列，映射到口型动作单元，再驱动面部网格变形。3D数字人则多了一层骨骼动画系统，口型、表情、肢体动作分别由不同的动画层控制，最后混合输出。两者的语音合成模块是共用的，都走TTS接口。

4.2 语音合成与口型同步的技术细节

语音合成这块，腾讯用的是自研的TTS引擎，支持多音色、多语种、多情感。音色可以选择预置的，也可以用少量样本定制专属音色。定制音色的原理是说话人嵌入，从几秒钟的参考音频里提取音色特征向量，合成时把这个向量注入TTS模型，就能生成相似音色的语音。

口型同步是数字人自然度的关键。如果口型和语音对不上，用户一眼就能看出是假的。技术实现上，先把语音切成帧，每帧提取音素特征，然后查表得到对应的口型参数（比如嘴巴张开程度、嘴唇圆展度），再驱动面部模型。难点在于协同发音，也就是连续音素之间的过渡，比如“ba”和“ma”的口型变化不是突变的，而是平滑过渡的。好的口型同步系统会做上下文相关的建模，考虑前后音素的影响。

实测下来，口型同步的延迟要控制在100毫秒以内，用户才感觉不到违和。如果延迟超过200毫秒，就会觉得数字人反应迟钝。所以整个链路里，ASR、检索、生成、TTS、口型驱动这几个环节的耗时都要精打细算。我的经验是，检索和生成是大头，能占到总延迟的70%以上，优化时要优先从这里下手。

4.3 多轮对话中的上下文管理与情绪适配

数字人不是一问一答就结束，很多时候需要多轮交互。比如用户先问“退款怎么弄”，数字人回答后，用户接着问“那运费谁出”，这时候系统要能记住上一轮说的是退款话题，把“运费”和“退款”关联起来。上下文管理的做法是把最近几轮的对话历史拼进提示词，让模型有记忆。但历史太长会挤占token预算，所以一般只保留最近3到5轮，更早的做摘要压缩。

情绪适配是提升用户体验的加分项。数字人可以根据用户输入的情感倾向调整语气和表情。用户着急时，数字人语速稍快、表情关切；用户满意时，数字人语气轻松、面带微笑。情感识别可以走单独的模型，也可以让大模型在生成答案时顺便输出情感标签。腾讯方案里情感标签是可选输出，数字人驱动层根据标签切换动画状态。

5. 向量数据库选型实战：Milvus、Chroma、Qdrant怎么选

5.1 三款向量库的核心差异与适用场景

Milvus、Chroma、Qdrant是当前比较主流的三个开源向量数据库，各有侧重。Milvus功能最全，支持多种索引类型（IVF、HNSW、DiskANN等），支持分布式部署和水平扩展，适合大规模生产环境。但Milvus的运维复杂度也最高，需要单独部署etcd、MinIO、Pulsar等组件，对运维团队有一定要求。

Chroma主打轻量和易用，几行代码就能跑起来，适合快速原型验证和小规模应用。它内置了嵌入函数，可以直接把文本传进去自动向量化，省去了手动调嵌入模型的步骤。但Chroma的扩展性有限，单机撑不住太高的并发，数据量大了性能下降明显。

Qdrant在过滤检索和负载均衡上有独特优势。它支持丰富的过滤条件，可以在向量检索的同时按元数据过滤，比如只搜某个部门、某个时间段、某个文档类型的片段。Qdrant的分布式架构也比较成熟，支持分片和副本，适合中等规模的生产环境。

选型时我一般建议按这个逻辑走：原型阶段用Chroma，快速验证效果；小规模生产用Qdrant，兼顾功能和运维成本；大规模生产用Milvus，牺牲运维复杂度换扩展性。当然还要看团队的技术栈，如果已经在用Kubernetes，Milvus的部署会顺手很多。

5.2 索引类型选择与性能调优参数

向量索引的类型直接影响检索速度和召回率。常见的索引有Flat、IVF、HNSW、DiskANN。Flat是暴力检索，召回率100%但速度慢，只适合小数据集。IVF是倒排文件索引，把向量空间划分成多个簇，检索时只搜最近的几个簇，速度快但可能漏掉边界上的结果。HNSW是分层可导航小世界图，检索速度快且召回率高，是目前最常用的索引类型。DiskANN是微软提出的磁盘索引，适合数据量超过内存容量的场景。

HNSW有两个关键参数：M和efConstruction。M控制每个节点的连接数，越大图越密，召回率越高但内存占用越大，一般设16到64。efConstruction控制建图时的搜索深度，越大图质量越好但建图越慢，一般设100到500。检索时还有一个efSearch参数，控制检索时的搜索深度，越大召回率越高但速度越慢，需要根据实际效果调。

我的调优经验是，先用默认参数跑一遍，看召回率和延迟是否达标。如果召回率不够，先加efSearch，再加M。如果延迟太高，先降efSearch，再考虑换索引类型。不要一上来就调参，先确认数据质量和嵌入模型没问题，因为大部分检索不准的问题根源在数据侧而不是索引侧。

5.3 数据分区、副本与一致性权衡

生产环境里，向量库的数据分区和副本策略直接影响可用性和性能。分区是把数据按某个维度拆成多个集合，比如按部门、按产品线、按时间。分区的好处是检索时可以只搜相关分区，减少计算量。副本是每个分区的备份，副本越多读吞吐越高，但写入成本和存储成本也越高。

一致性方面，向量库通常提供强一致和最终一致两种模式。强一致保证写入后立刻能读到，但延迟高；最终一致写入后可能短暂读不到，但吞吐高。知识库场景一般对实时性要求不高，用最终一致就够了。但如果知识更新频繁且要求立即可见，比如客服场景里刚发布的活动规则要马上能查到，那就得用强一致。

6. 实操落地：从零搭建一个数字人知识问答系统的完整步骤

6.1 环境准备与依赖安装

先列一下我实际搭建时用的环境。操作系统Ubuntu 22.04，Python 3.10，GPU是NVIDIA A10，显存24G。向量库用Qdrant的Docker镜像，大模型走腾讯混元的API接口，数字人用腾讯云的数字人SDK。

依赖安装分几块。Python侧需要安装qdrant-client、sentence-transformers、transformers、torch、tencentcloud-sdk-python等。Qdrant用Docker跑最省事，一条命令拉起来：

docker run -d --name qdrant -p 6333:6333 -p 6334:6334 -v /data/qdrant:/qdrant/storage qdrant/qdrant:latest

混元API需要先在腾讯云控制台开通服务，拿到SecretId和SecretKey，配到环境变量里。数字人SDK需要单独申请，拿到AppId和AppKey。

6.2 知识入库：文档解析、切片、向量化、写入

知识入库的完整流程我写成了一个脚本，分四步走。第一步是文档解析，用PyPDF2处理PDF，用python-docx处理Word，用BeautifulSoup处理HTML。解析出来的文本先做清洗，去掉多余空行和特殊字符。

第二步是切片，我写了一个基于语义的分割函数，先用换行符和句号做粗切，再用嵌入模型计算相邻句子的相似度，相似度低于阈值就断开。每个片段保留前后各50字的重叠。

第三步是向量化，用BGE-large-zh模型，输出1024维向量。批量大小设32，在A10上跑，一万个片段大概两分钟。

第四步是写入Qdrant，建一个collection，向量维度1024，距离度量用Cosine。每个点带上payload，包括文本内容、来源文档、章节、页码。写入时批量提交，每批100个点。

from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct client = QdrantClient(host="localhost", port=6333) client.create_collection( collection_name="knowledge_base", vectors_config=VectorParams(size=1024, distance=Distance.COSINE) ) points = [ PointStruct( id=i, vector=embeddings[i], payload={"text": chunks[i], "source": sources[i], "page": pages[i]} ) for i in range(len(chunks)) ] client.upsert(collection_name="knowledge_base", points=points)

6.3 检索与生成链路的代码实现

检索环节，先把用户问题用同一个BGE模型向量化，然后在Qdrant里搜Top-10。Qdrant的search接口支持带过滤条件，比如只搜某个来源的文档。

query_vector = embed_model.encode(user_question) hits = client.search( collection_name="knowledge_base", query_vector=query_vector, limit=10, query_filter=None )

拿到候选片段后，可选做重排序。我用的是BGE-reranker-large，把查询和每个片段拼成pair，过一遍模型得到相关性分数，按分数取Top-3。

生成环节，把Top-3片段和用户问题拼成提示词，调混元API。提示词模板我调了好几版，最终稳定下来的是这个结构：

你是一个专业的知识助手。请根据以下参考资料回答用户问题。 如果参考资料中没有相关信息，请直接说“抱歉，我暂时没有找到相关信息”，不要编造。 参考资料： [1] {片段1} [2] {片段2} [3] {片段3} 用户问题：{用户问题} 回答要求：分点作答，每点不超过50字，引用来源时标注编号。

混元API的调用用SDK，设置temperature为0.3，降低随机性。max_tokens设500，防止回答过长。

6.4 数字人接入与端到端联调

数字人接入分两步。第一步是把生成的文本送给TTS，拿到音频流。第二步是把音频流和文本一起送给数字人驱动接口，驱动口型和表情。腾讯数字人SDK提供了WebSocket接口，可以实时推送音频和文本，数字人端实时渲染。

端到端联调时，我重点测了三个指标：首字延迟、口型同步误差、多轮上下文保持。首字延迟从用户说完到数字人开口，实测在1.5秒左右，主要耗时在ASR和检索生成。口型同步误差用录屏逐帧比对，控制在80毫秒以内。多轮上下文保持测了五轮连续追问，没有出现话题丢失。

7. 常见问题与排查技巧实录

7.1 检索不准的排查思路与优化手段

检索不准是最常见的问题，表现是用户问了一个知识库里明明有的问题，但数字人回答“没找到”。排查时按这个顺序走：先看切片是否合理，把知识库里相关文档的切片打出来，看关键信息有没有被切碎或混在无关内容里。再看嵌入模型是否适合当前领域，通用嵌入模型在专业领域可能表现不佳，需要换领域微调过的模型。然后看检索参数，Top-K是不是太小，相似度阈值是不是设太高。最后看查询改写，用户的口语化问题有没有被正确转成检索语句。

优化手段我按性价比排序：第一，优化切片策略，按语义切而不是按固定长度切；第二，加查询改写，用大模型把用户问题转成多个检索变体；第三，换更强的嵌入模型或做领域微调；第四，加混合检索，向量加关键词；第五，加重排序模型。

7.2 大模型幻觉的抑制策略

幻觉的表现是数字人回答了知识库里没有的内容，或者把不同文档的信息拼错了。抑制幻觉要从三个层面下手。提示词层面，明确约束“只根据参考资料回答”，并给出“不知道”的示例。检索层面，提高召回质量，确保参考资料本身是相关的，噪音少。生成层面，降低temperature，减少随机性，同时限制max_tokens，防止模型自由发挥。

还有一个技巧是让模型在回答里标注引用来源，比如“根据[1]”，这样用户能判断答案是否有依据。如果模型标不出来源，说明它在编。这个技巧对提升用户信任很有效。

7.3 数字人交互延迟的优化经验

延迟优化是个系统工程。我实测下来，各环节耗时占比大概是：ASR占15%，检索占20%，生成占45%，TTS占15%，驱动渲染占5%。生成是大头，优化空间最大。具体手段包括：用流式生成，模型边生成边返回，不用等全部生成完；限制max_tokens，答案短了生成自然快；用更小的模型做生成，比如混元的轻量版；缓存常见问题的答案，命中缓存直接返回。

检索环节的优化主要是加索引和减K值。HNSW索引比Flat快很多，K从10降到5也能省不少时间。ASR和TTS的优化空间不大，除非换更快的引擎。

7.4 常见问题速查表

8. 这套方案的能力边界与扩展方向

8.1 当前方案的局限性

这套方案不是万能的，有几个明显的边界。第一，知识库的质量决定上限。如果原始文档本身写得乱、信息过时、互相矛盾，检索和生成再好也救不回来。第二，复杂推理能力有限。用户问一个需要跨多个文档综合推理的问题，比如“对比A产品和B产品在退款政策上的差异”，系统可能只能分别召回两个产品的政策片段，但做不好对比分析。第三，多模态理解还在早期。如果知识库里有关键的图表、流程图、视频，当前方案主要处理文本，图表信息会丢失。

8.2 可扩展的方向与个人建议

扩展方向我想到几个。一是多模态知识入库，用OCR和图表理解模型把图片里的信息也提取出来，扩充可检索的内容。二是Agent化，让数字人不只是问答，还能执行操作，比如查订单、改地址、提交工单，这需要把知识引擎和业务系统打通。三是个性化，根据用户画像调整回答的详细程度和语气风格，比如对新用户解释得更细，对老用户直接给结论。

我个人在实际操作中的体会是，这套方案落地最大的难点不在技术，而在知识治理。企业里往往没有一份干净、结构化、持续更新的知识库，东一份西一份，格式各异，版本混乱。技术团队花大力气把系统搭起来，结果发现知识库本身就不行，效果自然上不去。所以我的建议是，先花时间把知识库整理好，再上技术方案，顺序不能反。另外，数字人场景对延迟和自然度要求高，前期选型时一定要做端到端压测，别等上线了才发现延迟扛不住。最后再分享一个小技巧：提示词里加一句“如果用户问题模糊，先反问澄清再回答”，能显著减少答非所问的情况，这个在客服场景里特别管用。