RAG已死，上下文为王?

最近看到很多的文章都在写“RAG已死，上下文为王”，YB上也非常多的相关的内容。这让我这个刚接触AI应用的初学者感到非常疑惑。在阅读 https://github.com/davidkimai/Context-Engineering 后，我对大模型应用有了不一样的理解。

先说结论：RAG与 Context-Engineering 只是概念上的混淆。只是RAG并不能准确描述大模型应用技术，采用上下文工程这个更精确、更高价值的概念来代替。

那么什么是上下文工程？下面一张图就能说明上下文工程。在https://github.com/davidkimai/Context-Engineering中，将上下文工程以生物学隐喻的方式进行展开，图也是基于相关文章进行整理绘制的。

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step." — Andrej Karpathy "上下文工程是一门精妙的艺术和科学，为下一步填充恰当的信息到上下文窗口中。"

上下文是在推理时提供给 LLM 的完整信息负载，包括模型为合理完成给定任务所需的所有结构化信息组件。废话不多说，先上图：

原子：提示词的基本单位

完成一个任务所需要的最基本的,由于提供信息过少，模型难保持一致性。 prompt

分子：将提示词与示例结合

通过小样本学习的方式做到更高精度和一致性，同时借助外部示例数据库还能实现动态分子（不同任务检索示例数据库提供最相关的示例）。

细胞：添加记忆和状态

默认情况下大模型不具备记忆功能，大模型会忘记先前交互中的信息导致用户体验不连贯

直接将所有历史消息则会导致上下文窗口被填满，因此合理的记忆管理策略十分重要。

器官

上下文器官协调多个LLM细胞来解决任何单个上下文都无法解决的问题。由指挥者、共享记忆、以及专业细胞通过相应的合适所需应用的控制流模式结合组成。

各司其职的器官共同组成一个完整的认知系统。

目前构建器官可能会面临的挑战：

• 错误可能通过系统传递
• 编排增加了复杂性和延迟
• 关键信息可能在细胞之间丢失
• 复杂的交互难以追踪，调试困难
• 多次调用LLM增加总token成本
• 系统设计复杂性高，需要仔细规划和测试

器官构建的最佳实践方式：

• 从最小化器官开始，根据需要增加复杂性
• 在隔离状态下测量每个细胞的性能
• 需要定义细胞之间的清晰输入输出格式
• 跟踪所有细胞之间的通信
• 设计细胞处理意外输入
• 添加专门的细胞来检查输出
• 先构建基本功能再添加
• 识别并并行化独立任务

本文参考：https://github.com/davidkimai/Context-Engineering