Проблема: переплата за флагманы
Стандартный подход к извлечению данных из документов (RAG) часто подразумевает отправку всех полей в дорогие API уровня GPT-4. Это создает непропорционально высокие затраты, так как большинство полей являются простыми справочными данными, которые легко обрабатываются более слабыми моделями. Слепая замена флагмана на маленькую локальную модель приводит к ошибкам и браку данных. Решение — LLM-каскад: использование дешевой модели как первого эшелона с эскалацией к сильной модели только при сбое валидации.
Результаты бенчмарка: размер не равен качеству
Авторы провели сравнительный тест 20 локальных моделей против одного хостингового флагмана на задаче извлечения структурированных полей (JSON, температура 0). Ключевые выводы:
- Больше параметров ≠ лучше: Модели 4B (qwen3:4b) и 7B (mistral:7b) показали лучшие результаты среди локальных, опередив 12B и 14B модели (gemma3:12b, phi4:14b).
- Порог надежности: Модели менее 2B (например, qwen2.5:1.5b с точностью 12%) и 0.5B (возвращают пустой JSON) непригодны для старта без серьезной доработки.
- Задержка (Latency): Флагман отвечал за ~1.4 секунды, что быстрее большинства локальных моделей 7B–14B (2.6–7.6 сек на одном GPU). Экономия достигается за счет цены токенов, а не скорости.
| Категория модели | Примеры | Результат / Характеристика |
|---|---|---|
| Локальные лидеры | qwen3:4b, mistral:7b | Лучшая точность среди локальных; старт каскада |
| Локальные середняки | gemma3:12b, phi4:14b | Уступают меньшим моделям; размер не гарантирует качество |
| Локальные аутсайдеры | qwen2.5:1.5b, llama3.2:1b | Точность <12-15%; высокий риск сбоев |
| Хостинговый флагман | — | 1.4 сек/поле; 100% точность при наличии глоссария |
Главный рычаг: Глоссарий важнее размера модели
Самый значимый скачок в точности произошел не за счет замены модели, а за счет добавления в промпт бизнес-глоссария (синонимы полей, единицы измерения, контекст). Это позволило:
- Повысить точность локальной модели с 38% до 62%.
- Довести точность флагмана до 100%.
Без глоссария даже флагман показывал лишь 62% точности. Это решает проблему терминологической разнородности документов (например, «deductible» vs «retention»).
Архитектура каскада: Criteria → Loop → Split
Рабочий процесс строится на трех принципах:
- Критерии выбора: Старт всегда с локальной модели для конфиденциальных данных. Выбор модели зависит от надежности вывода (typed-output), а не только от размера.
- Цикл валидации: Каждый ответ локальной модели проверяется. Если валидация провалена, запрос эскалируется на флагман. Это делает экономию безопасной.
- Разделение задачи: Если локальная модель не справляется со сложной трансформацией, задача разбивается, а не просто отправляется «вверх» по иерархии.
Этот подход позволяет использовать дешевые локальные модели как основной двигатель, оставляя дорогие API для сложных случаев, что критически важно для масштабируемых Enterprise RAG-систем.
Источник: Towards Data Science ↗