Сокращение затрат на вывод RAG в 6 раз начинается с решения того, что никогда не доходит до LLM.

Винит Виджай

Большинство команд, разрабатывающих системы дополненной генерации информации (RAG) для классификации в сложных ситуациях, делают одну и ту же архитектурную ставку: направлять каждый неоднозначный случай непосредственно в языковую модель и полагаться на полученный контекст для его разрешения. Это хорошо работает в демонстрационном режиме. Но система рушится, как только ей приходится выдерживать проверку, проверку регулирующих органов или проверку со стороны сотрудника по вопросам соответствия, который спрашивает, почему то или иное решение было принято полгода назад.

Последний год я посвятил разработке систем классификации на основе алгоритмов RAG в условиях регулируемых предприятий, где цена неправильного ответа — не плохой ответ чат-бота. Решение должно выдерживать проверку в течение длительного времени после того, как модель его сгенерировала. Эта среда требует иного подхода к проектированию, чем тот, который обычно используется в большинстве материалов по разработке ИИ.

Вот что меняется, когда вы не можете позволить себе быть вероятностно настроенными во всем, и как каскадная архитектура решает эту проблему.

Скрытые издержки полностью LLM-конвейера

Привлекательность маршрутизации всего процесса через большую языковую модель (LLM) очевидна: меньше движущихся частей, более быстрая итерация, модель обрабатывает непредвиденные крайние случаи. Проблема проявляется позже, в трех местах.

Во-первых, возможность аудита. Ответ «Модель приняла решение на основе полученного контекста» неприемлем. Вам нужен путь принятия решения, который человек сможет восстановить, не перезапуская процесс вывода и не надеясь на тот же результат.

Во-вторых, стоимость в масштабе. Если ваша система обрабатывает десятки тысяч случаев в день, и каждый из них вызывает LLM-запрос с несколькими извлеченными документами в контексте, то ваши затраты на вывод и задержка будут масштабироваться с объемом таким образом, как это не происходит с логикой, основанной на правилах.

В-третьих, и это наименее обсуждаемый аспект, дрейф модели в простых случаях. Языковые модели отлично справляются с тонкими суждениями. Однако они непоследовательны, причем таким образом, который трудно обнаружить, в случаях, когда должен быть детерминированный ответ. Четкое структурированное соответствие известным критериям никогда не должно зависеть от настроения языковой модели.

Каскадный подход

Решение: перестать рассматривать LLM как передовую линию и начать рассматривать его как путь эскалации. На практике это означает трехэтапный конвейер.

Первый этап является детерминированным. Точные совпадения, сравнение структурированных полей и любые ситуации, для которых существует четкое правило, разрешаются здесь без вызова модели. На этом этапе должна быть обработана большая часть объема данных, часто более половины, в зависимости от качества данных, и каждое решение полностью объяснимо, поскольку это поиск, а не вывод.

На втором этапе поиск информации действительно приносит свои плоды. Для случаев, которые проходят первый этап — и я имею в виду случаи, которые не были однозначно разрешены, — вы создаете слой поиска, который извлекает конкретные доказательства, относящиеся к неоднозначности: предыдущие решения рецензентов по аналогичным случаям, контекстные документы, объясняющие кажущийся конфликт, или исторические прецеденты, проясняющие частный случай. Этап поиска информации здесь важнее, чем этап генерации. Если вы извлечете неверный контекст, даже самая лучшая в мире языковая модель выдаст уверенный, хорошо аргументированный, но неверный ответ.

Третий этап — это вызов LLM, и он должен обрабатывать только те остатки, которые не удалось разрешить на первом и втором этапах. Именно этот этап часто пропускают при разработке первой версии, и он является самым важным фактором как с точки зрения стоимости, так и качества. В одной из систем, над которой я работал, отправка на LLM только действительно неоднозначных 10-15% случаев снизила затраты на вывод примерно в 6 раз по сравнению с базовой системой, использующей только LLM, одновременно улучшив согласованность в детерминированном большинстве случаев до практически идеального результата.

Разработка запроса на информацию об асимметричном риске

