1，阿里小蜜
1.1，多轮问题定位
【线上链路设计】 COT主要发挥的核心作用是，让模型学习到作为一名淘宝售后客服，回答用户问题的主要思路和模版。
【对齐人工端沟通能力】 为了建设小蜜问题沟通阶段的多轮能力，最直接的学习目标就是对齐人工端小二沟通习惯。因此我们对人人语聊进行了细致的处理，使得模型尽可能模仿小二进行问题沟通。
【增强模型泛化性】 训练初期，我们发现模型比较容易过拟合，容易生成高频且带有幻觉的结果，泛化性很差；其次，全部使用人工咨询的SFT指令进行训练，模型的通用指令能力似乎丧失了，也难以对通用知识进行拒识，因此我们混合了更多通用数据，对模型进行重新SFT训练，增加模型的泛化能力，避免定位到错误的解决方案误导用户。
1.2，case 服务轨迹
【难点&挑战】 进线时小蜜没有任何上下文，而人工小二则可以查阅丰富完整的服务轨迹信息。
【case 服务轨迹】
【未问先答】“未问先答”是小蜜推出的新能力，在用户刚刚进线时，根据用户当前状态，立即推送用户可能需要的解决方案，更快地帮助用户路由到问题，减少咨询成本。
【业务应用】考虑到信息的抽取结果将会应用到下游丰富的大模型对话场景，而抽取枚举值将会损失丰富的细节信息，因此我们考虑让模型既可以输出自然语言摘要结果，也可以输出对应的枚举值。
1.3，生成式快捷短语
【业务背景】为了让小蜜可以更好的定位到用户的问题，在小蜜整体的交互中，增加了一些以推荐为导向的方法，快捷短语便是其中的一环。快捷短语的目的是生成单个或多个用户可能想了解/输入的内容，让用户通过点击基于知识/问题的快捷短语来与小蜜进行交互，在减少用户输入成本的同时帮助用户快速获取解决方案。
【方案设计】生成式快捷短语的目的是生成用户可能想要输入的内容，配合小蜜中的大模型多轮定位等功能，推进用户对话进展的同时获取解决方案。与之前的绑定知识不同，生成式快捷短语不绑定固定知识，而是让用户以对话的形式走大模型多轮定位获取解决方案。考虑到大模型的性能问题，实际线上部署的时候，先以前置判别模型进行判别，用以减少大模型调用量。
1.4，多轮追问生成
【业务背景】消费者在小蜜机器人咨询问题繁多，包含了闲聊、单诉求和多诉求。而每轮诉求之后，消费者通常会针对小蜜当前所给出的解决方案进行一步咨询，咨询内容大概包含以下3种情况：
对当前诉求的进一步描述或者对当前答案的进一步询问； 表达情绪上的不满、催促或者感谢； 当前诉求完结，跨诉求咨询其他新问题。因此如何精准判别消费者的同诉求追问并给出拟人化的合理性回复是算法面临的挑战。
【方案设计】
1.5，基于检索增强的文档问答大模型应用
【业务背景】双十一活动的特点是多样性高、时效性强，且规则较为复杂，如何结合淘宝的规则更好的理解消费者的问题，并且给出浅显易懂的回复答案是算法面临的挑战。
【方案设计】对文档按段落进行拆分，得到文档的段落内容以及对应的各级标题。然后对段落内容以及各级标题分别进行向量化，并保存到向量数据库中。检索时，将用户的 query 也进行向量化，然后与向量数据库中的向量进行匹配，搜索最相似的 n 条文档段落，最后将这些段落交由大模型进行最终的答案生成。
文档索引构建可以将文档转为文档索引块（Chunk），主要分为解析（Parsing）和切分（Chunking）两步：
【算法方案】
- Doc 向量化：【SimCSE模型架构】基于SimCSE模型结构，最后一层将embedding向量投影到256维。
- Doc 重排序：在进行重排优化策略时，我们针对数据层、训练层和模型层均进行了针对性实验及优化。
- SFT 微调：
- 【数据层】少量高质量的业务域问答数据+大量的高质量通用域问答数据；Role Prompt采用[Human, Assistant]的方式。
- 【模型层】基座选择Qwen7b，文档问答的prompt都非常长，采用较小的基座来兼容效果并能实际在业务落地；更长的context并不会带来效果上的提升，我们尝试过8k版本或者自己训练的4k版本，发现评测效果相比2k没有带来明显的提升。
- 【训练层】训练采用全参训练，经过我们的多次实验，7b模型的全参相比lora能取得更好的效果；对于训练的超参，我们发现对于训练的超参进行业务域的微调带来的提升并不明显且成本高。
2，B站
2.1，领域知识库建设
【RAG大模型智能客服框架】
【领域知识库的有效建设】
