Hugging Face выпустила relore — память репозитория для кодинг-агентов

Что выпустила Hugging Face

21 сентября 2026 года Hugging Face опубликовала статью инженера Тарека Зиаде о relore — сервисе, который даёт кодинг-агентам доступ к истории решений, стоящих за кодом. Аббревиатура раскрывается как REpository LORE: инструмент индексирует историю репозитория, фиксирует, кто что сказал, и связывает обсуждения с тем кодом, который существует сейчас.

Задача сформулирована на примере из жизни: информация была на GitHub, но лежала в разных issues, pull request'ах и комментариях, и ничего из этого не было видно из той issue, с которой начал агент. Утилита gh умеет достать любую отдельную issue, pull request или комментарий, однако сложность в другом — в том, чтобы понять, какие именно из них нужно достать: исправление может жить в другом pull request'е, обоснование — в комментарии ревью, а решение мейнтейнера — в треде, на который текущая issue никогда не ссылается.

Код relore открыт под лицензией Apache-2.0 и работает с любым репозиторием на GitHub, который вы готовы проиндексировать. Сам репозиторий huggingface/relore описывает проект как «память проекта на GitHub» и уточняет задачу так: «У каждой кодовой базы есть своя история. Спросите её, а потом сверьте ответ с кодом».

С чего началась работа

Отправной точкой стала обычная баг-репорта: 8 сентября контрибьютор открыл issue в Transformers о том, что GPTNeoXJapanese падает при любом rotary_pct, отличном от 1.0, потому что RoPE игнорирует partial_rotary_factor. В течение суток другой контрибьютор опубликовал верный диагноз и мейнтейнер ответил, что патчу будут очень рады; ещё через двое суток исправления открыли уже два разных человека.

Проблема проявилась, когда issue подхватил Serge — CI-агент Hugging Face. Он собирался написать ещё один патч, не зная, что работа уже идёт. Информация существовала, но pull request не был привязан к issue, и агент нашёл открытое исправление лишь как случайный побочный эффект поиска по символу. Именно этот режим отказа в Hugging Face сочли достаточно дорогим, чтобы дать ему отдельную команду.

Проекты не должны менять процесс работы ради такого инструмента: Hugging Face сознательно пошла с другого конца, чем предложения записывать контекст решений прямо в историю git. Знание уже есть — оно заперто в годах обсуждений на GitHub.

Как устроен relore

Сервис индексирует полную историю issues и pull request'ов репозитория и держит рядом рабочий клон; и то и другое отдаётся через один HTTP API. Дальше инструмент отвечает на три вопроса в том порядке, в котором их задаёт агент: «кто-то уже этим занимается?», «почему сделано именно так?» и «это ещё правда?».

Первый вопрос закрывает команда inflight: она одним шагом показывает всех, кто заявил права на исправление, с их статусом и автором. Второй — thread, why PATH:LINE и search: они возвращают результат на уровне комментариев и приписывают каждому авторство, а флаг --trust authoritative оставляет только то, что утвердил человек с правом записи. Символьный поиск вроде search --symbol GemmaRotaryEmbedding отвечает на вопрос, что говорили про функцию, — grep на такое не отвечает. Третий вопрос решают grep, symbol и copies: они выполняются против клона на HEAD на стороне сервера, без выгрузки на машину агента.

Разделение доверия встроено в саму модель данных: relore фиксирует, кто что сказал, обращается с решениями мейнтейнера иначе, чем с утверждениями контрибьютора, и по умолчанию исключает машинно-сгенерированный контент из набора доказательств. Уровни доверия — maintainer, contributor и bot — работают как фильтр, а не как вес при ранжировании. Индекс лексический и ранжированный, без эмбеддингов.

По пропускной способности заявлено простое свойство: каждый запрос — это запрос к Postgres, обращений к GitHub он не делает, поэтому десять агентов параллельно стоят столько же, сколько один. С GitHub контактирует только инжест, поддерживающий индекс свежим; запросы обслуживаются локально.

Первый прогон: issue 48630

Отчёт о первом полевом прогоне показывает работу по шагам. Команда relore inflight 48630 находит два треда, которые заявляют, что закрывают huggingface/transformers#48630: pull request #48652, открытый и одобренный, и pull request #48672, закрытый его автором. Вместо третьего патча агент видит, что работа уже в процессе.

Обоснование ищется иначе. Запрос search «standardize rope partial_rotary_factor refactor all models» с флагом --trust authoritative указал на #39847 — «[v5] Refactor RoPE for layer types»: тот же мейнтейнер, который перечислял регрессии в issue, и маркер ломающего изменения вместе позволили опознать рефакторинг, внёсший баг. Команда why PATH:LINE идёт от git blame к pull request'у и поднимает комментарии ревью вокруг нужной строки — в примере это src/.../modeling_gpt_neox_japanese.py:90. Часто именно там и лежит ответ на вопрос «почему эта строка вообще существует».

На момент отчёта relore на этом останавливался: агент клонировал репозиторий и доводил аудит вручную — через grep и разбор AST на Python. Этот разрыв и привёл к появлению команд для работы с кодом: defs и copies на базе tree-sitter индексируют символы Python, чтобы агент смотрел на структуру программы напрямую, а не восстанавливал её текстовым поиском. В одном из полевых тестов команда defs дала агенту более ясную картину файла, чем полное чтение, примерно за 5 % токенов.

Что это даёт и в чём ограничение

Цель сформулирована со стороны Hugging Face прямо: мейнтейнеры держат контекст десятилетней истории Transformers в голове, а у агента такого контекста нет, и relore должен дать ему ту же цепочку решений в момент работы с текущей кодовой базой. Инструмент уже используется внутри компании на нескольких проектах, включая Transformers, и Serge применяет его при ревью патчей и разборе issue.

В репозитории приведены и собственные измерения проекта: шесть агентов прогоняли relore «холодным» на одном и том же баге в transformers — по одному на релиз, опираясь только на --help и не помня предыдущих запусков; они завели 39 issue против самого инструмента, большинство из которых уже исправлено, и каждый следующий прогон проверял предыдущий снаружи.

Ограничение названо честно: платой за скорость является свежесть. Каждый тред хранит время последнего индексирующего визита, поэтому более поздние изменения на GitHub остаются неизвестными, а заявленные интервалы опроса коллектора не гарантируют актуальность для каждого треда. Для развёртывания нужны Postgres и токен GitHub с правами issues:read и pull_requests:read — на запись прав не требуется; в каталоге deploy/ лежит Helm-чарт.

Тем самым relore занимает нишу между git blame и поиском по трекерам: он не заменяет чтение кода, но снимает самый дорогой режим отказа агента — правку того, что уже правят, — и делает явными решения, которых в коде физически нет.