Хороший пример того, как классические методы обработки текста закрывают 80% потребностей без GPU и тяжёлых моделей. Разница в скорости - 0.1 мс против 186 мс у BERT - для продакшена с высоким RPS это решающий аргумент. Алгоритм Луна для карт, контрольные суммы для ИНН/СНИЛС - всё это отработанные десятилетиями методы, и правильно, что вы не стали заменять их нейросетью ради хайпа. Единственное, что добавил бы - модуль PII на регулярках можно дополнить нечётким матчингом для случаев, когда пользователь намеренно пишет номер через пробелы или подменяет цифры буквами. Это частый паттерн обхода фильтров, который как раз и роняет Recall в бенчмарке. Проект оформлен очень зрело - CI, SDK на двух языках, Grafana-дашборд, документация на MkDocs.
Статья отлично показывает проблему, о которой мало говорят: качество «золотой» разметки в бенчмарках далеко не золотое. Вы по сути наткнулись на систематическую ошибку аннотатора - метки кластеризуются по статьям, то есть один разметчик в одной сессии наставил неправильных флагов, и это протащилось в бенчмарк. Для меня самое ценное здесь - методологический урок: когда все 6 моделей единогласно спорят с эталоном, стоит проверить эталон, а не придумывать «слепую зону». Подход «не верить никому без грепа» - вообще хороший принцип для любой работы с данными. Было бы классно, если бы авторы RAGTruth учли эти findings и обновили датасет.
Интересно, что в основе детектора лежат артефакты архитектуры, а не "стиля" ИИ-музыки. Транспонированные свёртки оставляют характерные паттерны в частотном спектре - примерно так же, как первые GAN-картинки имели заметный "шахматный" паттерн. И это одновременно и сильная, и слабая сторона метода.
Самый недооцененный технический момент в статье - это правка eps в AdamW. То, что eps начинает доминировать в знаменателе оптимизатора на поздних этапах обучения больших моделей - реальная проблема, о которой говорят редко. Дефолтное значение 1e-8 подбиралось в эпоху, когда типичные градиенты были на порядки больше. При обучении модели с сотнями миллиардов параметров на триллионах токенов вторые моменты настолько маленькие, что eps буквально ломает обновление весов - оптимизатор начинает работать как SGD с моментом.
Тестирую на pet-project - AI-ассистент для кодревью. Архитектура такая: context слой содержит состояние репозитория (структура файлов, последние изменения, связи между модулями), skills - набор инструкций под конкретные задачи (ревью, рефакторинг, тесты). Context грузится один раз на сессию, skills подключаются по запросу.
По результатам: на повторных запусках экономия 35-40% токенов по сравнению с flat-промптом где всё в одну кучу. Поведение стало стабильнее - меньше галлюцинаций про несуществующие файлы когда context явный, а не выводится агентом самостоятельно.
Самое интересное открытие - инвалидация context при изменениях в репо работает лучше чем пересылать всё заново каждый раз. Но правильно выбрать гранулярность инвалидации оказалось нетривиальной задачей.
Интересный подход к разделению harness и агента. Сам тестирую похожую архитектуру - выделение context/skills в отдельный слой действительно экономит токены при частых запусках.
Хороший пример того, как классические методы обработки текста закрывают 80% потребностей без GPU и тяжёлых моделей. Разница в скорости - 0.1 мс против 186 мс у BERT - для продакшена с высоким RPS это решающий аргумент. Алгоритм Луна для карт, контрольные суммы для ИНН/СНИЛС - всё это отработанные десятилетиями методы, и правильно, что вы не стали заменять их нейросетью ради хайпа. Единственное, что добавил бы - модуль PII на регулярках можно дополнить нечётким матчингом для случаев, когда пользователь намеренно пишет номер через пробелы или подменяет цифры буквами. Это частый паттерн обхода фильтров, который как раз и роняет Recall в бенчмарке. Проект оформлен очень зрело - CI, SDK на двух языках, Grafana-дашборд, документация на MkDocs.
Статья отлично показывает проблему, о которой мало говорят: качество «золотой» разметки в бенчмарках далеко не золотое. Вы по сути наткнулись на систематическую ошибку аннотатора - метки кластеризуются по статьям, то есть один разметчик в одной сессии наставил неправильных флагов, и это протащилось в бенчмарк. Для меня самое ценное здесь - методологический урок: когда все 6 моделей единогласно спорят с эталоном, стоит проверить эталон, а не придумывать «слепую зону». Подход «не верить никому без грепа» - вообще хороший принцип для любой работы с данными. Было бы классно, если бы авторы RAGTruth учли эти findings и обновили датасет.
Интересно, что в основе детектора лежат артефакты архитектуры, а не "стиля" ИИ-музыки. Транспонированные свёртки оставляют характерные паттерны в частотном спектре - примерно так же, как первые GAN-картинки имели заметный "шахматный" паттерн. И это одновременно и сильная, и слабая сторона метода.
Самый недооцененный технический момент в статье - это правка eps в AdamW. То, что eps начинает доминировать в знаменателе оптимизатора на поздних этапах обучения больших моделей - реальная проблема, о которой говорят редко. Дефолтное значение 1e-8 подбиралось в эпоху, когда типичные градиенты были на порядки больше. При обучении модели с сотнями миллиардов параметров на триллионах токенов вторые моменты настолько маленькие, что eps буквально ломает обновление весов - оптимизатор начинает работать как SGD с моментом.
Тестирую на pet-project - AI-ассистент для кодревью. Архитектура такая: context слой содержит состояние репозитория (структура файлов, последние изменения, связи между модулями), skills - набор инструкций под конкретные задачи (ревью, рефакторинг, тесты). Context грузится один раз на сессию, skills подключаются по запросу.
По результатам: на повторных запусках экономия 35-40% токенов по сравнению с flat-промптом где всё в одну кучу. Поведение стало стабильнее - меньше галлюцинаций про несуществующие файлы когда context явный, а не выводится агентом самостоятельно.
Самое интересное открытие - инвалидация context при изменениях в репо работает лучше чем пересылать всё заново каждый раз. Но правильно выбрать гранулярность инвалидации оказалось нетривиальной задачей.
Интересный подход к разделению harness и агента. Сам тестирую похожую архитектуру - выделение context/skills в отдельный слой действительно экономит токены при частых запусках.