Команды разработчиков систем RAG (retrieval augmented generation) существенно сократили затраты на вывод данных, изменив архитектурный подход. В результате новых решений, основанных на детерминированном подходе, удалось снизить затраты до 6 раз. Это важно для предприятий, работающих в высокорегулируемых областях, где цена ошибки может достигать критических последствий.
Проблемы с традиционными моделями
Многие инженеры до сих пор полагаются на модели, основанные на использовании больших языковых моделей (LLM), отправляя все неоднозначные случаи в модель для анализа. Этот способ может быть успешным в рамках демонстраций, но не выдерживает проверки аудитов и нормативных требований, когда нужно объяснить решение, принятое несколько месяцев назад. Инженеры отмечают, что такие системы имеют три главные проблемы: сложность аудита, высокие расходы и нестабильность выводов.
Первой проблемой является низкая аудируемость — простое утверждение, что модель приняла решение на основе извлеченного контекста, не работает. Необходимо, чтобы возврат к принятым решениям был возможен без повторного запуска модели. Во-вторых, экономия на масштабах. Когда система обрабатывает десятки тысяч обращений каждый день, каждая вызванная моделью операция приводит к увеличению затрат и времени обработки. Наконец, существует проблема нестабильности моделей на простых случаях, что привлекает внимание к ошибкам, которые трудно заметить на первых порах.
Трёхступенчатый подход к обработке запросов
Команды предложили новый трёхступенчатый подход к обработке запросов, который декомпозирует обработку на три фазы. Первая фаза — это детерминированная обработка, в которой четкие совпадения и структурированные поля сравниваются без вызова модели. Эта фаза очищает основную массу запросов — более 50% в зависимости от качества данных. Все решения здесь полностью объясняемы.
Во второй фазе вводится слой извлечения, где собирается конкретная доказательная база для случаев, которые не были четко разрешены. Это может включать предыдущие решения, сопроводительные документы или исторические прецеденты, помогающие внести ясность в неоднозначные случаи. Третья фаза включает вызов LLM, который должен обрабатывать лишь остаточные случаи, что значительно сокращает затраты и повышает качество выводов.
Практические выводы для разработчиков
Для российских команд, работающих с системами RAG, такой подход может стать важным этапом в оптимизации процессов. Сложные правила и параметры большого объема данных можно эффективно обрабатывать поэтапно, что дает возможность снизить расходы до 80%, а также минимизировать влияние неправильных решений. Если ваша компания сталкивается с значительными затратами на обработку запросов, подумайте о переходе на трёхступенчатую архитектуру.
Следующий шаг для разработчиков — реализация прототипов системы с новым подходом и оценка результатов. Такие изменения могут привести к экономии расходов и значительно улучшить качество решений в долгосрочной перспективе.