中午起不来1. 上下文工程：解决大模型幻觉的关键技术
在构建基于大语言模型（LLM）的应用系统时，我们常常遇到一个令人头疼的问题：明明RAG系统返回了完美的文本块，提示词也精心设计过，但模型仍然会产生幻觉（hallucination）。更令人困惑的是，有时候文档加得越多，回复质量反而越差。这些问题往往不是出在提示词上，而是出在上下文管理上。
提示工程（Prompt Engineering）告诉模型"怎么说话"，而上下文工程（Context Engineering）则控制模型"说话时看到什么"。这两者相辅相成，但在生产环境中，后者往往是被忽视的关键环节。
1.1 什么是上下文工程
Context Engineering是在运行时决定AI模型看到什么信息、何时看到、以何种结构看到的工程实践。它把上下文当作一条动态管道来处理，而非一段静态提示词：
- 选对文档而不是全量灌入
- 将长文档压缩为面向任务的摘要
- 在检索之前重新表述模糊的用户查询
- 跨会话注入记忆和用户状态
- 用实时工具和数据锚定答案
- 组织所有输入，让模型知道什么最重要
简单来说，上下文工程是在生产环境中控制模型注意力的手段。做得好，小模型也能有不错的表现；做得差，最好的模型照样会产生幻觉。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选择性检索：避免信息过载
2.1 信息过载的危害
如果我们把50个文档全部塞进上下文，指望模型自己找到需要的内容，结果往往会适得其反。即便上下文窗口足够大，模型的注意力分布仍然不均匀——它会重点关注开头和结尾的Token，中间部分被忽略。这种现象被称为"lost in the middle"效应。
正确的做法是通过评分、重排、裁剪，只让相关且不重复的片段进入上下文窗口。
2.2 三步过滤法
2.2.1 相关性重排
初始搜索基于向量相似度或关键词匹配返回前50个结果，但相似不等于相关。交叉编码器（cross-encoder）会把查询和每个文档放在一起联合阅读，重新排序。虽然速度慢一些，但准确度高得多。重排之后只保留前5个最相关的结果。
2.2.2 冗余消除
同一个概念在文档库中出现在多个地方是常态。比如营销材料、技术规格、FAQ都可能提到同一功能。用Embedding对相似文本块做聚类，余弦相似度超过0.9的基本就是重复内容，可以删掉一个。模型不需要看同一个事实10遍。
2.2.3 任务感知过滤
利用元数据做筛选。每个文档都应打上标签：文档类型、最后更新日期、产品版本、地区、部门等。查询进来时按相关维度过滤。
2.3 实际案例
查询："总结最新的退款政策变更"
过滤前：向量搜索返回50个关于退款的文本块，有些来自2018年旧政策，有些是其他公司的文档，有些是从未面向客户的内部备忘录。LLM看到了14天和30天窗口期的矛盾说法、不同的排除条款、相互冲突的流程，试图综合所有信息后幻觉出了一条根本不存在的政策。
过滤后：加上region='CN'和updated_at >= 2025-01-01两个条件，立即排除40个文本块。剩余10个用交叉编码器重排，保留前5个再检查近似重复（余弦相似度 > 0.9）。最终送进上下文的只有3个高相关、无冗余的文本块。
效果：提示更短，回答更清晰，没有矛盾。实验数据显示，移除噪声上下文后准确率提高15-30%，Token消耗降低20-40%。真正的收益在于可追溯性——确切知道模型看到了什么上下文，才能调试失败；50个文本块全灌进去，只能靠运气。
3. 上下文压缩：让每个Token都有价值
3.1 长文档的问题
长篇原始文档容易撑破上下文限制，同时稀释注意力。多个案例研究表明，经过压缩可以在保持甚至提升准确率的同时砍掉50-7