大模型上下文工程：优化RAG系统核心技术与实践

1. 上下文工程：大模型应用落地的核心技术挑战

在大模型应用开发中，我们常常遇到这样的困境：明明RAG系统返回了看似完美的文本块，提示词也经过精心设计，但模型仍然会产生令人尴尬的"幻觉"（Hallucination）。更令人困惑的是，随着文档数量的增加，回复质量反而下降。这些问题往往不是出在提示词本身，而是隐藏在上下文处理环节。

提示工程（Prompt Engineering）教会模型如何表达，而上下文工程（Context Engineering）则控制模型在生成回复时能看到什么信息。这就像给一位专家提供参考资料：即使专家能力再强，如果给的是错误或无关的资料，他也无法给出正确回答。

1.1 上下文工程的核心价值

上下文工程是在运行时动态决定AI模型能看到哪些信息、以何种结构看到这些信息的工程实践。它解决了大模型应用中的几个关键痛点：

1. 信息过载问题：当向模型注入过多无关上下文时，模型会陷入"lost in the middle"效应，难以聚焦关键信息
2. 信息冲突问题：当上下文包含相互矛盾的内容时，模型会尝试"调和"这些矛盾，导致幻觉
3. 信息缺失问题：关键信息的遗漏会迫使模型基于不完整信息进行推测
4. 注意力分配问题：模型对不同位置信息的注意力分布不均，需要合理的信息布局

在生产环境中，优秀的上下文工程可以让较小的模型表现出色，而糟糕的上下文处理会让最强大的模型频频出错。根据实际项目经验，合理应用上下文工程技术可以将回答准确率提升15-30%，同时降低20-40%的Token消耗。

2. 选择性检索：精准控制信息输入

2.1 传统检索的问题

传统RAG系统常犯的一个错误是将大量检索结果不加筛选地塞入上下文窗口。这种做法会导致三个主要问题：

1. 注意力稀释：模型对开头和结尾的Token关注度更高，中间部分容易被忽略
2. 信息冗余：相同或高度相似的内容被重复提供
3. 噪声干扰：过时的、不相关的或低质量内容混入上下文

2.2 三层过滤机制

2.2.1 相关性重排

初始检索通常基于向量相似度或关键词匹配返回前N个结果（如50个）。但相似不等于相关，我们需要更精确的重排：

python复制# 使用交叉编码器进行重排的示例代码
from sentence_transformers import CrossEncoder

cross_encoder = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')
scores = cross_encoder.predict([(query, doc) for doc in retrieved_docs])
reranked_docs = [doc for _, doc in sorted(zip(scores, retrieved_docs), reverse=True)][:5]

交叉编码器虽然计算成本较高（比向量检索慢5-10倍），但准确度显著提升。实际测试中，这种重排可使精确率提高20-40%。

2.2.2 冗余消除

同一概念常在不同文档中重复出现。我们可以通过Embedding聚类识别并去除冗余内容：

python复制from sklearn.cluster import DBSCAN
from sentence_transformers import SentenceTransformer

encoder = SentenceTransformer('all-MiniLM-L6-v2')
embeddings = encoder.encode([doc.text for doc in reranked_docs])
clusters = DBSCAN(eps=0.1, min_samples=1).fit(embeddings)

unique_docs = []
seen_clusters = set()
for doc, label in zip(reranked_docs, clusters.labels_):
    if label not in seen_clusters:
        unique_docs.append(doc)
        seen_clusters.add(label)

经验表明，余弦相似度超过0.9的文本块通常包含重复信息，保留一个代表即可。

2.2.3 任务感知过滤

利用文档元数据进行精细过滤：

• 时间范围（last_updated >= 2024-01-01）
• 文档类型（type='policy'）
• 产品版本（version='2.0'）
• 地区限制（region='CN'）

python复制filtered_docs = [
    doc for doc in unique_docs 
    if doc.metadata['last_updated'] >= cutoff_date
    and doc.metadata['doc_type'] == 'policy'
]

2.3 实际案例：退款政策查询

原始查询："总结最新的退款政策变更"

过滤前：

• 50个文本块
• 包含2018年旧政策
• 包含其他公司政策
• 包含内部备忘录
• 多种矛盾说法（14天 vs 30天退款期）

过滤后：

• 3个文本块
• 全部来自2024年更新
• 仅包含面向客户的正式政策
• 条款完全一致

效果：回答准确率提升25%，Token消耗减少65%，且每个引用都可追溯。

