Команда разработчиков опубликовала результаты внешнего бенчмарка метода причинного recall для ИИ-ассистента, ориентированного на поддержку разработки. В отличие от предыдущего теста на собственном корпусе задач, новый эксперимент был проведён на репозитории YDB — открытой распределённой СУБД Яндекса, содержащей 10 285 issue и 37 067 pull request. Целью замерялась способность ассистента находить по симптомам бага ранее закрытый PR с исправлением, используя два подхода: семантический поиск по сходству слов и обход графа причинных связей, построенного на явных ссылках Closes/Fixes/Resolves. На собственном корпусе recall семантики составлял 38%, а причинный метод давал 87%; на внешнем корпусе эти показатели составили 32,1% и 94,5% соответственно, причём доверительные интервалы на 95% уровне не пересекались.

Методика эксперимента была полностью детерминированной и не привлекала языковые модели. Эталонные пары «issue — закрывающий PR» извлекались регулярным выражением из тела каждого PR, затем для каждого issue-запроса строилась выдача ближайших PR по эмбеддингам (семантический поиск) и отдельно — обход по рёбрам графа, соединяющим issue с их фиксами. Оба варианта ранжировались в порядке свежести PR; метрикой служила доля запросов, где целевой PR попал в топ выдачи. При первом прогоне выяснилось, что 53% свежих PR созданы ботами (ydbot и github-actions) — они не ссылаются на issue и искажают выборку. Поэтому был сделан второй прогон с фильтрацией механических авторов, оставив только «живые» PR людей и ИИ-агентов (например, copilot-swe-agent). На 47 пригодных парах первого прогона и 293 парах второго результаты были согласованы, но второй дал более узкие доверительные интервалы.

Важным результатом стала воспроизводимость закономерности на совершенно другом наборе данных: другой язык (английский), другой домен (инфраструктурная СУБД), другая культура тикетов. Базовый семантический recall на YDB (32,1%) оказался близок к показателю собственного корпуса (38%), причём разница укладывается в большую плотность дистракторов на YDB. Причинный recall на внешнем корпусе даже превзошёл собственный (94,5% против 87%), что объясняется более чистыми связями один-к-одному между issue и закрывающим PR в YDB, тогда как в собственном корпусе встречались «братские» issue одного модуля, на которых обход мог давать ложные срабатывания. Таким образом, не конкретное число, а именно закономерность — треть при семантике и более 90% при добавлении причинных рёбер — устойчиво переносится между проектами.

Параллельно с основным замером разработчики провели детекцию следов использования ИИ в PR YDB тем же детерминированным способом — регулярными выражениями по автору и телу. Прямой след (явная метка авторства агента) был найден в 143 PR, созданных аккаунтами copilot-swe-agent, cursor, devin, codex, aider (преимущественно Copilot), и в 22 PR с трейлером соавторства или строкой «Generated with Claude Code». Косвенные следы (без метки) не учитывались, поэтому общая доля PR с признаками ИИ в свежем окне из 4000 PR составила всего 0,2%, что разработчики сами называют заведомо нижней границей. В том же корпусе обнаружено 173 PR со словом revert в заголовке, 2 067 issue с flaky и 356 с regression, а также 778 групп практически одинаковых по смыслу заголовков — это иллюстрирует, насколько часто одна и та же проблема переоткрывается даже в дисциплинированном инфраструктурном проекте.

Значение этой работы для российского рынка AI-ассистентов двойное. Во-первых, она даёт объективную метрику, с помощью которой можно оценивать качество памяти инструментов, а не только их способность генерировать ответ. Во-вторых, подтверждается, что для эффективной помощи в отладке критически важны не просто эмбеддинги, а явное моделирование причинно-следственных связей внутри проекта. Руководитель «Поиска и ИИ» Яндекса недавно отмечал в интервью, что минимизация галлюцинаций — критически важная инженерная работа, и что LLM без поиска не может гарантировать фактологическую точность. Данный бенчмарк показывает, какую долю потенциальных галлюцинаций можно устранить, просто научив ассистента доставать уже известное решение из собственной базы знаний. Аналогичные подходы развивают и конкуренты, но публичных сравнений на одинаковых корпусах пока опубликовано мало.

Ограничения метода авторы честно обозначают: он не измеряет latency, не проверяет работу на графах с миллионами узлов, держится на явных ссылках Closes #N (там, где их не пишут, бонус теряется), и не оценивает качество самих рёбер — ложная связь уводит обход в сторону, что скорее занижает recall. Тем не менее, полученные результаты дают практические ориентиры для разработчиков AI-ассистентов: вкладывать усилия в построение и поддержание графа причинности выгоднее, чем пытаться улучшить эмбеддинги. Дальнейшие шаги могут включать тестирование на более крупных репозиториях с разной степенью формализованности связей, а также интеграцию подобной логики непосредственно в продукты для повышения качества ответов ассистента без увеличения размера модели.

Растущая активность ИИ-агентов в репозиториях — ещё один сигнал, что проблема памяти будет только острее. Если автоматизированные патчи создаются быстрее, чем раньше, то количество кода, в котором могут быть скрыты уже встречавшиеся ошибки, растёт. Инструменты, способные распознать, что проблема уже решена, и предложить готовый PR вместо генерации нового, могут существенно сократить время разработчика и снизить вероятность повторного внесения тех же багов. Результаты бенчмарка на YDB показывают, что такой подход уже сегодня способен находить повторяющиеся решения в 9 из 10 случаев — и это при полностью автоматической, не требующей LLM разметке. Дальнейшие исследования должны уточнить, насколько эта доля сохранится при замене человеческих PR на агентные и при усложнении структуры связанных задач.