Notes

Agent 什么时候该写 memory？现在的 agent 基本靠启发式规则或人工设定。更理想的方式可能是根据"信息价值"动态决定——但这需要 agent 能评估自己的知识边界，而这是很难的。 一个折中方案：让 agent 在每次任务完成后做简短的"知识更新报告"，作为 memory 写入的触发信号。

检索系统的质量评估比想象中难。传统的 precision/recall 在实际场景里很难定义 ground truth——用户想要的东西往往不是文档里有明确答案的。 最近在看一些 embedding-based retrieval 的评估方法，发现难点在于： 1. 语义相似 ≠ 检索价值高 2. 单次查询很难评估，需要看长期的用户满意度 3. 分布偏移会导致离线指标和在线指标不一致 可能的解法：结合用户行为信号做持续评估，而不是依赖固定的测试集。

Meta 的 MemGPT 论文，关于大模型在长对话中的 memory 管理。核心思路是把 memory 分层（working memory、recent memory、episodic memory、semantic memory），用类似 OS 的方式管理。 想法有意思，但实际效果还需要更多场景验证。

当前向量数据库的格局： - **Pinecone**：云原生，易用性好，但成本高 - **Milvus**：开源，可控性好，部署复杂 - **Qdrant**：Rust 实现，性能好，社区活跃 - **Chroma**：简单，适合研究和原型 在实际项目中选型，主要看： 1. 数据规模 2. 延迟要求 3. 运维能力 4. 是否需要支持混合检索（稀疏 + 稠密） 向量数据库本身的技术壁垒不高，核心竞争力在于工程化程度和生态。

在做一个复杂 AI 系统时，工程层面至少要分三层考虑： **基础设施层**：模型服务、推理优化、资源调度。关注的是性能、成本、可观测性。 **Agent 层**：任务分解、工具调用、memory 管理。关注的是任务完成率、错误恢复、上下文保持。 **应用层**：用户体验、反馈收集、持续优化。关注的是用户价值、迭代速度。 很多 AI 项目出问题，往往是因为把三层混在一起做，或者只关注某一层。

Claude 3 发布了。上下文从 200K 升级到 1M，性能提升显著。多模态能力也补上了。 对于需要长文档处理和复杂推理的场景，context 长度的提升是实质性的改进。

自动驾驶的数据闭环，有三个核心问题： **数据采集**：什么场景需要采集？采了之后怎么筛选？成本和覆盖度的平衡？ **数据标注**：corner case 的标注成本高、定义模糊。怎么提高标注效率和质量？ **模型更新**：新的数据怎么高效地反映到模型里？增量训练还是全量重训？怎么验证更新后的模型？ 这三个问题相互依赖，数据采集策略影响标注成本，标注质量影响模型效果，模型效果又影响数据采集的优先级定义。 很多团队把这三个问题分开优化，结果发现局部最优不等于全局最优。

随着 context window 越来越大，一个新的工程问题出现了：**context 的经济学**。 在固定成本下，应该怎么分配 context： - 放更多历史对话 - 放更多检索结果 - 放更详细的系统 prompt - 放用户提供的文档 不同分配的 ROI 不同，而且随任务变化。 一个反直觉的观察：有时候放更少但更相关的信息，效果反而比塞更多检索结果好。 本质上是信号噪声比的问题。当前的模型在长 context 里注意力分散的问题还没完全解决。

Embedding 模型选型的一些经验： **通用场景**：OpenAI 的 text-embedding-ada-002 够用，效果稳定，但有成本和延迟。 **中文场景**：最近的 BGE、InternLM-Embedder 效果不错，开源可控，可以私有化部署。 **专用场景**：如果能做领域 fine-tuning，提升往往很明显。但 fine-tuning 成本高，需要数据量支撑。 评估 Embedding 模型：MTEB 榜单是参考，但不能完全依赖。自己的数据、自己的 query、自己的 metric 才是标准。

Agent 系统的错误处理比传统软件难很多，因为： 1. Agent 的行为有不确定性，同一个输入可能产生不同输出 2. 错误可能发生在执行、推理、工具调用等多个环节 3. 某些"错误"其实是合理的探索行为 一个实用的分层错误处理： **快速失败**：明显的无效输入、无权限操作等，立即返回错误，不浪费 context。 **可重试失败**：网络超时、API 限流等，可以重试几次。 **降级策略**：当某个工具不可用时，尝试备选方案或给出部分结果。 **人工介入**：当系统判断无法继续时，生成清晰的上下文摘要，交给人工处理。 关键是**错误信息要有足够的上下文**，让决策者（另一个 agent 或人）能做出合理判断。

平台工程（Platform Engineering）最近很热，但很多团队做偏了。 好的平台工程的本质是：**降低开发者认知负担，提高团队协作效率**。 具体来说： - 让开发者不需要深入了解 infra 细节就能跑通服务 - 让跨团队的协作有标准化的接口和流程 - 让故障定位和恢复有工具支持 不好的平台工程： - 做了一堆"平台工具"，但每换一个团队就要重新学一遍 - 把内部工具做得很炫酷，但解决不了实际问题 - 把平台团队变成了审批和瓶颈 评判一个平台做得好不好：看它是否让业务开发团队更高效，而不是看平台团队自己有多少产出。

RAG（Retrieval Augmented Generation）系统的优化空间主要在三个方向： **检索优化**：query rewriting、hybrid search、reranking... 让检索结果更相关。 **生成优化**：prompt engineering、context compression、answer synthesis... 让模型更好地利用检索结果。 **迭代优化**：多轮查询、self-RAG、active retrieval... 让系统能够动态调整检索策略。 实践中发现，很多团队只优化检索，不优化生成。实际上，生成侧的优化往往投入产出比更高——因为检索结果的提升空间有限，而好的 prompt 设计可以让同样的检索结果发挥更大价值。