提示：在实际项目中，建议从简单的日期过滤开始，逐步叠加重排和去重功能。仅添加时间戳过滤就能消除40-60%的噪声。

3. 上下文压缩：提升Token使用效率

3.1 长文档带来的挑战

原始长文档直接放入上下文会导致：

1. 占用宝贵的位置限制
2. 关键信息被淹没在细节中
3. 模型注意力被分散

研究表明，经过适当压缩可以在保持准确率的同时减少50-75%的Token使用。

3.2 三种压缩策略

3.2.1 带约束的LLM摘要

不同于通用摘要，我们生成面向当前查询的定制摘要：

code复制请总结以下文档，仅保留与[2025年1月后定价变更]直接相关的内容，忽略历史价格、实施细节和其他产品信息。输出5-8个要点，每个要点不超过20个词。

这种方法可将3000个Token的文档压缩到100-150个Token，保留率约5%。

3.2.2 句子级评分

使用小型模型（如BERT）评估每个句子与查询的相关性：

python复制from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch

model_name = "bert-base-uncased"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForSequenceClassification.from_pretrained(model_name)

sentence_scores = []
for sentence in document.split('.'):
    inputs = tokenizer(query, sentence, return_tensors="pt", truncation=True)
    outputs = model(**inputs)
    score = torch.sigmoid(outputs.logits).item()
    sentence_scores.append((score, sentence))
    
top_sentences = [s for _, s in sorted(sentence_scores, reverse=True)[:int(len(sentence_scores)*0.2)]]

保留得分最高的20%句子，可达到约70%的信息保留率。

3.2.3 层次化摘要

对超长文档（如书籍、手册）采用三级压缩：

1. 章节摘要（保留10%）
2. 章节摘要的摘要（保留30%）
3. 最终摘要（保留50%）

mermaid复制graph TD
    A[完整文档 10,000 Token] --> B[章节摘要 1,000 Token]
    B --> C[元摘要 300 Token]
    C --> D[最终摘要 150 Token]

3.3 API文档查询案例

查询："比较API文档中Plan A与Plan B的速率限制"

原始文档：

• 30页API文档
• 包含认证、错误码、Webhook等无关内容
• 速率限制信息分散在多个章节

压缩后：

1. "Plan A：1000次/小时，10,000次/天"
2. "Plan B：5000次/小时，50,000次/天"
3. "突发流量：1分钟内20%超额"
4. "速率限制错误返回HTTP 429"

总计约200 Token，仅为原始文档的2%，但完整回答了查询。

注意：压缩需要额外的LLM调用，当文档超过2000 Token时收益大于开销。对于短文档，直接使用原文更高效。

4. 层次化布局：优化信息结构

4.1 信息结构的重要性

LLM对上下文中不同位置的注意力分布不均：

• 开头部分：高度关注（系统指令）
• 中间部分：注意力下降
• 结尾部分：关注回升（用户问题）

合理的结构可以引导模型注意力，提高回答质量。

4.2 推荐布局模板

markdown复制[System Rules]
You are a precise financial research assistant.
Answer only from provided context.
If information is missing, say "I don't have that information."
Never make assumptions about numerical data.

[Task]
Goal: Answer user question using context below.
Output format: Start with direct answer, then provide supporting details.

[User Profile]
- Risk tolerance: Low
- Investment horizon: 5-10 years
- Region: India
- Previous queries: HDFC Bank 3 times
- Preferences: Dividend-paying stocks

[Retrieved Context]
DOC 1: HDFC Bank Q4 2024 earnings
- Revenue: ₹45,000 cr (+15% YoY)
- Net profit: ₹12,000 cr (+18% YoY)

[Tool Outputs]
- live_price("HDFCBANK"): ₹1,842.50
- news_summary: "Dividend ₹19/share"

[Question]
What's the latest on HDFC Bank?

4.3 各区块的作用

1. System Rules：设定行为边界，最先被模型读取
2. Task：明确回答要求和格式
3. User Profile：提供个性化上下文（跨会话记忆）
4. Retrieved Context：标记为可引用的来源
5. Tool Outputs：结构化实时数据，权威性最高
6. Question：最后出现，确保模型已掌握所有背景

4.4 结构化的优势

1. 调试方便：可单独检查每个区块的内容
2. 模块化替换：更新某部分不影响其他内容
3. 注意力引导：关键指令放在开头，问题放在结尾
4. 多智能体兼容：不同智能体可共享部分区块

测试表明，结构化布局比非结构化文本的准确率高10-20%，尤其在复杂查询中差异更明显。

