Update 20230609_01.md

Author: digoal

202306/20230609_01.md

@@ -50,7 +50,20 @@ PostgreSQL , PolarDB , OKR , 目标 , 充分条件 , 必要条件 , 变化 , 不
 
 把老板的O再往上放大, 你可以看到更高层面的O. 老板的O是更高层面的KR.  所以老板的O发生变化时, 往往是更高层面的KR在发生变化.    
 
+## 大模型也会因为 “出发太久, 忘记初心”  
+如下:    
 
+https://edu.aliyun.com/course/3126500/lesson/342570389  
+  
+避免向大模型输入巨量信息  
+  
+大模型仅支持有限长度的上下文，有人认为如果我们使用支持超长文本的大模型，我们就可以在使用时提供更多信息了。但是由于技术发展，我们越来越需要将历史信息、详细指令、API调用上下文、插件和系统响应信息等大量信息同时塞给大模型，这样做除了产生更大的调用成本和带宽消耗之外，还有可能降低有用信息被检索和解读的概率，导致大模型输出结果与用户的问题无关。因此，支持超长文本的大模型并没有给应用市场带来革命性的变化。所以，我们需要考虑优化提示词文字，精简信息内容，甚至压缩历史记忆文字量，从而提升大模型的准确率。  
+  
+<b> 如果我们使用支持超长上下文的大模型，我们有可能会遇到另一个问题，对近邻信息敏感度更高的问题（recency问题）。也就是说，虽然我们可以给大模型传递很长的历史记录，但是大模型只对靠近提示词末尾部分的信息更感兴趣，如果你需要检索的信息恰好被编辑到提示词最开始的部分，大模型也有可能无法向你提供正确的答案。 </b>   
+  
+持续优化Agent规划能力  
+  
+与人类相比，大模型Agent的规划能力还比较初级。大模型是从训练样本中学习事物之间的联系，并学会如何做规划的。在实际应用中，大模型做出的规划很可能需要先经过使用者的调整再做实施。在面对一个复杂任务时，大模型Agent会将任务分解为一系列长链路的步骤，我们可以设计一些方法衡量这些步骤是否还需要进一步拆解。当大模型按照步骤链条执行时，我们也需要设计自动化方案，观察执行链路中会不会出现前一个步骤累积下来的错误，执行过程是否需要终止。当然，我们也可以添加交互手段，让系统的使用者介入Agent的规划和执行，加以修正。  
 
 #### [期望 PostgreSQL|开源PolarDB 增加什么功能?](https://github.com/digoal/blog/issues/76 "269ac3d1c492e938c0191101c7238216")