Снижение затрат на вывод RAG в 6 раз начинается с решения о том, что никогда не должно попадать в LLM
Большинство команд, создающих системы дополненной генерацией с поиском (RAG) для классификации в условиях высоких ставок, делают одну и ту же архитектурную ставку: направляют каждый неоднозначный случай прямо в языковую модель и доверяют извлеченному контексту разобраться во всем. Это отлично работает в демоверсии. Но это рассыпается в прах в тот момент, когда системе приходится проходить аудит, отвечать перед регулятором или инспектором по комплаенсу, который интересуется, почему шесть месяцев назад было принято то или иное конкретное решение.
Последний год я провел за созданием систем классификации на базе RAG в регулируемых корпоративных средах, где цена неверного ответа — это вовсе не плохой ответ чат-бота. Решение должно выдерживать пристальную проверку спустя долгое время после того, как модель его выдала. Такая среда диктует философию проектирования, отличную от той, что предполагается в большинстве материалов по разработке ИИ.
Вот что меняется, когда вы не можете позволить себе быть вероятностным во всем, и как каскадная архитектура решает эту проблему.
Невидимая стоимость пайплайна, построенного целиком на LLM
Привлекательность маршрутизации всего через большую языковую модель (LLM) очевидна: меньше движущихся частей, быстрее итерации, модель сама справляется с непредвиденными крайними случаями (edge cases). Проблема проявляется позже, в трех аспектах.
Во-первых, аудируемость. Ответ «модель приняла решение на основе извлеченного контекста» не является приемлемым. Вам нужен путь принятия решения, который человек может восстановить без повторного запуска инференса в надежде получить тот же результат.
Во-вторых, стоимость при масштабировании. Если ваша система обрабатывает десятки тысяч кейсов в день и каждый из них обращается к LLM с несколькими извлеченными документами в контексте, ваши расходы на инференс и задержка (latency) будут расти вместе с объемом так, как это не свойственно логике на основе правил.
В-третьих, и об этом говорят меньше всего, — дрифт модели на простых кейсах. LLM отлично справляются с тонкими оценками. Но они непоследовательны — причем трудным для обнаружения образом — в тех случаях, когда должен быть детерминированный ответ. Четкое структурное совпадение с известными критериями никогда не должно зависеть от настроения языковой модели.
Каскадный подход
Решение: перестать рассматривать LLM как передовую линию и начать воспринимать ее как путь эскалации. На практике это означает трехэтапный пайплайн.
Первый этап — детерминированный. Точные совпадения, сравнения структурированных полей и все, что имеет четкое правило, разрешается здесь вообще без вызова модели. Этот этап должен закрывать подавляющую часть объема — зачастую больше половины в зависимости от качества ваших данных, — и каждое решение полностью объяснимо, поскольку представляет собой поиск по справочнику, а не инференс.
Второй этап — это то место, где поиск (retrieval) отрабатывает свою ценность. Для случаев, которые пережили первый этап (и я имею в виду пережили в том смысле, что они не были четко разрешены), вы создаете поисковый слой, который извлекает конкретные доказательства, имеющие отношение к данной неопределенности: предыдущие решения рецензентов по аналогичным делам, контекстуальные документы, объясняющие явный конфликт, или исторический прецедент, проясняющий пограничный случай. Шаг поиска здесь важнее шага генерации. Если вы извлечете неправильный контекст, даже самая лучшая языковая модель в мире выдаст уверенный, логически обоснованный, но неверный ответ.
Третий этап — это вызов LLM, и она должна видеть только тот «остаток», который не смогли разрешить первый и второй этапы. Это та часть, которую люди пропускают при проектировании своей первой версии, и это самый мощный рычаг управления как стоимостью, так и качеством. В одной системе, над которой я работал, перенаправление в LLM только действительно амбивалентных 10–15% кейсов снизило затраты на инференс примерно в 6 раз по сравнению с базовым вариантом, использующим только LLM, одновременно доведя согласованность на детерминированном большинстве практически до идеала.
Проектирование промпта для асимметричного риска
Когда дело доходит до этапа LLM, большинство команд по умолчанию используют нейтральный промпт: «Оцените, следует ли одобрить этот кейс или пометить его флагом». Такая постановка вопроса неверна для классификации с высокими ставками, поскольку цена двух типов ошибок несимметрична. Пропуск чего-то, что действительно требовало внимания, может привести к реальному вреду в дальнейшем. Неправильная пометка нормального кейса стоит времени рецензента и задержки. Эти два исхода редко бывают одинаково плохими, однако нейтральный промпт требует от модели относиться к ним так, будто они равнозначны.
Промпт с учетом асимметричного риска делает этот компромисс явным для модели, а не заставляет ее угадывать вашу склонность к риску. Конкретно это означает: инструктировать модель рассматривать неопределенность как повод для эскалации, а не для оправдания; предоставлять откалиброванные примеры обоих типов ошибок с описанием их последствий; и запрашивать показатель уверенности (confidence score) наряду с самой классификацией вместо бинарного ответа. Показатель уверенности становится вашей второй каскадной точкой: все, что ниже определенного порога, отправляется рецензеню-человеку вместо автоматического разрешения, независимо от того, что говорит классификация модели.
Это звучит как незначительная деталь инженерии промптов. На практике это грань между системой, которая снижает нагрузку на рецензентов, и системой, которая незаметно увеличивает риски, создавая видимость исправной работы.
Правильная оценка такой системы
Стандартные метрики оценки RAG создавались не под этот сценарий использования, и их слепое применение создаст у вас ложное чувство уверенности. Вот несколько важных корректировок.
Качество поиска необходимо измерять отдельно от точности финальной классификации. Система может иметь отличные показатели ранжирования поиска и все равно принимать неверные окончательные решения, если шаг генерации придаст доказательствам неправильный вес. Отслеживайте их независимо друг от друга.
Ваш набор для оценки (eval set) должен содержать намеренное оверсемплирование (избыточную выборку) кейсов, доходящих до третьего этапа, поскольку именно там действительно проверяется рассудительность вашей системы. Если ваш оценочный набор повторяет ваше производственное распределение, в нем будут преобладать детерминированные кейсы, с которыми ваш каскад и так отлично справляется, и вы останетесь слепы к тем самым сбоям, которые имеют наибольшее значение.
Оценка с помощью LLM-судьи подходит для этой предметной области, но только в том случае, если промпт судьи кодирует ту же структуру асимметричного риска, что и ваш рабочий промпт. Судья, который относится к обоим типам ошибок одинаково, будет систематически отдавать предпочтение неверному компромиссу при настройке вашей системы.
Наконец, выстройте цикл обратной связи (feedback loop) от подтвержденных результатов обратно в ваш поисковый корпус. Когда рецензент-человек отменяет решение модели, этот кейс и его правильное разрешение должны стать доступным для поиска контекстом для будущих аналогичных случаев. Без этого обработка неоднозначных ситуаций вашей системой никогда не улучшится — она просто продолжит совершать ошибки того же типа с той же частотой.
Более широкий урок
Инстинкт использовать самую мощную модель для каждого решения понятен, но в областях, где неверные ответы имеют реальные последствия, более ценная инженерная работа заключается в том, чтобы решить, что вообще никогда не должно попадать в модель. Каскадная архитектура — это не обходной путь для ограничения LLM. Так выглядит зрелая система RAG, когда вам действительно приходится защищать ее решения перед тем, чья работа заключается в поиске изъянов в вашей логике.
Если вы создаете ИИ-системы для любой регулируемой или критически важной сферы, вопрос, который стоит задать перед написанием хотя бы одного промпта, звучит вовсе не так: «Как заставить модель справиться с этим хорошо?». Он звучит так: «Какие части этого решения изначально не должны были быть работой модели?»
Винит Виджай (Vineet Vijay) — ведущий инженер по искусственному интеллекту и машинному обучению.
Добро пожаловать в сообщество VentureBeat!
Наша программа гостевых публикаций — это площадка, где технические эксперты делятся инсайтами и представляют нейтральные, неангажированные глубокие обзоры об ИИ, инфраструктуре данных, кибербезопасности и других передовых технологиях, формирующих будущее корпоративного сектора.
Читайте далее в рамках нашей программы гостевых публикаций — и ознакомьтесь с нашими рекомендациями, если вы хотите сами написать статью!
