为LLM检索大量文档（例如前10或前20）与少量文档（例如前3）作为上下文，需要在信息广度、计算效率和相关性之间进行权衡。最佳选择取决于具体的用例、检索到的文档质量以及LLM有效处理信息的能力。
检索更多文档的优点 更大的文档集提供了更广阔的上下文，这有助于LLM生成更全面的答案。例如，在回答关于气候变化影响的问题时，检索20个文档可能包括温度趋势、区域影响和缓解策略的数据，从而允许模型综合不同的观点。这减少了遗漏少量文档可能排除的关键信息的风险。此外，如果检索系统不够精确，包含更多文档可以弥补排名中的微小错误——例如，排名较低的文档可能包含前3个文档缺乏的关键细节。然而，这假定额外的文档至少在某种程度上是相关的；不相关的内容可能会引入噪音。
检索更多文档的缺点 处理更多文档会增加计算成本和延迟。LLM有token限制，因此包含20个文档可能会导致截断，丢弃部分上下文。例如，如果每个文档是500个token，20个文档将消耗10,000个token，留给实际查询或响应的空间就很小了。不相关的文档也有使模型混淆的风险。假设用户询问Python调试，而前10个文档包含三个过时的Stack Overflow讨论串；LLM可能会优先考虑过时的解决方案。此外，更长的上下文可能导致“迷失在中间”的行为，即模型在过多的文本中难以专注于最关键的信息。
何时使用少量文档 当优先考虑精度而非广度时，仅检索前3个文档的效果最佳。对于“如何安装库X”这样的直接查询，前3个结果很可能足够且能最小化噪音。这种方法计算效率高，减少了token使用量和成本。它也不太容易出现信息冲突——例如，如果前3个文档都认同某种方法，LLM可以自信地生成清晰的答案。然而，这种策略假定检索系统高度精确。如果前3个文档存在偏差或不完整（例如，缺少关键的安全补丁说明），LLM的输出将反映这些不足之处。测试是关键：开发者在限制上下文之前，应该评估他们的检索系统是否能持续地在前几名中呈现高质量的结果。
总之，较大的文档集提供了广度，但有低效率和噪音的风险；而较小的文档集优先考虑精度，但要求检索精度高。决策应与应用程序的目标、资源限制以及底层检索系统的可靠性相一致。
