Prompt Engineering和context engineering有什么区别?
Prompt是指导大模型怎么思考的机制，解决的是how的问题，怎么推理，怎么组织答案。
Context是为大模型提供信息的机制，解决的是what的问题，给模型什么知识，什么数据。
Prompt的核心技术包括CoT、few shot、角色扮演等，用来激发模型内部已有的知识；
Context的核心是RAG，通过检索将外部知识注入模型。
两者缺一不可，前者决定质量，后者决定准确性。
在实际工程中，Prompt面临脆弱性和幻觉问题，我们用自动优化和Self-Consistency来解决；
Context面临中间迷失和噪声问题，我们用重排策略和自反思来优化。
未来的发展方向是Agent，让系统动态地生成和管理这两者，实现真正的智能协作。
为什么Transformer架构在处理超长上下文时会变慢？它的瓶颈在哪里？我们该如何解决？
在Transformer的自注意力机制中，模型主要做的事情是让每一个Token都要去和整个序列里其他所有的Token进行交互，计算他们之间的相关度。
假设输入序列长度从n变成2n，计算量和显存占用不是简单的翻一倍，而是直接飙升4倍。这就是所谓的二次方爆炸，长度双倍增长，代价是4倍的计算量。
除了计算的瓶颈，还有一个关键的瓶颈是显存瓶颈，也就是常说的显存墙现象。
可以想象这样一个场景，GPU的计算核心就像一个吃饭飞快的人，但是显存的带宽就像是一根很细的吸管，搬运数据的速度远远跟不上计算的需求。
在推理阶段，这个问题更加明显，每次生成一个新的Token，模型都要反复去显存里搬取之前计算过的键值缓存KV cache，结果，计算核心大部分都在等数据这个动作上，而不是在真正算数据，这才是变慢的物理本质。
第三个问题就是外推性差，很多大模型其实是在相对较短的文本上训练的，如果给他塞进一个长文本，虽然物理硬件层面上可能扛得住，单模型内部的位置编码机制并不知道这些超长距离的Token之间应该如何交互，导致的结果就是深层内容开始乱套，困惑度PPL疯狂飙升。
所以，长文本变慢的本质其实是O(n^2)的计算复杂度和硬件IO访问瓶颈的双重碰撞，而我们的解决思路是：
首先，用Flash Attention在算子层面做融合和优化，直接解决IO的瓶颈；
其次，用GQA和MQA在架构层面做参数共享，显著压缩KV cache的体积；
同时，借助PagedAttention，在内存管理上做创新，消灭显存碎片；
最后，通过位置编码的数学手段，比如RoPE Scaling让模型具备外推能力。