RAG效果不及预期，试试这10个上下文处理优化技巧。对大部分开发者来说，搭一个RAG或者agent不难，怎么把它优化成生产可用的状态最难。在这个过程中，检索效率、准确性、成本、响应速度，都是重点关注问题。
Context Pruning如何结合rerank，优化RAG上下文？
最近半年，我阅读了业界关于 AI Agent 的工程实践：Anthropic 的 Context Engineering 论文、Manus 的工程分享、Cline 的 Memory Bank 设计等。同时自己也一直在做跟 AI Agent 相关的项目，如：Jta[1]（开源的翻译 Agent，基于 Agentic Workflow）。
在大模型研究领域，做混合专家模型（MoE）的团队很多，但专注机制可解释性（Mechanistic Interpretability）的却寥寥无几 —— 而将二者深度结合，从底层机制理解复杂推理过程的工作，更是凤毛麟角。
谷歌在第三天发布了《上下文工程：会话与记忆》(Context Engineering: Sessions & Memory) 白皮书。文中开篇指出，LLM模型本身是无状态的 (stateless)。如果要构建有状态的（stateful）和个性化的 AI，关键在于上下文工程。
如果你也在做 RAG 或智能体应用，大概经历过这些瞬间：文档切得太碎，答案失去上下文；切得太大，又召回不准；加了更多提示词，效果可能更不稳定。
在几天前，上海交大发布了一篇名为 《上下文工程2.0：上下文工程的上下文》（Context Engineering 2.0: The Context of Context Engineering） 的重磅论文。
近期，DeepSeek-OCR提出了“Vision as Context Compression”的新思路，然而它主要研究的是通过模型的OCR能力，用图片压缩文档。
dots.ocr 支持多语言文档的解析，能够在单一模型中统一完成版面检测、文本识别、表格解析、公式提取等任务，并保持良好的阅读顺序。他们之所以在一个模型中完成这些任务，是因为他们相信这些任务之间可以相互促进，为彼此提供更多的 context，从而达到更高的性能上限。目前，该项目的 star 量已经超过了 5000。
最近在开源社区闲逛，发现字节悄悄放出了一个叫 MineContext 的项目。和字节Viking团队的小伙伴聊天时，我了解到一个挺有意思的故事：MineContext 团队其实在今年四五月份就有了初步想法，甚至更早之前就在思考：如何围绕个人的完整记忆来做应用。
