Особенности внедрения RAG-систем: уроки из реального мира
Внедрение систем Retrieval-Augmented Generation (RAG) в реальных проектах часто сталкивается с неожиданными трудностями, где стандартные «лучшие практики» могут приводить к ухудшению метрик. Один из последних кейсов показывает, что ключевая работа в RAG-системах заключается не в написании кода, который может быть создан за один день, а в тщательной подготовке данных, создании эффективного оценочного комплекса (eval-harness) и проведении честных замеров. Только таким образом можно определить, какие индустриальные стандарты применимы к конкретному проекту, а какие оказываются вредными.
В ходе разработки антискам-бота, который обрабатывает «грязные» данные из Telegram-чатов с опечатками, сленгом и смешением языков, было обнаружено, что такие элементы, как BM25 и реранкеры, в некоторых конфигурациях снижали общую эффективность системы. Это подчеркивает важность индивидуального подхода и эмпирической проверки каждого компонента на собственных данных, вместо слепого следования общепринятым решениям.
Создание антискам-бота на основе грязных данных
Проект антискам-бота, помимо RAG-модуля, включает в себя классификатор для определения необходимости помощи и типизатор проблем. Эта система является примером ML-инженерии, работающей с неразмеченными и сложными данными. Она демонстрирует, как можно создать рабочий классификатор, когда метрики могут быть обманчивы, а входные данные представляют собой хаотичный поток информации.
Оптимизация русского эмбеддера для повышения производительности
Для локальной RAG-системы, работающей на AMD Strix Halo, где вычислительные ресурсы ограничены одним iGPU, критически важной стала оптимизация эмбеддера. Целью было не достижение максимальной точности, а создание максимально легкого русского ретривера, способного быстрее завершать первую стадию поиска на том же GPU, который также используется для реранкера, периодической переиндексации и генеративной LLM.
В результате была разработана оптимизированная модель STRIZH, которая показала значительные преимущества по сравнению с bge-m3 в условиях фоновой индексации и одновременной обработки пользовательских запросов. Например, STRIZH обеспечил 14,0 транзакций в минуту против 6,0 у bge-m3 и индексировал 46 батчей в секунду против 4,9. При фиксированных 200 онлайн-запросах в секунду генерация проседала всего на 2% со STRIZH по сравнению с 7% у bge-m3. Оптимизация включала обучение 12-слойного RuModernBERT-small, выбор четырех слоев и доучивание на смешанных парах с hard negatives.
Действительно, кейс с RAG для антискам-бота на «грязных» данных из Telegram показателен. Оптимизация эмбеддера STRIZH для AMD Strix Halo, демонстрирующая 14,0 транзакций в минуту против 6,0 у bge-m3, подчеркивает критичность адаптации под аппаратные ограничения и специфику языка. Это наглядно демонстрирует, что в RAG-системах, особенно на периферийных устройствах, кастомная разработка и бенчмаркинг компонентов, таких как ретриверы, часто превосходят универсальные решения.