RAG

TEPCA在证据层和参数层同时做时间对齐：时间约束的路径剪枝+互信息筛选保证证据链时序一致，时间条件化的DG-LoRA让低秩适配随查询时间动态变化，在ICEWS14/GDELT上刷新SOTA。

DKGI抛弃预定义图API，直接把完整知识图谱导出为节点/边文件，让LLM Agent用Python自己写图访问代码并随执行反馈迭代，免训练在STaRK三个图谱上全面超越最强基线至少6.7个Hit@1点。

把生物医学句向量检索器转换为System One类型化决策模型：交叉头+交叉熵+温度缩放是最优选型，RLCD的策略梯度项因奖励归一化偏差而落后2.5-3分。

categories: [“论文精读”] summary: “一条几乎全由确定性代码构成的检索链（混合召回+重排+证据包编译+机械脚手架），LLM只在最后当可替换阅读器，在LongMemEval-S上双跑479/475，正负跨过已发表SOTA 478——并诚实量化了评委噪声。” 📌 系列导航：🔥 日报 · 📚 周报 · 📡 技术雷达 · 📄 论文精读 · 📮 情报站 论文信息 项目 内容 日期 2026-10-01 论文 Auditable Long-Term Memory: A Deterministic Retrieval Chain Measured at 479/475 of 500 on LongMemEval-S 作者 Christopher J. Chanhnourack（Centennial Defense Systems） 链接 arXiv:2609.38021 代码/证据 longmemeval-evidence（MIT，含数据包、评委裁决、对照组记录） 领域 RAG / 长程记忆检索 一句话总结 把长程对话记忆系统里LLM的角色压缩到最后一步"读证据包并作答"，其余检索全链路用确定性代码实现，在LongMemEval-S上双跑得分479/475，恰好骑在已发表SOTA（478）两侧——同时用两遍规则、第二评委和负对照，把排行榜上一两分差距其实是测量噪声这件事摆到了台面上。 解决什么问题 带长期记忆的对话助手需要回答"我一共看过几位医生"这类问题，证据散落在几十个历史会话里。真正的失败是安静的失败：系统没检索到那个关键会话，却能流利地给出错误答案。而且事后无法核查"它为什么这么答"。现有方案（MemGPT、Mem0、Zep等）把智能塞进记忆管理和LLM调用里，过程不可审计。另外，长上下文榜单顶部的分差只有几分，单次跑分+LLM评委，让排名部分成了测量噪声的产物。 核心方法 五段式链条，前四段全是确定性代码，字节级可复现： 混合候选召回：稠密向量检索 + 关键词全文检索 + 一条有界语义扩展通道（只增候选不重排）。470个可答题中468题的金标会话全部进入候选池，其中10个金标会话只靠语义扩展通道捞回。 交叉编码器重排：bge-reranker-v2-m3 对每个会话按问题打分，会话分=最大chunk分，fp16定批+按先前名次打破平局，保证排序确定。 覆盖优先的证据包编译：硬预算16会话/40k token。稠密基线top-10原样保留为前缀，其余槽位按交叉编码器序填充并做保词抽取压缩；超出预算先丢最低名次的扩展。462/470题的证据包是"金标完备"的。编译器通过金标打乱、ID破坏、双编译字节一致等负对照验证。 确定性推理脚手架（约240题启用）：从证据包机械地生成时间线、用户陈述的时钟粒度新鲜度序、取值偏好不变量、计数枚举汇总——代码实现，内部不一致即抛错。 可替换阅读器：LLM只出现这一次。同一批冻结证据包喂给8个不同阅读器（闭卷93分到Opus 479分的阅读器曲线），换阅读器不用动上游任何东西。 最值得学的是测量纪律：发布前冻结"双跑一致才算数"的晋升规则；用第二评委（GLM-5.3）复评，一致率98.6%但双跑都只给472；官方评委对字节相同的答案复评也会翻3个裁决。任何"改进组件"先过60行负对照（曾在基线正确的题上零翻转才准上线）——一个能修好3道错题的验证器因为弄坏了11道对的题而被否决。 实验结果 Opus阅读器双跑：479/500 与 475/500（官方GPT-4o评委），报为477±2，骑跨Chronos High的478；双跑稳定下限473。 grok-4.6-high同包：476/474；最高推理档agentic变体反而退步到461/465（20个损失里15个是"过度怀疑"签名：该答的弃答、计数过滤过头）。 评委噪声：官方评委复评字节相同的pass-1答案从479变478；两个评委在500行里分歧7行。 负对照抓住的真陷阱：xhigh变体上线前的25行探针（找回9题）和60行零翻转对照都看涨，全量双跑却净回归——60行对照撞上约3.4%真实翻转率时有约13%概率恰好零翻转。 分类别看：对SOTA的净+1来自multi-session +2、SSU/TR各+1，抵掉knowledge-update −3。 深层洞察 这篇真正的贡献不是"479"，而是三件事。其一，可审计性可以工程化：LLM退到"可替换阅读器"这个角色后，从证据包往后的每个产物都能发布、复核、换模型重跑——这比黑盒agent记忆系统在严肃场景（本文作者来自国防承包商，背景不言自明）的价值大得多。其二，榜单顶部是噪声海：一分之差小于评委自身的翻转率，社区却常拿它排座次；文中顺手指出Mastra的94.87%其实是类别平均、原始分468，OMEGA的95.4%换了个非官方评委。其三，负对照是防自欺的唯一手段：能修复3个错误样本的组件，可能在你看不见的地方毁掉11个正确样本；小规模探针+小对照集在3.4%翻转率下根本不够置信。 ...