5. 动态查询重构：从模糊到精确

5.1 用户查询的典型问题

原始用户查询往往存在：

• 缺少时间范围（"最近"、"上季度"）
• 缺少具体指标（"表现如何"）
• 使用非专业术语（"不好用" vs "延迟高"）

5.2 三种重构方法

5.2.1 澄清优先（适用于对话系统）

python复制def clarify_query(original_query):
    clarification_needs = {
        'timeframe': False,
        'metrics': False,
        'scope': False
    }
    
    # 检测缺失的时间范围
    if not any(word in original_query for word in ['最近', '去年', '季度', '月份']):
        clarification_needs['timeframe'] = True
    
    # 检测缺失的指标
    if any(vague_word in original_query for vague_word in ['表现', '情况', '如何']):
        clarification_needs['metrics'] = True
    
    # 生成澄清问题
    questions = []
    if clarification_needs['timeframe']:
        questions.append("您想了解哪个时间段的数据？（例如：2024年第一季度）")
    if clarification_needs['metrics']:
        questions.append("您最关注哪些具体指标？（例如：收入增长、用户数量、利润率）")
    
    return questions

5.2.2 HyDE（假设文档嵌入）

python复制def hyde_expansion(query):
    prompt = f"""根据以下问题，生成一段假设性的答案。保持专业但简洁：
    
问题：{query}
假设答案："""
    
    hypothetical_answer = llm.generate(prompt)
    return hypothetical_answer

# 使用假设答案进行检索
hypothetical_answer = hyde_expansion("产品最新的改进有哪些")
retrieved_docs = vector_db.query(hypothetical_answer)

5.2.3 多查询扩展

python复制def multi_query_expansion(query):
    prompt = f"""为以下查询生成5个不同表述的版本，涵盖可能的专业术语和常见说法：
    
原始查询：{query}
1. """
    
    expansions = llm.generate(prompt, n_completions=5)
    return [query] + expansions

expanded_queries = multi_query_expansion("上季度的表现与竞争对手相比如何")
# 输出：
# 1. 2024年Q4公司X与主要竞争对手财务表现对比
# 2. 去年第四季度营收和利润与同行比较
# 3. 最近三个月关键指标行业排名
# 4. 公司X与竞争对手A/B/C上季度业绩对比
# 5. 2024年10-12月市场份额变化情况

5.3 金融查询重构案例

原始查询："上季度的表现与竞争对手相比如何"

重构后查询："比较2024年第四季度（10-12月）公司X与竞争对手A、B、C在收入增长和利润率方面的表现，数据来源为公开财报"

重构使检索准确率从42%提升至78%，因为：

1. 明确了时间范围（2024年Q4）
2. 指定了竞争对手（A、B、C）
3. 列出了具体指标（收入增长、利润率）
4. 限定了数据来源（公开财报）

6. 记忆与状态：实现个性化交互

6.1 记忆系统的组成

6.2 实现方案

6.2.1 对话摘要生成

python复制def generate_dialogue_summary(conversation_history):
    prompt = f"""用150-200 Token总结以下对话的核心内容，保留：
    1. 用户的主要问题和需求
    2. 达成的共识或解决方案
    3. 用户表达的任何偏好或特殊要求
    
对话历史：
{conversation_history}

摘要："""
    
    return llm.generate(prompt)

6.2.2 记忆注入流程

mermaid复制graph LR
    A[当前对话] --> B[生成摘要]
    B --> C[存入向量数据库]
    D[新查询] --> E[向量搜索相关记忆]
    E --> F[组合到上下文]

6.2.3 编程助手案例

记忆内容：

• 技术栈：React/TypeScript
• 编码风格：函数组件+Hooks
• 项目类型：医疗数据可视化
• 历史问题：Redux异步操作

新查询："仪表板中如何处理实时更新"

响应："考虑到您现有的Redux架构，建议使用RTK Query配合WebSocket订阅，这与您之前用Redux Toolkit解决异步操作的方式一致。"

相比没有记忆的系统，个性化回答减少3-5轮澄清对话，用户体验显著提升。

7. 工具感知上下文：连接实时数据

7.1 工具集成架构

