陪伴类 AI 的人设一致性与语音延迟优化需兼顾技术方案和工程实践

在开发陪伴类 AI 时，维持长对话人设一致性是核心难点。单纯依赖 RAG 或长上下文都无法彻底解决问题。三种方案各有优劣：

第一种方案采用 RAG 检索增强，类似 MiniMax 的做法。用户历史对话切片向量化后存入 Milvus，每轮对话进行 top-k 召回，再拼接至 System Prompt。但当对话轮次达到 20 轮时，召回噪声会导致人设漂移，比如提到"上周二"时可能产生幻觉。

第二种方案是全量上下文硬塞，类似 GPT-4o 的路线。这种方案利用模型原生支持的 128k 或 200k 上下文，将全量历史直接输入模型。但推理成本随对话轮次线性增长，高频陪伴场景中 Token 消耗极快。处理极长文本时，模型仍会出现"中间丢失"现象。

第三种方案采用结构化记忆存储，类似 Kimi 与智谱的做法。从非结构化对话中抽取关键事实，例如用户生日、宠物名，存储为 KV 结构。对话过程中通过 Function Calling 机制动态读写存储层。实测显示，这种方案在 50 轮以上对话中，人设崩坏率可压低至 5% 以内。

仅靠简单的 System Prompt 无法支撑深度陪伴感。高效的人设构建需要结合传统游戏 NPC 行为树与 LLM 生成能力。成熟的陪伴类 Prompt 通常包含多个模块，单次输入可能高达 3000+ tokens。风格模板定义特定口癖、语气词和句式结构；情绪状态机定义关系阶段；触发条件库预设特定场景反应；关系判定逻辑实时更新关系权重。

在语音通话中，端到端延迟超过 1.5 秒会影响用户体验。技术上可以采用 CosyVoice + 零样本 TTS 方案。通过流式 LLM 输出与语音合成引擎并发处理，将合成延迟压低至 800ms 以内，用户感知到的响应速度接近自然对话。

构建这类产品时，需关注工程化体验。关键信息必须建立结构化数据库，通过 Function Calling 保证准确性。选择长上下文方案时，需关注 Token 成本曲线，设计截断机制或摘要压缩算法。语音陪伴场景需优化流式输出，采用 LLM 流式输出 → TTS 流式合成的方式。