Structured Distillation for Personalized Agent Memory: 11x Token Reduction with Retrieval Preservation

论文基本信息

• 作者: Sydney Lewis
• 机构: Process-Point Technologies Corporation
• 发表日期: 2026-03-13
• 开源代码: https://github.com/Process-Point-Technologies-Corporation/searchat

一句话总结

将用户与 Agent 的对话历史压缩为 38 token/exchange 的结构化检索单元，在保留 96% 检索质量的同时实现 11x 压缩，使数千次 exchange 可纳入单一 prompt。

摘要（翻译）

与 AI agent 的长时间对话产生一个简单问题：历史是有用的，但逐字携带成本高昂。本文研究个性化 agent 记忆：将一个用户与 agent 的对话历史蒸馏为紧凑的检索层以便后续搜索。

每个 exchange 被压缩为包含四个字段的复合对象： - exchange_core：核心信息 - specific_context：具体上下文 - thematic_room_assignments：主题归属 - regex-extracted files_touched：正则提取的文件

可搜索的蒸馏文本平均每个 exchange 仅 38 tokens。

应用于 6 个软件工程项目的 4,182 次对话（14,340 个 exchange），该方法将平均 exchange 长度从 371 tokens 降至 38 tokens，实现 11x 压缩。

我们通过 201 个检索导向查询、107 种配置（5 种纯模式和 5 种跨层搜索模式）、5 个 LLM 评判器（214,519 个共识评分查询-结果对）来评估个性化召回是否在压缩中存活。最佳纯蒸馏配置达到最佳逐字 MRR 的 96%（0.717 vs 0.745）。

结果与机制相关：所有 20 种向量搜索配置在 Bonferroni 校正后均不显著，而所有 20 种 BM25 配置均显著下降（效应量 |d|=0.031-0.756）。最佳跨层设置略超过最佳纯逐字基线（MRR 0.759）。

结构化蒸馏在不舍 uniform 检索质量的前提下压缩单用户 agent 记忆。以 1/11 的上下文成本，数以千计的 exchange 可纳入单一 prompt，而逐字源仍可用于深入挖掘。

核心贡献

1. 结构化压缩格式

四个字段的设计： - exchange_core：是什么（核心任务/问题） - specific_context：在什么上下文中（项目、文件、讨论线程） - thematic_room_assignments：属于哪个主题（功能、bug、refactor） - regex-extracted files_touched：涉及哪些文件（精确追踪）

这使得检索可以按字段匹配，而不只是整体相似性。

2. 11x 压缩率

• 原始：371 tokens/exchange
• 蒸馏后：38 tokens/exchange
• 保留 96% 的检索质量（MRR 0.717 vs 0.745）

3. 机制依赖性发现

关键发现：压缩效果因检索机制而异： - 向量搜索：对压缩高度容忍（20/20 配置无显著差异） - BM25：对压缩敏感（20/20 配置显著下降）

这说明蒸馏策略需要与下游检索方法联合设计。

关键方法细节

蒸馏过程

1. 结构化提取：用 LLM 将每个 exchange 解析为四字段格式
2. 正则提取：自动提取文件名、函数名等结构化信息
3. 主题标注：用 embedding 聚类确定主题归属

检索配置

107 种配置测试： - 5 种纯模式：纯蒸馏、纯逐字、纯向量、纯 BM25、混合 - 5 种跨层模式：在不同粒度层组合 - 5 个 LLM 评判器做共识评分

跨层设置

最佳跨层配置（MRR 0.759）略超最佳逐字基线（0.745），说明： - 蒸馏层 + 逐字层的组合优于单纯任何一方 - 蒸馏提供快速粗排，逐字提供精排

为什么重要

记忆压缩的实用性

上下文窗口限制（即使百万 token）vs 无限对话历史： - 不可能把所有历史都放进去 - 需要有损压缩，但要有选择地保留关键信息 - 结构化压缩提供了一种可解释、可控制的压缩方式

对 Agent 系统的启示

• 对话记忆的压缩是可行的（11x 无显著质量损失）
• 压缩策略需要适配检索方法（向量 vs BM25）
• 跨层检索（粗排 + 精排）可能是最优架构

与移动端/端侧的相关性

极致压缩需求

端侧设备存储有限： - 不能存储所有历史 - 需要高效压缩（38 tokens vs 371 tokens） - 结构化格式便于选择性加载

隐私保护

• 蒸馏后的表示可能比逐字历史更少暴露细节
• 文件名、正则提取等结构化信息可控脱敏
• 压缩本身是一种隐私增强

检索效率

• 38 tokens 的向量比 371 tokens 快近 10x
• 向量搜索对压缩的容忍性说明可以安全压缩
• 适合实时检索场景

实验结果

压缩质量

配置	MRR	相对逐字
最佳逐字	0.745	100%
最佳蒸馏（纯）	0.717	96%
最佳跨层	0.759	102%

检索方法差异

• 向量搜索（20 配置）：全不显著 → 压缩可接受
• BM25（20 配置）：全显著下降 → 压缩不适用
• 混合方法：中等敏感

参考文献

• 论文主页: https://arxiv.org/abs/2603.13017
• 开源代码: https://github.com/Process-Point-Technologies-Corporation/searchat
• Author: Sydney Lewis (Process-Point Technologies Corporation)