CMC 框架把长上下文压缩成与答案对齐的记忆嵌入，冻结解码器即可使用，SQuAD 提升 7.3 EM，推理省时省电 20%、峰值显存减半。

PACE诊断出点积训练失败的两大病灶——角度-范数纠缠与方向各向异性，用两阶段课程（余弦+LoRA → 点积+全参微调）加Focal Embedding Loss，让嵌入范数真正参与语义编码。

ViSAR完全在ColPali/ColQwen2.5的嵌入空间内操作，构建查询条件化的页级相似度矩阵动态决定检索页数：平均只取4.7页（固定top-10、启发式方法取15-18页），端到端延迟最高降58.7%，精度还略有提升，且相似度矩阵稀疏度与答案对错正相关——一个免费的检索质量监控信号。

仓库级代码生成中，错误的代价并不均等：少数关键token一旦生成错误，整段代码就滑向错误语义路径。ACToR在生成时识别这些关键token并按需触发针对性检索，在CoderEval上相对提升15.4%。

七个通用工具的图推理智能体 GRA，在工业混合知识图谱上以不到三分之一的输入 token 胜过全量上下文基线 5.1 个百分点——赢在’选择性访问’而非图拓扑本身。

上下文越长不一定越好——信息丰富的训练上下文会让模型变得’依赖上下文’，削弱参数化知识。

