Introduction:
当 bug 发生时，我们会拿到很多信息：上下文、报错信息等等，文章把这些东西定义为 facts，自然产生一个问题：“哪种 facts 应该被组织进 prompt？” 这篇文章就这一点做出了一些探讨。
之前的工作研究了很多独立的信息，比如上下文、GitHub issue（这也行？）、栈跟踪信息；这篇文章将它们归纳成七种 just facts。
第一项实验旨在确认已考虑的 facts 是否具备正面作用（缺乏这个 fact，不能在这个 fact 指向的 bug 上做出正确修复）。文章同时发现，过多的 facts 可能造成负面作用。这么看来，一个精简的完备的有效的 facts 集合会很有用。然而本文做的实验指出，基本不存在一个这么完美的 facts 集合，需要特定情况特定分析。本文提出了一个模型，模型可以针对 errors 给出 facts 选择方案。
-
对七种 just facts 的系统化研究
-
facts 数量与 LLM 做 APR 的性能的非线性关系的确切证据
-
为什么会产生 facts 选择的问题？
-
一个 bug 指向性的事实选择模型
我太喜欢这个文章了
标签：Repair,Selection,Based,just,LLM,facts,bug From： https://www.cnblogs.com/sysss-blogs/p/18214457