plusxiaxia

昨天和微软的朋友聊AI employee，讨论到了数字分身。我自己的看法，数字分身可以是AI employee的一部分，但不能完全等价。当一个事情，足以改变就有的生产方式，组织结构，才能够称上革命。按照现在组织架构给每个岗位构建数字分身。显然是被当下给局限了。 真正要做的是，在智力和执行力被充足供应的情况下，思考有无新的岗位，为新的优质生产力设计工作流。

普通 RAG 的隐含假设是： 用户问题 → 检索 top-k → 生成答案 Agentic RAG 的改进是： 用户问题 → 拆解问题 → 多路检索 → 判断证据够不够 ↑ ↓ 缺什么 ← gap feedback 这其实非常像 Memory Engineering 里的一个基础原则： memory retrieval 不是“找一些相关内容”，而是“证明当前上下文足以回答问题”。 也就是说，Memory 系统不应该只返回 chunks，而应该返回： - 已找到什么证据 - 每个证据支持问题中的哪一部分 - 还有哪些 slot / sub-question 没被覆盖 - 是否需要继续检索、换 query、换 corpus - 如果仍然没有，是否应该明确拒答或标注缺失 这比“向量库 + rerank”高级一层。 2. 这篇真正有用的模块：Sufficient Context Agent Google 说它检查三样东西： - retrieved snippets：检索到的原文片段 - intermediate draft：中间草稿答案 - missing pieces analysis：缺口分析 这个设计很重要。 因为很多 RAG 系统的问题不是“没检索到东西”，而是： 检索到了一堆看起来相关的东西，但其实只覆盖了问题的 60%。 例如医生那个问题里，用户问了： - discharge medications - dietary restrictions - allergic reactions - 还要求排除 inpatient / emergency meds，除非是 heparin IV drip 或 Tenecteplase 普通 RAG 可能检索到药物和饮食就开始答了。 但 Sufficient Context Agent 会问： 原问题里有几个约束？ 每个约束有没有证据？ 有没有 evidence gap？ gap 是什么？ 下一轮该搜什么？ 这对 Memory Engineering 很关键，因为 memory 系统经常面对的不是简单事实查询，而是“带约束的历史上下文重建”。 比如： - “我上次说过不喜欢什么样的播报？” - “这个项目之前为什么决定不用方案 A？” - “之前我们关于 Agent Memory 的判断依据是什么？” - “帮我续写上次那个系统，但不要重复已否掉的方向。” 这些都不是单次 semantic search 能稳定解决的。 3. 可以抽象成一个 Memory Retrieval Verifier 我会把这篇文章里的启发抽成一个组件： User Query ↓ Intent / Constraint Parser ↓ Memory Query Planner ↓ Multi-source Retrieval ↓ Evidence Ledger ↓ Sufficiency Verifier ├─ enough → Answer / Act └─ not enough → Gap-specific Retrieval 其中最重要的是两个 ledger： Evidence Ledger 记录： claim: 用户问 discharge meds evidence: discharge summary paragraph 3 source: clinical_notes / discharge_summary confidence: high Gap Ledger 记录： missing: allergic reactions during stay why_missing: current snippets only mention discharge meds and diet next_query: rash OR adverse event OR allergy OR reaction next_source: clinical notes / nursing notes 这比传统 RAG 的 source citations 更进一步。 传统 citation 是“我引用了哪里”。 Memory Engineering 需要的是： 我为什么认为这些记忆已经足够？ 我还缺什么？ 我是否为了补缺口继续搜过？ 4. 对 Agent Memory 的直接启发 我觉得可以分成四层： 第一层：Memory retrieval 不该是 top-k，而是 coverage search 不要问： 找和问题最相关的 10 条记忆 而要问： 这个问题包含哪些子问题 / 约束？ 每个子问题有没有 memory evidence？ 这尤其适合长期记忆、项目记忆、用户偏好记忆。 第二层：Memory search 要允许“失败后继续找” Google 文章里说的 persistence，其实就是： 第一次没找到，不等于不存在；可能是 query formulation 错了，或者 source 选错了。 对 memory 系统也是一样。 比如用户问： “之前我们怎么定的内容方向？” 如果搜 “内容方向” 没搜到，不应该马上说不知道。应该继续搜： - 选题方向 - 内容策略 - Supreme Directive - 早报偏好 - Agent Memory - 个人提效 - 企业 AI 转型 这就是 query rewrite + gap search。 第三层：Memory namespace / corpus routing 很重要 Google 的 cross-corpus retrieval 对企业场景是： finance db project logs clinical notes nutrition notes pharmacy records 不同 corpus 的可信度、时效性、用途不同。 所以 Memory Engineering 不能只有一个大向量库。更好的方式是： query → 判断该去哪个 memory namespace 找 例如： - 用户偏好 → persistent memory - 上次对话细节 → session_search - 项目决策 → repo docs / plans / issues - 内容素材 → saved第四层：stop condition 是关键 Agentic RAG 最大的问题是容易无限搜。 所以 Sufficient Context Agent 的价值还包括：决定什么时候可以停。 Memory 系统也应该有类似 stop condition： 如果所有 required slots 都有证据 → 停 如果经过 N 次 gap search 仍缺失 → 明确说明缺失 如果找到互相冲突的 memory → 标注冲突

之前刷到过她老公的视频，确实是太能折腾了，处女座的开店真是灾难，完美主义者做什么事都追求极致。 4500万全部亏光，本来躺平也是A8富豪。所以说中产返贫三件套，最大一套就是创业干餐饮。网友说拿4500万做 4% 保本理财，每年稳赚180万，每月就是15万，每天睡醒就是 5000 元到账不香吗。