python复制class ToolManager:
    def __init__(self):
        self.registered_tools = {
            'get_live_price': {
                'description': '获取股票实时价格',
                'parameters': {'symbol': 'str'},
                'example': {'symbol': 'AAPL'}
            },
            'get_news': {
                'description': '获取公司最新新闻',
                'parameters': {'company': 'str', 'limit': 'int'},
                'example': {'company': 'Microsoft', 'limit': 3}
            }
        }
    
    def execute_tool(self, tool_name, params):
        if tool_name == 'get_live_price':
            return stock_api.get_price(params['symbol'])
        elif tool_name == 'get_news':
            return news_api.get_company_news(params['company'], params.get('limit', 1))
    
    def get_tool_description(self):
        return json.dumps(self.registered_tools)

7.2 结构化工具输出

json复制{
  "tool_name": "get_live_price",
  "output": {
    "symbol": "HDFCBANK",
    "price": 1842.50,
    "currency": "INR",
    "timestamp": "2025-02-19T14:30:00Z",
    "source": "NSE"
  },
  "error": null,
  "execution_time": "0.45s"
}

7.3 金融助手工作流

1. 用户查询："HDFCBANK的最新股价和新闻"
2. 工具决策：调用get_live_price和get_news
3. 结构化结果注入上下文
4. 模型生成回答：
   • 当前股价：₹1,842.50（+2.3%）
   • 最新新闻：宣布每股₹19股息

关键优势：

1. 数字来自权威源，无幻觉
2. 信息实时更新
3. 回答可验证（提供数据来源和时间戳）

8. 技术选型指南

8.1 各技术适用场景

8.2 实施路线图

1. 基础阶段（1-2周）：

   • 为所有文档添加时间戳
   • 实现简单的日期过滤
   • 设计基本上下文模板

2. 进阶阶段（3-4周）：

   • 添加交叉编码器重排
   • 实现HyDE查询扩展
   • 集成1-2个关键工具

3. 优化阶段（持续迭代）：

   • 添加记忆系统
   • 实现自动压缩
   • 完善监控和调试工具

9. 避坑指南与实战经验

9.1 常见错误与解决方案

1. 过度检索：

   • 症状：回答包含无关信息
   • 修复：添加严格的分层过滤
   • 经验值：最终上下文应≤8个文本块

2. 压缩失真：

   • 症状：关键细节丢失
   • 修复：添加"必须保留"关键词列表
   • 检查点：人工抽样验证压缩质量

3. 记忆膨胀：

   • 症状：响应变慢，成本增加
   • 修复：设置记忆TTL（如90天）
   • 指标：记忆库应≤1000条/用户

4. 工具超时：

   • 症状：响应延迟高
   • 修复：设置500ms超时，降级处理
   • 备用方案：缓存最近结果

9.2 性能优化技巧

1. 重排加速：

   • 使用小型交叉编码器（如MiniLM）
   • 先向量检索Top 50，再重排Top 5

2. 压缩优化：

   • 对文档预生成章节摘要
   • 对小文档（<1000 Token）跳过压缩

3. 记忆检索：

   • 为摘要添加关键词标签
   • 使用混合搜索（关键词+向量）

4. 工具调用：

   • 并行调用独立工具
   • 对频繁查询实现本地缓存

10. 效果评估与持续改进

10.1 核心评估指标

1. 准确率：

   • 人工评估100个样本
   • 关键指标：事实正确性、完整性

2. 效率：

   • Token使用量（输入/输出）
   • 端到端延迟

3. 成本：

   • LLM调用次数
   • 工具API调用成本

4. 用户体验：

   • 所需澄清轮数
   • 用户满意度调查

10.2 A/B测试方案

python复制def run_ab_test(user_query):
    # 对照组：原始流程
    control_result = original_pipeline(user_query)
    
    # 实验组：新上下文工程技术
    test_result = enhanced_pipeline(user_query)
    
    # 评估维度
    metrics = {
        'accuracy': human_evaluation(control_result, test_result),
        'token_usage': {
            'control': count_tokens(control_result),
            'test': count_tokens(test_result)
        },
        'latency': {
            'control': measure_latency(control_result),
            'test': measure_latency(test_result)
        }
    }
    
    return metrics

10.3 迭代优化循环

code复制收集反馈 → 识别瓶颈 → 针对性优化 → A/B测试 → 监控 → 收集反馈

关键点：

1. 每次迭代只改变一个变量
2. 保留足够的基线数据
3. 监控长期效果（如用户留存率）

11. 典型应用场景解析

11.1 金融研究助手

挑战：

• 处理实时市场数据
• 避免财务数字幻觉
• 保持专业术语一致性

解决方案：

1. 工具集成：实时股价、财报数据
2. 严格引用：标注每个数字的来源
3. 术语库：确保表述符合行业标准

