[讨论] file.top_k 文档记录文件的数量,但实际上限制了 L2 分段

□ 说明

`RetriveFileConfig.top k'被记录为*"要取回的文件总数"*,但当前取回的管道从未将其用于绑定文件.

在`AgenticMixin. 累进取'中:

• QQ recall segments ' pass file.top k' tovector search-segments',因此,QQtop k ' 实际上是L2部分**,而不是L1文件。
• QQcollect files " 然后将那些 QQtop k " 部分滚动到它们的文件上—— 文件列表是一个 * 派生的 * 集,不是排序的封装列表 。

顺序:一个单个聊天召回文件,其片段占据了所有的"top k"插槽,在"files"层中产生准确的** 1**文件,尽管配置中写有"5个文件". 在他们投票之前 各种但又微弱的文件被挤出

□动机

`文件'层是代理商读作的"这些是我的相关记忆文件". 当一个宽文件(例如有多行的长行注文件)垄断了段窗口时,检索会隐藏所有其他相关的文件. 这是用户可见的:查询存储器,而返回的文件数量实际上无法预测——它是1至 " top k " 之间任何区段的 " 歧义( recall file id) " 。

文件层本身故意 * not * 今天的第二名搜索(ADR 0007的卷起设计). 错误是,仅以文件计数记录的** ** knob 而非默默表示分数 。

□ 候选方向(在执行前需要输入)

1. ** 高级配置,继续滚动。 ** 将取号重命名/重新文档为 " segment.top k " (或增加 " file.uplied " 清晰度)并接受 " files " 计数。 最小的变化,没有行为改变, 但记录的许诺 保持错误的。
2. ** 扩大L2窗口,继续滚动。 ** 搜索比文件目标(例如`file counts × supers per file gues',或一个新的'file.candiates'乘数)更多的片段,然后卷起并切入到'top k' 不同文件. 保留"没有第二名的搜索";一旦候选人范围更广,聊天文件仍然只能在自己的文件片段内主导. 需要每个文件段的上限或再切换以真正绑定一个文件的共享.
3. ** Rank 原生档案。 ** 文件已经带有嵌入( “ {name} ” : {description} ” ) 。 添加一个真实的文件级别排序搜索, 并使用自己的“ top k” , 先返回文件和部分作为支持证据 。 最大的变化:新的repo路径('vector search files'),可能与ADR0007的"L1没有被搜索"立场相冲突,需要自己的讨论.

目前还没有代码——这是一个语义决定,它影响了相接合同和注射结果形状,所以应该先在这里解决.

□ 平台

独立平台

□ 优先级

次要(有记录的指针的行为正确性,不是坠机)

□ 超出范围

• 分层排名质量(在其他地方覆盖)
• 改变 " 最大(部分)分数 " 的滚出分数