找回旧决定之后

假设我们接手 Harbor 项目，想知道它现在用哪家服务发交易邮件。样本里既有早期选择，也有后来明确推翻它的记录，还混入了另一个项目 Cedar 的决定。以下全部是本站编写的模拟记录。

用英文询问“Harbor 现在用哪家服务发邮件，为什么”，前两项来自 8 月 1 日的旧会话；9 月 4 日的新会话到第 6 项才出现。中文提问时，新会话首次出现在第 5 项。只读第一项，就会漏掉决定已经改变这件事。

这次 recall 返回的是排序后的片段及上下文入口。分数用于排列结果，不能解释成“这项决定目前正确”的概率。我们对新旧邮件方案、缓存、登录会话和超时设置共 7 处来源执行 get，均找回了样本中的完整原文。

• 先核对对象：名称相近、使用同一服务，不代表属于同一个项目或用途。
• 再看日期和变更关系：寻找“取代”“撤回”“改为”等明确表述，并检查它针对的是哪项旧决定。
• 展开上下文：保留完整的原因、条件和例外；原始对话里也可能包含当时的猜测、模型回答和复制进来的旧检索结果。
• 遇到矛盾仍未解释清楚时，继续查看后续记录或当前项目状态，再决定怎样使用。

14 个模拟会话共 28 条消息。我们预先写下 4 个有已知答案的问题和 1 个缺少答案的问题，每题分别用中英文问一次；保留默认前 8 项，之后再展开来源。

8 个有答案的提问，结果中都出现了当前决定的完整文字。这个结果只对应精心构造的小样本，不能当作真实项目准确率。缓存与登录方案的旧记录也仍在结果中。

样本从未写入 Harbor 的年度营销预算。询问预算的中英文问题仍各返回 8 项片段，却没有预算答案。检索列表本身没有替使用者判断“资料没有写这件事”。

我们另行下载了固定版本的 huggingface/funes-memory 公开记忆，在其中询问 4 项设计选择：只追加、推理后端、文本优先索引，以及保留原始片段。每项也分别用中英文提问。这部分是真实公开开发记录，和上面的模拟样本分开处理。

推理后端的问题在两种语言的结果中都能继续找到原因；中文提问需要展开第 3 项，才看到原生推理与构建维护成本的说明。文本优先的问题，英文上下文解释了每轮索引预算与明确指定路径的区别；中文结果更多停在界面、文档修改。

只追加与原始片段这两题，英文结果提供部分相关材料，中文前 8 项没有直接讲清所问的原因。我们没有完整的语料答案集，不能据此断言原因不存在，也不把这 4 题变成语言能力排名。

单独诊断时，我们关闭了时间衰减：旧邮件方案仍排在前面，选中的 3 个中文问题也没有因此补齐直接解释。改写一个提问作为探索，原始结果仍保留，没有用后来的尝试替换首轮结果。

本次在 8 GB 内存的 Apple Silicon Mac 上运行官方 arm64 版 funes 1.3.0，核对了发布文件、模型和公开数据的版本与校验值。程序、两个模型及分词器、公开样本合计约 1.50 GB；下载过程中处理过不完整传输，准备时间不作为标准安装耗时。

模型已下载后，模拟样本每次检索约 1.8–2.2 秒，公开样本约 5.1–6.6 秒。检索进程的最高常驻内存约 1.84 GB。每题只记录一轮，这些是命令运行观察，不含人工阅读、确认与返工，也没有证明实际节时。

原有搜索也值得比较。在同一模拟样本的回答中，直接搜索 Mailgun 会命中 3 条记录，包含 Harbor 的新旧选择和 Cedar 的选择；搜索 Postmark 只命中新决定。它的前提是已经知道准确词语。我们没有测量人工查找时间，因此没有证据建议用 funes 全面替换现有办法。

本次没有安装 Trufflehog。索引提示关闭秘密信息脱敏后，仍完成了模拟数据索引；因此不能把“索引完成”当作“已经脱敏”。真实会话、共享上传，以及编码助手调用远程模型的流程，本次均未测试。

我们的使用建议：如果你常常需要找回跨会话的旧决定，可以先用已知记录检验检索与上下文。真正接入项目后，还要比较自己原来的查找办法，以及助手有没有正确处理后来的改动。本站这次完成的是检索环节的有限试验。

下载包含 14 个模拟会话、中英文提问、本站原始模拟结果及运行说明。无需导入自己的聊天记录；样本不附带模型或程序。准备 Python 3 和官方 funes 1.3.0，解压后按 README 运行。首次模型下载约 1.26 GB。

运行脚本只索引包内模拟目录，每轮另建运行目录，随后执行 10 个提问并展开邮件方案的新旧上下文。你可以先直接阅读附带结果，再决定是否需要运行。

• funes 1.3.0 ↗官方发布取得对应系统的程序并核对发布校验值。
• README · 1.3.0 ↗固定版本命令、模型与集成的维护者说明。
• funes-memory ↗公开开发记录本次检索所用的数据版本；内容中的旧判断仍需核对。