上下文示例：

code复制[System Rules]
回答精确到小数点后两位
标明所有数据来源
使用正式财务术语

[Tool Outputs]
- live_price("AAPL"): 182.34 (NYSE, 2024-03-15 10:00 EST)
- earnings("AAPL", "Q1 2024"): EPS=1.89, Revenue=$123.5B

[Question]
苹果公司上季度每股收益是多少？

11.2 医疗问答系统

挑战：

• 确保医疗建议安全
• 处理复杂医学术语
• 区分不同可信度来源

解决方案：

1. 来源分级：临床指南>研究论文>科普文章
2. 安全护栏：禁止诊断建议
3. 术语解释：自动添加括号说明

上下文示例：

code复制[Retrieved Context]
DOC 1 (可信度A): 《2024 ADA糖尿病指南》
- 二甲双胍仍是一线用药(证据等级A)
- SGLT2抑制剂对心肾保护作用(证据等级B)

DOC 2 (可信度B): 《JAMA 2023年研究》
- 新型GLP-1受体激动剂减重效果显著

[Safety Check]
本回答仅供参考，不能替代专业医疗建议

11.3 技术支持机器人

挑战：

• 处理产品特定问题
• 理解用户非专业描述
• 引用正确的文档版本

解决方案：

1. 版本感知：根据用户产品版本过滤文档
2. 查询扩展：将用户语言映射到技术术语
3. 步骤拆解：复杂操作分步指导

上下文示例：

code复制[User Profile]
- Product: Database Server
- Version: 2.3.1
- Skill Level: Beginner

[Retrieved Context]
DOC 1 (v2.3.x): 备份恢复指南
- 新版使用`pg_backup`替代旧命令
- 添加了进度显示功能

[Question]
如何备份我的数据库？

12. 前沿发展与未来方向

12.1 新兴技术趋势

1. 动态上下文窗口：

   • 根据查询复杂度自动调整窗口大小
   • 关键信息固定位置，其余内容动态加载

2. 多模态上下文：

   • 结合文本、表格、图表
   • 图像关键信息提取为文本描述

3. 自适应压缩：

   • 基于查询类型自动选择压缩策略
   • 机器学习预测最佳压缩率

4. 记忆压缩：

   • 将长期记忆提炼为"用户画像向量"
   • 减少存储需求同时保留个性化能力

12.2 实施建议

1. 从简单开始：

   • 先实现日期过滤和基本模板
   • 逐步添加更复杂功能

2. 监控驱动优化：

   • 跟踪每个环节的Token使用
   • 记录常见失败模式

3. 平衡成本收益：

   • 不是所有查询都需要全套处理
   • 简单查询走快速通道

4. 持续教育团队：

   • 上下文工程需要跨领域知识
   • 定期分享最佳实践

13. 资源与工具推荐

13.1 开源库选型

13.2 商业解决方案

1. 检索增强：

   • Pinecone（向量数据库）
   • Cohere（重排API）

2. 上下文管理：

   • Azure AI Studio
   • Google Vertex AI

3. 工具平台：

   • Zapier（无代码集成）
   • Make（自动化工作流）

13.3 学习资源

1. 论文：

   • 《Lost in the Middle: How Language Models Use Long Contexts》
   • 《Precise Zero-Shot Dense Retrieval without Relevance Labels》

2. 书籍：

   • 《Designing Machine Learning Systems》
   • 《Building LLM Powered Applications》

3. 教程：

   • Coursera: "Advanced RAG Techniques"
   • DeepLearning.AI: "LLM Application Engineering"

14. 团队协作与知识管理

14.1 上下文工程团队组成

1. 数据工程师：

   • 构建和维护文档管道
   • 实现元数据标记系统

2. 机器学习工程师：

   • 优化检索和重排模型
   • 开发压缩算法

3. 产品经理：

   • 定义评估指标
   • 平衡功能与成本

4. 领域专家：

   • 验证回答准确性
   • 提供专业术语指导

14.2 知识共享实践

1. 上下文案例库：

   • 收集典型成功/失败案例
   • 标注问题和解决方案

2. 模式手册：

   • 记录已验证的上下文模板
   • 维护术语转换表

3. 定期评审：

   • 每周分析Top错误
   • 每月分享优化成果

15. 伦理与合规考量

15.1 关键风险领域

1. 信息准确性：

   • 建立事实核查流程
   • 明确免责声明

2. 数据隐私：

   • 匿名化用户记忆数据
   • 提供记忆清除选项

