SRX: верификация исторических данных в AI вместо простого поиска
Система SRX демонстрирует новый подход к работе с историей изменений кода: вместо передачи всей базы знаний модели, система восстанавливает конкретные версии файлов, проверяет их целостность через SHA-256 и только после этого отправляет данные на интерпретацию LLM. Тесты на репозитории Vite подтвердили точность восстановления, однако гипотеза о SRX как о новом алгоритме сжатия была опровергнута.
# SRX: верификация исторических данных в AI вместо простого поиска
Когда искусственному интеллекту необходимо не просто ответить на вопрос, основываясь на «вспомнивших» фактах, но и предоставить точную ссылку на то, где и в какой момент этот факт был зафиксирован, традиционные методы поиска могут давать сбои. В своей последней работе разработчик Игорь Рыбаков рассматривает архитектуру SRX (Semantic Reconstructive eXchange), которая решает проблему происхождения данных (provenance) через детерминированное восстановление состояния системы.
От поиска к реконструкции состояния
В классических системах RAG (Retrieval-Augmented Generation) или при использовании семантического поиска модель часто получает сырой набор данных, соответствующих запросу. Если параметр конфигурации, например database.pool_size, менялся множество раз — от 4 до 16, затем до 32, и в итоге снова возвращался на 16 — поисковый движок может вернуть все эти записи. Однако нейросети сложно самостоятельно определить, какая версия является актуальной для текущего контекста, особенно если последующие решения отменили предыдущие изменения.
В SRX приоритеты смещены. Система не доверяет модели процессу выбора верности данных. Вместо этого внедрена жесткая цепочка обработки: 1. Storage: доступ к исходным данным. 2. Retrieval: нахождение нужной записи. 3. State reconstruction: восстановление конкретного состояния файла или проекта. 4. Verification: проверка целостности восстановленных данных против исходного Git-источника с помощью SHA-256. 5. Answer LLM: только после подтверждения верности данных они передаются языковой модели.
Как отмечают разработчики, «LLM никогда не создает метрики; она лишь интерпретирует измеренные доказательства». Это позволяет избежать галлюцинаций, когда модель пытается «угадать», какой фрагмент истории является релевантным, и снижает вероятность ошибок при генерации кода на основе устаревших версий.
Успех тестов на реальных данных
Чтобы убедиться в работоспособности подхода, проект был проверен не на синтетических данных, а на реальной истории коммитов популярного фреймворка Vite. Система импортировала 50 первых коммитов (first-parent commits), восстановила исторические состояния файлов и провела сверку с оригинальным репозиторием.
Результаты теста были однозначными: * Импорт реальных коммитов: 50 шт. * Перезагрузка устойчивости: PASS. * Проверка доказательств: 4/4 прошло. * Верификация SRX: PASS. * Побайтовое сравнение (bit-perfect) с командой git show: PASS. * Совпадение хешей источника (SHA match): PASS.
Это подтверждает ключевое допущение: исторический ответ можно связать с реально восстановленным файлом, который прошел криптографическую проверку. Если бы система попыталась сделать это через генеративное предсказание содержимого файла, вероятность ошибки была бы высока. Здесь же каждый байт проверяется детерминированно.
Почему SRX не стал новым компрессором
Изначально разработчик рассматривал SRX не только как инструмент верификации, но и как потенциально эффективный метод компрессии для хранения истории изменений. Гипотеза заключалась в том, что описывать изменения между версиями семантически может быть компактнее, чем хранить полные дампы.
Однако эксперимент показал обратное. На части реальных данных структурные операторы не дали никакого выигрыша в объеме, а существующие решения, такие как алгоритм сжатия zstd с использованием эталонных файлов, оказались существенно эффективнее. Таким образом, направление «SRX как новый компрессор» считается закрытым.
Перспективы: селективное восстановление
Сейчас фокус смещается на другой вопрос: как восстановить лишь минимально необходимый фрагмент истории, чтобы получить корректный ответ и при этом доказать источник этого ответа? Это направление, известное как selective reconstruction, выглядит наиболее перспективным.
Следующие шаги предполагают измерение того, сколько именно истории действительно требуется для формирования качественного ответа, и насколько точно система умеет выбирать нужное состояние. Также планируется исследование того, можно ли машинным способом описывать семантический смысл изменений между версиями, а не просто фиксировать их байтовую разницу. Однако окончательные выводы по этому пункту потребуют дополнительных экспериментов.
Проект продолжает развиваться в открытом доступе на GitHub, предоставляя сообществу возможность изучать методы обеспечения надежности и проверяемости данных в эпоху автономных агентов.