Когда дело доходит до стадии LLM (Large of Lab Life), большинство команд по умолчанию используют нейтральный запрос: «Оцените, следует ли одобрить это дело или отметить его как требующее внимания». Такая формулировка не подходит для классификации с высокими ставками, поскольку стоимость двух типов ошибок несимметрична. Пропуск чего-то, что действительно требовало внимания, может привести к реальному ущербу в дальнейшем. Неправильная отметка чего-то, что было в порядке, обходится рецензенту временем и приводит к задержке. Эти два результата редко бывают одинаково плохими, однако нейтральный запрос просит модель рассматривать их так, как если бы они были одинаковыми.

Асимметричный подход к оценке риска явно указывает модели на этот компромисс, вместо того чтобы позволять ей гадать о вашей толерантности к риску. Конкретно это означает указание модели рассматривать неопределенность как причину для эскалации, а не для устранения проблемы, предоставление калиброванных примеров обоих типов ошибок с подробным описанием их последствий, а также запрос оценки достоверности наряду с классификацией, а не бинарного ответа. Оценка достоверности становится вашей второй точкой каскадирования: все, что ниже определенного порога, передается на проверку человеку, а не автоматически разрешается, независимо от того, что говорит классификация модели.

На первый взгляд это может показаться незначительной технической деталью. На практике же это разница между системой, которая снижает нагрузку на рецензентов, и системой, которая незаметно увеличивает риски, создавая видимость работоспособности.

Правильная оценка подобной системы

Стандартные метрики оценки RAG не были разработаны с учетом этого сценария использования, и их применение без адаптации создаст ложное чувство уверенности. Несколько важных корректировок.

Качество поиска необходимо измерять отдельно от точности окончательной классификации. Система может иметь отличные показатели ранжирования результатов поиска, но при этом принимать неверные окончательные решения, если на этапе генерации данных неправильно взвешиваются имеющиеся доказательства. Отслеживайте их независимо друг от друга.

Для оценки необходимо преднамеренно увеличить количество случаев, достигших третьего этапа, поскольку именно на этом этапе проверяется эффективность работы системы. Если ваш набор данных для оценки будет отражать распределение данных в рабочей среде, в нем будут преобладать детерминированные случаи, которые ваша система уже хорошо обрабатывает, и вы не сможете увидеть, какие именно ошибки имеют наибольшее значение.

Метод LLM в качестве оценки судьёй подходит для этой области, но только если подсказка судьи содержит ту же асимметричную формулировку риска, что и ваша производственная подсказка. Судья, который одинаково рассматривает оба типа ошибок, будет систематически отдавать предпочтение неправильному компромиссу при настройке вашей системы.

Наконец, создайте обратную связь от подтвержденных результатов к вашему корпусу поиска. Когда эксперт-человек отменяет решение модели, этот случай и его правильное решение должны стать доступным контекстом для поиска аналогичных случаев в будущем. Без этого обработка неоднозначных случаев вашей системой никогда не улучшится, она просто будет продолжать совершать ошибки одной и той же категории с той же частотой.

Более широкий урок

Стремление использовать наиболее подходящую модель для каждого решения вполне понятно, но в областях, где неправильные ответы имеют реальные последствия, более ценная инженерная работа заключается в определении того, что вообще не должно касаться модели. Каскадная архитектура — это не обходной путь для ограничений LLM. Это то, как выглядит зрелая система RAG, когда вам действительно приходится защищать её решения перед тем, чья работа заключается в поиске недостатков в вашей логике.

Если вы разрабатываете системы искусственного интеллекта для любой регулируемой или высокорискованной области, то прежде чем писать хоть один запрос, стоит задать себе вопрос не «Как заставить модель хорошо справиться с этим?», а «Какие части этого решения вообще не должны были входить в задачи модели?».

Винит Виджай — ведущий инженер в области искусственного интеллекта и машинного обучения.

Добро пожаловать в сообщество VentureBeat!

Наша программа гостевых публикаций — это площадка, где технические эксперты делятся своими знаниями и предоставляют нейтральные, непредвзятые аналитические материалы по искусственному интеллекту, инфраструктуре данных, кибербезопасности и другим передовым технологиям, формирующим будущее предприятий.

Узнайте больше о нашей программе гостевых публикаций — и ознакомьтесь с нашими рекомендациями, если вы заинтересованы в написании собственной статьи!

Источник: venturebeat.com