1. 上下文是指什么1.1短期记忆短期记忆就是一种缓存机制缓存1.2长期记忆mysql—同步到 es怎么存chat 多轮对话— chatRounds(每一轮的情况)— chatRoundStep 每一轮的每一个不走记录下来。1.3上下文有一些什么内容mysql 有一份redis 有一部分es/向量数据库有一部分 (检索、召回)实践中维护用权重来区别 百分比、置信度。例子color 今天喜欢红色偶然表达喜欢黄色 (不确定是否永久喜欢)红色-100 黄色-50 权重。越高 说明 越是长期画像。1.3.1用户画像1.3.1.1长期用户画像建模: 喜欢吃 川菜、湘菜1.3.1.2 中期用户画像表达了用户的偏好但是又不足以成为 真正的长期用户偏好。1.3.1.3 短期用户画像某一轮多轮对话里面我今天想吃西餐》 覆盖长期用户偏好长期画像加载后这轮会话 用户长期被覆盖了。1.3.1.4如何沉淀为长期用户画像呢怎么判断为临时性偏好。还是真的长期用户的偏好1.3.1.5用户画像的建模-- 业务特征电商品牌偏好、价格偏好、出口\进口、颜色、风格社交用户关系 你是谁的朋友、谁是你的朋友1.3.2面试讲清楚 用户画像的建模时怎么样的有什么字段、含义、用在哪里。1.3.3对话内容每一轮的对话内容数据库会有一份、redis 会缓存一份(部分)少数情况下ES/向量数据库 还有一份 召回对话细节。1.3.4对话摘要结构体关键事实 每次都带过去。写到system_prompt 部分 用户态度约束提取约束已经达成的里程碑/一致的点大模型输出的核心内容用户的核心内容1.3.5中间结果每一轮最终回复生成的过程中你会调用很多工具会产生很多中间结果有一些是可以保留下来的。研发阶段会保留多。1.3.6存哪里数据库存一份 redis 存一份es/向量数据库存一份1.4 上下文每一项内容1.4.1从哪里来用户输入、工具调用、大模型输出、计算的中间结果1.4.2存哪里是否要持久化—mysql是否要缓存到es里面是否可以直接放内存只有本轮要用的临时性的结果 其他不用1.4.3 怎么查询出来mysql where 语句es 查询条件rpc、http 调用1.4.4要不要压缩如何压缩1.4.5如何召回细节必定意味着你要同步过去es\向量数据库等1.5上下文窗口编排算法xxx什么东西要传过去大模型传过去的顺序是怎么样的传递的本质 传messages系统提示词的message、其他的多轮对话。1.5.1系统提示词顺序角色定义 system硬约束业务规则输出格式few-shot可以压缩上下文少了 (少给几个)摘要 对话内容纯文本(可以压缩) 摘要丢掉些细节1.5.2 多轮对话滑动窗口算法上下文管理在窗口很大的时候基本是L0原文在窗口 内容多了尝试压缩一部分不重要内容重要内容保留 L1 核心运行级在窗口内容 更小了 大家都压缩 l2 紧张运行快运行不下去时核心压缩非核心淘汰保留索引。l3 最小运行级别。2 上下文 压缩、摘要2.1 设计不同的级别分级 上下文空间不够了。 不同内容重要性 来进行压缩。原文大模型可读摘要弱压缩摘要强压缩摘要一句话索引2.2 你这个摘要是调用一下大模型吗是的本质上是你的prompt 是怎么写的你怎么评估你的摘要、能不能召回细节2.2.1prompt 怎么写细节不能说告诉大模型 什么内容保留什么内容不保留。具体的压缩规则什么关键信息要留下来。举例子 摘要的示例 用户的明确表态需要保留。(不要改我接口我预算xxx) 直接保留。里程碑要留着长任务、plan里面 达到了一个状态某个阶段实现了那么这个阶段的结论要留着。 描述xxx问题已经描述清楚留着。用户和agent 达成一致。 用户和agent 思考方向等达成一致了。不留便于用户理解的废话可以不留了。用户输入的解释、冗余的内容可以不留了。 用户为了表达它输入的内容说了很多解释不留。给出的例子. 不留2.2.2怎么评估摘要的效果真正的意思 该留的你有没有留下来 信息损耗了多少回答压缩比压缩后的长度/原文长度丢一些细节针对大模型可读 50%左右2.3 召回细节架构简化流程3 上下文的时间相关性有些上下文时间越久越没用。使用一个时间衰减的指数 weightf(t)