<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>深度学习 on Coder_Studio</title>
        <link>https://iamxurulin.github.io/tags/%E6%B7%B1%E5%BA%A6%E5%AD%A6%E4%B9%A0/</link>
        <description>Recent content in 深度学习 on Coder_Studio</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh-cn</language>
        <copyright>iamxurulin</copyright>
        <lastBuildDate>Sun, 23 Aug 2026 17:21:42 +0000</lastBuildDate><atom:link href="https://iamxurulin.github.io/tags/%E6%B7%B1%E5%BA%A6%E5%AD%A6%E4%B9%A0/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>Prompt Engineering和context engineering有什么区别?为什么Transformer架构在处理超长上下文时会变慢？</title>
        <link>https://iamxurulin.github.io/p/prompt-engineering%E5%92%8Ccontext-engineering%E6%9C%89%E4%BB%80%E4%B9%88%E5%8C%BA%E5%88%AB%E4%B8%BA%E4%BB%80%E4%B9%88transformer%E6%9E%B6%E6%9E%84%E5%9C%A8%E5%A4%84%E7%90%86%E8%B6%85%E9%95%BF%E4%B8%8A%E4%B8%8B%E6%96%87%E6%97%B6%E4%BC%9A%E5%8F%98%E6%85%A2/</link>
        <pubDate>Thu, 04 Jun 2026 17:14:35 +0000</pubDate>
        
        <guid>https://iamxurulin.github.io/p/prompt-engineering%E5%92%8Ccontext-engineering%E6%9C%89%E4%BB%80%E4%B9%88%E5%8C%BA%E5%88%AB%E4%B8%BA%E4%BB%80%E4%B9%88transformer%E6%9E%B6%E6%9E%84%E5%9C%A8%E5%A4%84%E7%90%86%E8%B6%85%E9%95%BF%E4%B8%8A%E4%B8%8B%E6%96%87%E6%97%B6%E4%BC%9A%E5%8F%98%E6%85%A2/</guid>
        <description>&lt;h2 id=&#34;prompt-engineering和context-engineering有什么区别&#34;&gt;Prompt Engineering和context engineering有什么区别?
&lt;/h2&gt;&lt;p&gt;Prompt是指导大模型怎么思考的机制，解决的是how的问题，怎么推理，怎么组织答案。&lt;/p&gt;
&lt;p&gt;Context是为大模型提供信息的机制，解决的是what的问题，给模型什么知识，什么数据。&lt;/p&gt;
&lt;p&gt;Prompt的核心技术包括CoT、few shot、角色扮演等，用来激发模型内部已有的知识；&lt;/p&gt;
&lt;p&gt;Context的核心是RAG，通过检索将外部知识注入模型。&lt;/p&gt;
&lt;p&gt;两者缺一不可，前者决定质量，后者决定准确性。&lt;/p&gt;
&lt;p&gt;在实际工程中，Prompt面临脆弱性和幻觉问题，我们用自动优化和Self-Consistency来解决；&lt;/p&gt;
&lt;p&gt;Context面临中间迷失和噪声问题，我们用重排策略和自反思来优化。&lt;/p&gt;
&lt;p&gt;未来的发展方向是Agent，让系统动态地生成和管理这两者，实现真正的智能协作。&lt;/p&gt;
&lt;h2 id=&#34;为什么transformer架构在处理超长上下文时会变慢它的瓶颈在哪里我们该如何解决&#34;&gt;为什么Transformer架构在处理超长上下文时会变慢？它的瓶颈在哪里？我们该如何解决？
&lt;/h2&gt;&lt;p&gt;在Transformer的自注意力机制中，模型主要做的事情是让每一个Token都要去和整个序列里其他所有的Token进行交互，计算他们之间的相关度。&lt;/p&gt;
&lt;p&gt;假设输入序列长度从n变成2n，计算量和显存占用不是简单的翻一倍，而是直接飙升4倍。这就是所谓的二次方爆炸，长度双倍增长，代价是4倍的计算量。&lt;/p&gt;
&lt;p&gt;除了计算的瓶颈，还有一个关键的瓶颈是显存瓶颈，也就是常说的显存墙现象。&lt;/p&gt;
&lt;p&gt;可以想象这样一个场景，GPU的计算核心就像一个吃饭飞快的人，但是显存的带宽就像是一根很细的吸管，搬运数据的速度远远跟不上计算的需求。&lt;/p&gt;
&lt;p&gt;在推理阶段，这个问题更加明显，每次生成一个新的Token，模型都要反复去显存里搬取之前计算过的键值缓存KV cache，结果，计算核心大部分都在等数据这个动作上，而不是在真正算数据，这才是变慢的物理本质。&lt;/p&gt;
&lt;p&gt;第三个问题就是外推性差，很多大模型其实是在相对较短的文本上训练的，如果给他塞进一个长文本，虽然物理硬件层面上可能扛得住，单模型内部的位置编码机制并不知道这些超长距离的Token之间应该如何交互，导致的结果就是深层内容开始乱套，困惑度PPL疯狂飙升。&lt;/p&gt;
&lt;p&gt;所以，长文本变慢的本质其实是O(n^2)的计算复杂度和硬件IO访问瓶颈的双重碰撞，而我们的解决思路是：&lt;/p&gt;
&lt;p&gt;首先，用Flash Attention在算子层面做融合和优化，直接解决IO的瓶颈；&lt;/p&gt;
&lt;p&gt;其次，用GQA和MQA在架构层面做参数共享，显著压缩KV cache的体积；&lt;/p&gt;
&lt;p&gt;同时，借助PagedAttention，在内存管理上做创新，消灭显存碎片；&lt;/p&gt;
&lt;p&gt;最后，通过位置编码的数学手段，比如RoPE Scaling让模型具备外推能力。&lt;/p&gt;
</description>
        </item>
        
    </channel>
</rss>