3. 公平性：

   • 检测并消除偏见
   • 确保多语言支持

15.2 合规检查清单

1. 所有数据来源合法授权
2. 医疗/金融建议有明确免责
3. 用户数据存储加密
4. 提供人工复核通道
5. 记录关键决策依据

16. 从Demo到生产的进阶路径

16.1 成熟度模型

16.2 规模化挑战

1. 性能瓶颈：

   • 实现异步处理管道
   • 对简单查询启用缓存

2. 一致性维护：

   • 版本化上下文模板
   • 自动化回归测试

3. 监控体系：

   • Token使用警报
   • 异常回答检测

17. 成本控制策略

17.1 主要成本驱动因素

1. LLM调用（尤其是压缩和重排）
2. 向量数据库操作
3. 工具API调用
4. 存储（记忆系统）

17.2 优化技巧

1. 分层处理：

   • 简单查询跳过重排
   • 短文档跳过压缩

2. 缓存策略：

   • 缓存常见查询结果
   • 预生成热门文档摘要

3. 预算控制：

   • 设置每日上限
   • 成本异常警报

18. 调试与故障排除

18.1 常见问题诊断

1. 幻觉回答：

   • 检查上下文是否包含正确信息
   • 验证工具调用是否成功

2. 遗漏关键点：

   • 审查检索过滤条件
   • 检查压缩是否过度

3. 响应缓慢：

   • 分析各环节延迟
   • 检查工具超时设置

18.2 调试工具包

1. 上下文检查器：

   • 可视化最终上下文结构
   • 标注每个部分的来源

2. 检索分析器：

   • 显示原始检索结果
   • 对比重排前后变化

3. 记忆查看器：

   • 展示活跃记忆片段
   • 显示相关性评分

19. 定制化开发指南

19.1 领域适配步骤

1. 术语表构建：

   • 收集领域专业术语
   • 创建同义词映射

2. 文档预处理：

   • 添加领域特定元数据
   • 设计专用分割策略

3. 评估集创建：

   • 收集典型用户查询
   • 标注预期回答标准

19.2 垂直行业方案

1. 法律领域：

   • 强调条款精确引用
   • 添加法域过滤器

2. 教育领域：

   • 适配不同认知水平
   • 支持渐进式提示

3. 电商领域：

   • 实时库存集成
   • 个性化推荐记忆

20. 终极建议与个人心得

在实际项目中落地上下文工程技术，以下几点经验尤为宝贵：

1. 数据质量优先：再先进的算法也无法弥补垃圾输入。投入时间清洗和标记文档库，这比后续任何优化都重要。我们曾用两周时间完善文档元数据，使准确率直接提升40%。

2. 渐进式复杂化：不要试图一次性实现所有技术。从简单的日期过滤开始，逐步添加重排、压缩等功能。每增加一层复杂度，都要验证收益是否超过成本。

3. 监控一切：记录每个环节的Token使用、延迟和中间结果。这些数据是优化的黄金资源。我们通过分析发现，80%的查询只需要20%的功能，于是为简单路径创建了快速通道。

4. 用户体验闭环：建立用户反馈机制，特别是错误案例收集。最终用户发现的边缘情况，才是最需要解决的现实问题。我们设置了"回答质量评分"按钮，收集了最有价值的改进方向。

5. 团队知识共享：上下文工程需要跨领域知识。定期举办案例分享会，让数据工程师、ML工程师和产品经理相互理解各自环节的挑战。我们每周的"怪异失败案例"会议产生了许多创新解决方案。

6. 保持简单：当面临选择时，选择更简单的方案。复杂系统难以维护和调试。曾有一个功能使用精美但复杂的记忆系统，最终被简单的关键词标记方法取代，因为后者更可靠且易于理解。

7. 关注基础指标：不要被高级功能迷惑，始终监控核心指标：回答准确率、响应时间和成本。所有优化都应至少改善其中一项而不损害其他。我们每月进行一次"基础指标回顾"，确保不偏离核心目标。

8. 预留演进空间：设计系统时考虑未来扩展。例如，为文档元数据预留额外字段，为工具集成设计通用接口。六个月前预留的"用户反馈标记"字段，后来成为个性化改进的关键数据源。

上下文工程不是一次性项目，而是持续优化过程。从我们实施的经验看，系统上线后前三个月的持续迭代，通常能使关键指标再提升50-100%。保持耐心，持续改进，最终会构建出真正可靠的大模型应用系统。