问题：AI编码的成功为什么难以复制？ 越来越多的团队在尝试AI辅助编码。但一个普遍现象是：成功案例很多，成功复制却很难。 某个项目用AI写代码效率翻倍，换个项目就不行了；某个工程师用AI很顺手，换个人就各种踩坑。问题出在哪？ 本质是上下文的缺失，也是驾驭能力的缺失。 AI编码不是简单的提问-生成代码，而是需要三层上下文的支撑：编程环境上下文、项目上下文、需求上下文。任何一层的缺失，都会导致AI生成的代码无法落地。 平台要解决的核心问题，就是让这三层上下文可复制，让AI可被有效驾驭。 理论基础：从Prompt到Harness的三阶段演进 第一阶段：Prompt Engineering（提示词工程） 时间：2022年底至2024年初 核心理念：关注说什么 在这个阶段，所有主流的AI教程都着重讲解如何创建一个完美指令——角色扮演、Few-shot、Step-by-step等技巧。用户是绝对掌控者，模型是基于单条指令完成任务的被动执行者。 模型没有记忆、没有工具，每一次交互都是独立的条件概率生成。 第二阶段：Context Engineering（上下文工程） 时间：2024年至2025年初 核心理念：关注配置环境 随着模型上下文窗口的扩充（从4K到128K/200K tokens），业内开始形成共识：相较于研究提示词如何遣词造句，更重要的是以系统性框架（RAG知识库、系统提示词、Memory记忆系统、工具调用接口）为模型构建信息环境。 用户从直接发号施令者转变为情境构建者——负责判断当前情况，提供信息与资源；模型则在给定的上下文环境中，自行判断如何应对。 第三阶段：Harness Engineering（驾驭工程） 时间：2025年初至今 核心理念：关注让什么发生 随着Claude 4.6、GPT-5.4 Codex、Gemini 3.1 Pro等具备深度Agentic能力的模型成熟，新的范式被提出——Harness Engineering（驾驭工程）。 “Harness"在英语中意为马具/缰绳。它不是动力本身，但它决定了动力能否被稳定地使用。AI像一匹很快的马，但需要一套缰绳才能被驾驭。 核心定义：设计一套环境与机制，使AI Agent能在可控边界内持续自主工作。 核心理念：人类引导，智能体执行（Humans steer, Agents execute） 驾驭工程的四个核心动作 Harness Engineering的核心可以概括为四个动词： 1. Constrain（约束）：设定边界 问题：AI会产生幻觉，会偷懒，会写出看似能跑实则一团糟的代码。 解决方案：通过不变量约束，而不是微观管理实现细节。 具体做法： Guardrails护栏：定义AI不可逾越的行为边界 权限分级：不同场景下AI的能力范围 沙箱隔离：Docker容器隔离，任务完成后销毁 架构约束：强制执行依赖方向（如 Types→Config→Repo→Service→Runtime→UI） 2. Inform（告知）：提供信息 问题：AI只能访问运行时上下文中的知识，其他都等于不存在。 解决方案：把上下文推回仓库，结构化组织信息。 具体做法： 渐进式披露：给AI一张地图（AGENTS.md），而不是1000页说明书 结构化docs/目录：设计文档、产品规格、技术参考 可观测性数据：日志、指标、追踪（LogQ、PromQL） UI能力：Chrome DevTools协议，让AI能读取界面、截图、导航 3. Verify（验证）：检查结果 问题：AI生成的代码未必符合要求，需要验证。 解决方案：建立评估机制，让验证自动化。 具体做法： Evals评估：为每个产品领域和架构层打分 智能体评审：AI评审AI的代码 结构测试：验证架构依赖是否合规 CI任务：校验知识库是否最新、结构是否正确 4. Correct（纠正）：修正问题 问题：发现问题后，如何让系统自我修复？ ...

传统 RAG 的困境 如果你用过 RAG（检索增强生成），应该熟悉这套流程： 文档切片（chunking） 向量化（embedding） 存入向量数据库 查询时检索 Top-K 相似片段 喂给 LLM 生成答案 这套方案有个致命问题：切片粒度很难把握。 切太小，语义不完整；切太大，噪音太多。更麻烦的是，向量相似度检索本质上是模糊匹配——它能找到相关的内容，但不一定能找到精确的内容。 比如你问项目预算在第几章？，向量检索可能返回一堆提到预算的片段，却无法告诉你精确的章节位置。 PageIndex 的思路：给 AI 一张地图 PageIndex 的核心理念很简单：不用向量，用结构。 它把文档解析成一棵层级树： 文档 ├── 第一章 概述 │ ├── 1.1 项目背景 │ └── 1.2 目标与范围 ├── 第二章 技术方案 │ ├── 2.1 架构设计 │ └── 2.2 技术选型 └── 第三章 实施计划 这棵树直接放在 LLM 的上下文窗口里。检索时，LLM 像人一样读目录找答案： 问题：架构设计在哪？ → LLM 定位到 第二章 > 2.1 架构设计 问题：项目总体目标是什么？ → LLM 定位到 第一章 > 1.2 目标与范围 这就是 推理即检索（Reasoning-based Retrieval）。 ...