企业官网建设流程全解析

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对话摘要

结构体

1. 关键事实 每次都带过去。
   写到system_prompt 部分 ，

• 用户态度
• 约束提取约束
• 已经达成的里程碑/一致的点

2. 大模型输出的核心内容
3. 用户的核心内容

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

1. 什么东西要传过去大模型
2. 传过去的顺序是怎么样的？
   传递的本质 传messages

系统提示词的message、其他的多轮对话。

1.5.1系统提示词

顺序：

角色定义 system
硬约束
业务规则
输出格式
few-shot可以压缩上下文少了 (少给几个)
摘要 对话内容纯文本(可以压缩，) 摘要丢掉些细节

1.5.2 多轮对话

滑动窗口算法

上下文管理

在窗口很大的时候，基本是L0原文，
在窗口 内容多了，尝试压缩一部分不重要内容，重要内容保留 L1 核心运行级
在窗口内容 更小了， 大家都压缩， l2 紧张运行，
快运行不下去时，核心压缩，非核心淘汰，保留索引。l3 最小运行级别。

2 上下文 压缩、摘要

2.1 设计不同的级别

分级 上下文空间不够了。 不同内容重要性 来进行压缩。

1. 原文
2. 大模型可读摘要
3. 弱压缩摘要
4. 强压缩摘要
5. 一句话索引

2.2 你这个摘要是调用一下大模型吗？

是的
本质上是你的prompt 是怎么写的？
你怎么评估你的摘要？、能不能召回细节？

2.2.1prompt 怎么写？

1. 细节不能说？
2. 告诉大模型 什么内容保留，什么内容不保留。
3. 具体的压缩规则，什么关键信息要留下来。

举例子 摘要的示例 ：

• 用户的明确表态，需要保留。(不要改我接口，我预算xxx) 直接保留。
• 里程碑要留着，长任务、plan里面 达到了一个状态，某个阶段实现了，那么这个阶段的结论要留着。 描述xxx问题已经描述清楚，留着。
• 用户和agent 达成一致。 用户和agent 思考方向等达成一致了。
  不留
• 便于用户理解的废话可以不留了。
• 用户输入的解释、冗余的内容可以不留了。 用户为了表达它输入的内容，说了很多解释，不留。
• 给出的例子. 不留

2.2.2怎么评估摘要的效果

真正的意思？ 该留的你有没有留下来？ 信息损耗了多少？
回答
压缩比=压缩后的长度/原文长度
丢一些细节，针对大模型可读 50%左右

2.3 召回细节

架构

简化流程

3 上下文的时间相关性

有些上下文，时间越久，越没用。
使用一个时间衰减的指数 weight=f(t)