За первые три месяца работы с RAG-системой можно спокойно потратить заметную часть бюджета впустую, и проблема при этом будет не в качестве поиска. Поиск может находить релевантные документы корректно. Деньги утекают раньше, на этапе, который почти никто не считает: на раздутом контексте, который модель получает на вход перед тем, как сформировать ответ.
Мы прошли через это сами и видим одну и ту же картину у клиентов. Команда честно пытается улучшить RAG и делает это самым очевидным способом: добавляет в запрос всё больше найденных фрагментов текста. После этого компания платит дважды. Первый раз в счетах за GPU, второй раз в потерянных конверсиях из-за медленного интерфейса. Ниже разбираем, почему так происходит и что с этим делать.
Три дорогие ошибки, которые повторяют почти все
Эти ошибки выглядят как забота о качестве, а на деле работают как утечка в бюджете. Каждая из них имеет понятную цену для бизнеса.
- Покупка точности через объём контекста. Больше найденного текста интуитивно кажется безопаснее: вдруг нужный факт где-то там есть. Но если посмотреть, как модель распределяет внимание, видно, что токены в основном работают внутри одного найденного фрагмента, а не между разными фрагментами. Значит, вы оплачиваете вычисления на связи между фрагментами, которые почти ничего не добавляют к ответу. Это прямые деньги, потраченные на то, что не повышает качество.
- Игнорирование TTFT. TTFT это время до первого токена, то есть момент, когда пользователь видит, что система начала отвечать. Пользователь не ждёт ваш финальный ответ терпеливо, он оценивает скорость по первой реакции. В исследовании REFRAG приводят ускорение TTFT до 16,53 раза при контексте в 16 384 токена с кэшем и до 32,99 раза на более длинном контексте. Для бизнеса это не приятная мелочь, а напрямую конверсия и удержание пользователя.
- Налог на KV-кэш в каждом запросе. Длинные запросы раздувают память KV-кэша и замедляют всю систему. В упомянутой работе отдельно разбирают, как меняются память KV-кэша и пропускная способность, когда контекст сжимают. На практике это означает, что одно и то же железо обслуживает либо мало тяжёлых запросов, либо много лёгких. Разница это ваши расходы на инфраструктуру при той же нагрузке.
Что REFRAG делает иначе
Подход из исследования REFRAG показывает, что проблему можно решать не грубой силой, а архитектурой пути данных. Логика простая по идее и важная по последствиям.
Сначала для найденного контекста заранее вычисляются эмбеддинги фрагментов с помощью лёгкого энкодера. Эти эмбеддинги подаются в декодер вместе с токенами вопроса. За счёт этого длина входной последовательности для декодера сокращается примерно во столько раз, какой выбран коэффициент сжатия. Дальше отдельная политика на основе обучения с подкреплением выборочно разворачивает в полный текст только те немногие фрагменты, которые реально важны для ответа, а не разворачивает всё подряд.
Результат в их условиях нагляден: при сжатии в 32 раза ускорение TTFT достигает 30,85 раза относительно LLaMA, при этом по логарифмической перплексии система держится на уровне CEPE. Для владельца продукта это переводится в простую вещь: та же осмысленность ответа при кратно меньшей задержке и меньшей нагрузке на железо. Скорость перестаёт быть статьёй расходов и становится частью маржи.
Что проверить в своей системе уже в этом квартале
Чтобы перестать терять деньги, не нужно сразу переписывать всю архитектуру. Достаточно навести порядок в пути контекста. Вот рабочий чек-лист, который мы применяем сами.
- Поставьте жёсткий лимит на токены контекста. Не абстрактное top k, а именно потолок по числу токенов. Это прямой контроль над счётом за вычисления.
- Считайте TTFT отдельно от пропускной способности. Это разные метрики, и именно TTFT убивает конверсию. Если вы его не измеряете, вы не видите, где теряете пользователей.
- Агрессивно убирайте дубли в выдаче поиска. Если фрагмент не добавляет новых фактов, он добавляет только задержку, за которую вы платите дважды: вычислениями и временем пользователя.
- Кэшируйте всё, что можно кэшировать. Эмбеддинги фрагментов по своей природе предназначены для повторного использования, и это снимает часть нагрузки с каждого запроса.
- Не начинайте с более крупной модели. Если нужен длинный контекст, сначала почините путь контекста, а не берите модель побольше. Большая модель обычно дороже и часто лишь маскирует исходную проблему.
Итог
В AI-продуктах скорость начинается до первого токена, и там же начинаются деньги. Раздутый контекст незаметно жжёт бюджет на GPU и теряет конверсию, пока команда думает, что просто заботится о качестве ответа. Главный вопрос для бизнеса звучит так: знаете ли вы, сколько токенов уходит в каждый запрос вашей RAG-системы, измеряете ли вы TTFT и во что обходится каждая секунда задержки в деньгах и потерянных пользователях. Чаще всего ответ на эти вопросы и есть та сумма, которую можно вернуть без смены модели.
Если вы хотите понять, где ваша RAG-система или инфраструктура теряет деньги, мы предлагаем бесплатный технический аудит инфраструктуры. Разберём путь контекста, замеры TTFT и нагрузку на железо по этим пунктам и дадим конкретные рекомендации. Оставьте заявку на странице https://myod.it/contact-us/
