Подбор оптимального размера ЯЗЫКОВЫХ МОДЕЛЕЙ: маршрутизация, поиск и оценка вместо учета размера самих моделей
Изучите, как выбирать между небольшими и крупными языковыми моделями в зависимости от объема работы, оценивайте стоимость выполнения задачи и сначала используйте механизмы маршрутизации, RAG, кэширования и верификации.
Количество параметров позволяет легко формулировать заголовки, и возникает соблазн рассматривать его как показатель качества продукта: модель объемом 70 миллиардов должна превосходить модель объемом 7 миллиардов, поэтому самая большая модель, которую вы можете себе позволить, должна быть безопасным выбором. Однако в реальных условиях такой упрощенный подход быстро теряет силу. Более крупные модели обычно стоят дороже за один вызов, реагируют медленнее, увеличивают нагрузку на инфраструктуру и часто решают проблемы, которых у вашего приложения вообще не было. В этом руководстве объясняется, как выбирать модель в зависимости от нагрузки, а не от ее размера, как учитывать одновременно стоимость, задержку и вероятность сбоев, а также какие архитектурные решения (маршрутизация, получение данных, проверка, кэширование и простой код) обычно приносят больше пользы, чем просто обновление модели.
Почему принцип «чем больше, тем лучше» перестает работать в производстве
Эта интуиция понятна. Инженеры-программисты десятилетиями наблюдали, как оправдывают себя обновления аппаратного обеспечения: более быстрый процессор, больше оперативной памяти, более крупные диски и современнее графическое ядро почти всегда приводят к улучшениям. Когда языковые модели стали больше и более мощными, казалось естественным перенести эту модель мышления. Если одна модель рассуждает лучше другой, зачем кому-то специально выбирать более слабую?
Ответ появляется в тот момент, когда модель используется для решения реальной задачи. Вопрос, который вы ставите, меняется с «Какая модель умнее?» на «Какая модель даст лучший результат для этой конкретной задачи?» Это совершенно разные вопросы. Самая мощная модель может дать незначительно лучший ответ, но при этом работать гораздо медленнее. Её использование может стоить в несколько раз дороже. Для простой задачи классификации она может оказаться бесполезной, генерировать слишком длинные ответы, которые невозможно отобразить в интерфейсе, быстро исчерпать ресурсы контекста и усложнить процесс развертывания. Самое главное — она может решать проблему, которой у вас на самом деле нет.
Начните с объема работы, а не с количества параметров
Более надежный способ выбора модели — это описание самой задачи. Прежде чем сравнивать какие-либо модели, ответьте на следующие вопросы:
- Как выглядит входной данные?
- Какой результат ожидается?
Последний вопрос является настоящим инженерным вопросом, и остальная часть этого руководства посвящена его ответу: почему самая большая модель не всегда является лучшей, как выбирать между небольшими и крупными моделями, когда крупная модель действительно оправдывает свою стоимость, и как выглядит разумная проектная конфигурация для промышленного использования.
Один продукт поддержки, два совершенно разных нагрузочных профиля
Рассмотрим приложение для поддержки предприятий. Пользователь вводит фразу «Сбросить мой пароль». Что должен сделать слой ИИ в таком случае? Скорее всего, он просто распознает намерение пользователя и соотнесёт его с определённой меткой, чтобы приложение могло перейти к фиксированной, детерминистичной процедуре обработки.
PASSWORD_RESET
Для определения такой метки не требуется сложной модели для принятия решений. Ориентация на такую модель была бы сомнительным дизайнерским решением, поскольку достаточно простой модели или даже сопоставления ключевых слов и правил, чтобы справиться с задачей.
Теперь представим другое сообщение: с вчерашней версии системы у европейских клиентов начались периодические сбои при оплате, и пользователь хочет, чтобы система сравнила изменения в коде с логами сервиса оплаты, выявила вероятные причины сбоев, определила, связаны ли они с новым механизмом повторных попыток, и предложила план возврата к прежней версии. Для обработки такого запроса требуется гораздо больше ресурсов:
- восстановление соответствующих изменений в развертывании и логов
- большой объем контекста
- способность читать и понимать код
- анализ выводов логов
- мышление, включающее несколько шагов
- связывание событий в разных системах
- четкое техническое объяснение
- честное отношение к неопределенности
Здесь более мощная модель действительно может добавить ценность. Ошибка заключается не в использовании крупной модели, а в том, что эти два запроса рассматриваются как одинаковая нагрузка.
Рабочее определение ценности модели
Полезным способом для оценки выбора является простая гедонистическая формула:
Ценность модели = возможности × надежность × полезность ÷ стоимость
Это не формула, которую нужно вычислить. Это способ мышления. Модель, на 10% более мощная, но в пять раз дороже и в три раза медленнее, не обязательно является лучшим вариантом для производства. Точно так же крайне дешевая, но ненадежная для вашей задачи модель также является плохим выбором. Оптимизация должна стремиться не к максимальной интеллектуальности, а к наибольшей полезности интеллекта за единицу затрат, задержки и сложности.
Почему крупные модели привлекательны и где возникают ограничения
Предпочтение крупным моделям не является иррациональным, поскольку они обладают реальными преимуществами. Они часто лучше справляются со сложным рассуждением, демонстрируют более стабильную производительность при выполнении различных задач, более гибко интерпретируют нечеткие инструкции, эффективнее работают с сложными кодовыми базами, требуют меньше уточняющих указаний и способны демонстрировать гораздо более высокую эффективность при решении по-настоящему сложных задач.
Так почему бы не использовать самую мощную модель везде? Потому что производственные условия вносят ограничения, которые редко отражаются в цифрах с табло лидеров. Представьте эндпоинт, обрабатывающий 100 000 запросов в день. Если более мощная модель стоит значительно дороже за один вызов, этот разрыв перестаёт быть абстракцией — он проявляется в бюджете на инфраструктуру. Если к тому же эта модель работает медленнее, пользователи это замечают. Если она склонна к длинным ответам, растёт расход токенов на вывод. А если приложение выполняет тысячи небольших задач, отправка каждой из них в продвинутую модель для рассуждений — это просто пустая трата.
Выбор модели — это задача оптимизации, а не конкурс популярности.
Модель, находящаяся в верхней части таблицы с результатами тестирования, не обязательно является лучшей для создания приложения.
Количество параметров — это лишь одна из характеристик
При сравнении моделей обычно акцентируют внимание на их размере: 7 млрд, 13 млрд, 34 млрд, 70 млрд, сотни миллиардов. Один только размер мало что говорит о пригодности модели. Практическое сравнение включает рассмотрение нескольких параметров одновременно, например:
- способность к выполнению конкретной задачи
- задержка, включая время до получения первого токена и общее время генерации
- стоимость за запрос и за успешно выполненную задачу
- пропускная способность при ожидаемой нагрузке
- размер контекста, действительно необходимый для выполнения задачи
- надежность и стабильность при многократных запусках
- варианты развертывания, включая локальное или приватное хостинг
- возможность контроля
Возможность контроля заслуживает особого внимания, поскольку ее легко упустить из виду. Модель может быть очень мощной, но трудной в управлении. В корпоративных рабочих процессах предсказуемое поведение часто ценится выше, чем креативность.
Структурированный извлечение — это другая цель
Возьмем пример извлечения счетов-фактур. Для этой задачи требуется фиксированный формат, подобный приведенному ниже, а не обстоятельное описание документа.
{
"invoiceNumber": "...",
"invoiceDate": "...",
"vendor": "...",
"total": 0
}
Здесь важен надежный и корректно сформированный результат, который код на последующих этапах может парсить каждый раз. Это отдельная цель оптимизации, отличная от общей способности к рассуждению, и более мелкие или ограниченные по размеру модели часто хорошо ее достигают, особенно при сочетании с проверкой схемы.
Задержка: первая ловушка в производственной среде
В демо-версии шестисекундное ожидание кажется приемлемым. Результат впечатляет, вы делитесь им с командой, и все довольны. Но если в реальном приложении разместить такую же обработку за кнопкой, ситуация меняется: пользователь нажимает на кнопку, появляется индикатор загрузки, и проходит три, пять или восемь секунд. В такой момент никто уже не восхищается интеллектом модели — все задаются вопросом, почему приложение работает так медленно.
Задержка является характеристикой продукта, и в интерактивном программном обеспечении она имеет огромное значение.
Почему более крупные модели обычно реагируют медленнее
Точная зависимость определяется множеством факторов: архитектурой модели, оборудованием, стеком обслуживания, процедурой квантизации, группировкой запросов, количеством генерируемых токенов, размером вводного текста и дизайном модели. Однако в целом более ресурсоемкие модели требуют больше ресурсов на один токен и могут возвращать результаты медленнее. Это особенно важно в следующих случаях:
- интерфейсы чата
- ассистенты по программированию и автодополнение
- голосовые ассистенты
- инструменты поддержки клиентов
- интерактивные панели управления
- рабочие процессы с агентами, при которых задержки накапливаются на каждом этапе
Автодополнение четко ilлюстрирует этот момент. Предложение кода, на генерацию которого уходит пять секунд, уже не является автодополнением — это помеха. Модель меньшего размера, отвечающая практически мгновенно, часто гораздо полезнее, чем более мощная модель, заставляющая разработчика ждать.
Стриминг улучшает восприятие, а не вычисления
Стриминг — это стандартный способ сделать ожидание кажущимся более коротким. Без него пользователь ничего не видит, пока не будет готов полный ответ:
[wait...]
Hello! Here is the answer...
С использованием стриминга текст появляется на экране по мере прихода токенов:
Hello
Hello, here
Hello, here is
Hello, here is the
Hello, here is the answer...
Необходимо четко различать эти аспекты. Стриминг снижает воспринимаемую задержку, поскольку первые слова появляются быстро, но он не уменьшает объем вычислений или общее время до получения результата. Это улучшение пользовательского опыта, а не оптимизация производительности, и оно бесполезно для неконфликтных этапов, таких как классификатор внутри пайплайна.
Затраты: измеряйте их за каждую успешную задачу
Именно на этом этапе многие прототипы превращаются в дорогостоящие системы. Во время разработки затраты кажутся незначительными: один инженер отправляет несколько запросов, и никто не думает о счете. Затем начинается реальный трафик, и каждый запрос может содержать гораздо больше информации, чем просто сообщение пользователя:
- множество одновременных пользователей
- несколько запросов за сессию
- длинные запросы
- загружаемые документы
- результаты работы инструментов
- история разговора
- сгенерированные ответы
Объем токенов растет быстро, и выбор модели становится крайне важным фактором.
Более достоверной метрикой, чем стоимость одного запроса, является затраты на правильное выполнение задачи. Сравним две гипотетические модели (приведенные цифры носят иллюстративный характер, а не являются результатами тестирования):
- Модель А: 0,01 доллара за запрос, точность выполнения задачи — 90%, для каждого успешного результата требуется примерно 1,11 запроса, что соответствует примерно 0,011 доллара за успешно выполненную задачу.
- Модель Б: 0,05 доллара за запрос, точность выполнения задачи — 96%, для каждого успешного результата требуется примерно 1,04 запроса, что соответствует примерно 0,052 доллара за успешно выполненную задачу.
Ожидаемое количество попыток равно одному деленному на коэффициент успеха, поэтому стоимость за один успешный результат составляет цену запроса, деленную на точность. Если модель B стоит в пять раз дороже, но улучшает результаты лишь незначительно, бизнес может разумно предпочесть модель A. Ситуация меняется, когда неверный ответ имеет серьезные последствия — например, когда он приводит к возврату средств, проблемам с соответствием нормам или перебоям в работе. Именно поэтому стоимость всегда необходимо учитывать вместе с последствиями неудачи, а не отдельно.
Чрезмерно большие модели для недостаточно сложных задач
Типичный антипаттерн выглядит следующим образом: каждое поступающее сообщение классифицируется как жалоба, вопрос или запрос на возврат средств, и каждое из них направляется в самую сложную доступную модель. Причина — удобство: один API, один запрос, одна модель, и всё готово. Однако архитектура заключается не в том, чтобы сделать один компонент способным на всё; она направлена на соответствие каждой задаче подходящему компоненту. Для простой классификации существуют следующие варианты:
- детерминистические правила
- эмбеддинги
- небольшая языковая модель
- специализированный классификатор
- более крупная модель, предназначенная для случаев с низкой уверенностью
Последний вариант приводит к одному из самых эффективных паттернов в производственной среде.
Эскалация: дорогая модель в качестве обработчика исключений
В наивном подходе всё направляется сразу в большую модель:
Every request
↓
Large model
Дизайн с поэтапным усилением позволяет сначала использовать более простую модель и проверять уровень её уверенности:
Every request
↓
Small/cheap model
↓
Confidence check
↓
┌───────────────┐
│ │
High confidence Low confidence
│ │
Fast answer Large model
Ответы с высоким уровнем уверенности возвращаются немедленно; только неопределённые случаи передаются более мощной модели. Дорогостоящая модель перестаёт быть стандартным вариантом обработки и превращается в механизм обработки исключений. Этот подход зависит от наличия надёжного сигнала уверенности, такого как скоринг калиброванного классификатора, согласованность результатов различных методов или инструмент проверки, способный отклонять некорректные результаты; поэтому необходимо измерить частоту просачивания некачественных ответов через ветку «высокая уверенность», прежде чем полагаться на неё.
Распределение запросов между уровнями моделей
Как только вы начинаете мыслить в таком ключе, модели перестают казаться конкурентами и становятся похожи на специализированных работников. Маршрутизатор запросов может находиться перед несколькими уровнями обработки и выбирать подходящий для каждого запроса, с общим этапом проверки перед тем, как что-либо дойдет до пользователя:
User Request
|
v
Request Router
|
+-----------+-----------+
| | |
v v v
Simple Medium Complex
| | |
v v v
Small LLM Mid Model Large Model
| | |
+-----------+-----------+
|
v
Validation Layer
|
v
Response
Маршрутизатору нужно понимание уровня сложности. Самая простая версия — это небольшой набор категорий:
SIMPLE
MEDIUM
COMPLEX
Логика направления запросов может быть такой же простой, как переключатель на основе решения классификатора. Приведенный ниже пример написан на C#, но язык здесь второстепенен; та же структура отлично подходит и для сервиса на TypeScript.
public async Task<string> ProcessAsync(Request request)
{
var complexity = await classifier.ClassifyAsync(request);
return complexity switch
{
Complexity.Simple =>
await smallModel.GenerateAsync(request),
Complexity.Medium =>
await mediumModel.GenerateAsync(request),
Complexity.Complex =>
await largeModel.GenerateAsync(request),
_ => throw new InvalidOperationException()
};
}
Важно то, что говорит код о своей архитектуре: не каждый запрос требует максимальной сложности обработки. Если применять это решение последовательно, оно может кардинально изменить экономическую эффективность системы ИИ. Следует отметить, что сам классификатор добавляет вызов и некоторую задержку к каждому запросу, поэтому он должен быть значительно дешевле моделей, к которым направляет запросы; кроме того, неизвестная категория должна вызывать явную ошибку, как это делается в стандартном варианте обработки.
Когда проблема — в знаниях, а не в интеллекте
Ещё одним распространенным подходом является: «Модель не знает нашу внутреннюю документацию, поэтому давайте перейдем на более крупную модель». Размер модели не решает проблему отсутствия знаний. Когда информация является эксклюзивной, свежей или высокоспециализированной, проблема заключается в доступе к знаниям, а не в способности к рассуждениям. Именно эту проблему решает технология Retrieval-Augmented Generation (RAG). Основной алгоритм работы выглядит следующим образом:
User Question
|
v
Embedding / Retrieval
|
v
Relevant Documents
|
v
Prompt + Retrieved Context
|
v
Language Model
|
v
Answer
Если пользователь спрашивает о внутренней политике возвратов средств вашей компании для корпоративных клиентов, никакая универсальная модель, какой бы большой она ни была, не может дать ответа. Вам необходимо предоставить соответствующий текст в запросе. Чтобы узнать подробнее о том, как работает этот шаг поиска информации, ознакомьтесь с нашим руководством о том, как системы RAG получают свежие знания по запросу.
Исправьте канал передачи информации до использования модели
Это приводит к принципу, который стоит принять в качестве правила:
Улучшайте то, что вы подаете модели, прежде чем обновлять саму модель.
Команды часто пытаются исправить плохие ответы, переходя на более мощную модель, хотя настоящая причина кроется в чем-то другом:
- слабый поиск информации
- нерелевантные документы
- отсутствующие метаданные
- плохое разбиение на фрагменты
- недостаточный контекст
В таких случаях проблемой является не сама модель, а процесс обработки информации.
Качество контекста важнее его количества
Большие окна контекста кажутся впечатляющими, но больше контекста автоматически не означает лучшего результата. Предоставление модели 200 страниц документации, когда ответ содержится всего в двух абзацах, технически обеспечивает её информацией, но на практике усложняет задачу, поскольку теперь ей приходится искать нужный сигнал среди шума. Чрезмерно большой объём контекста склонен увеличивать:
- потребление токенов
- задержку
- затраты
- отвлекающие факторы
- вероятность наличия противоречивой информации
Лучшей целью является наименьший объём высококачественного контекста, который всё ещё позволяет модели правильно ответить. Именно поэтому зрелые системы RAG вкладывают значительные ресурсы в слой поиска с использованием таких техник, как:
- семантический и гибридный поиск
- фильтрация по метаданным
- переписывание запроса пользователя
- переусловливание кандидатских фрагментов
- обновление документов
- формирование структурированных блоков текста
Галлюцинации требуют проверки, а не более мощной модели
Неприятная правда: использование достаточно мощной модели не приводит к исчезновению галлюцинаций. Более сильные модели действительно чаще правильно определяют факты и лучше решают задачи в различных областях, однако языковая модель по-прежнему остается генератором текста, а не источником правды, к которому можно обращаться как к базе данных. Поэтому решение заключается в дизайне: необходимо добавить явную проверку на этапах обработки, например:
User Request
↓
Retrieve Evidence
↓
Generate Answer
↓
Validate Claims
↓
Return Response
Для критически важных рабочих процессов это можно усилить следующими мерами:
- цитаты, указывающие на источники информации
- структурированные результаты, проверяемые по схеме
- проверка на соответствие бизнес-правилам
Позвольте модели делать выводы, а программному обеспечению соблюдать правила
Это создает важную границу в архитектуре. Если от модели требуется рассчитать общую сумму счета-фактуры, нет причин доверять её арифметике, когда ваше приложение может выполнить эти вычисления с точностью. Вместо этого разделите обязанности:
Model:
Extract line items
Application:
Calculate subtotal
Application:
Calculate tax
Application:
Calculate total
Model:
Explain the result
Модель извлекает элементы счета и объясняет результат; приложение рассчитывает сумму по статьям, налог и общую сумму. Каждая часть выполняет то, в чем она надежна, и цифры, которые видит пользователь, по своей конструкции всегда корректны.
Где проявляют себя небольшие модели, и где у них недостатки
Маленькие языковые модели часто считаются «менее умными», что в техническом смысле верно во многих случаях. Однако инженерия не сводится к уму в отрыве от других факторов, и маленькие модели обеспечивают конкретные преимущества:
- низкая стоимость обработки запросов
- низкая задержка
- проще развертывание на локальных устройствах
- меньшие требования к инфраструктуре
- потенциально более высокая пропускная способность
- проще масштабирование
- хорошо подходят для узких задач
- полезны в сценариях работы на периферийных устройствах
- потенциально лучшая конфиденциальность при работе локально
Они особенно полезны для классификации, извлечения информации, составления кратких резюме, маршрутизации, автодополнения, простых преобразований и рабочих процессов, специфичных для определенной области. Если вы хотите углубиться в эту тенденцию, наш обзор небольших специализированных моделей, превосходящих гигантские LLM содержит более подробную информацию по этой теме.
Однако небольшой размер не означает автоматически лучшую производительность. Некоторые задачи выходят за рамки возможностей небольшой модели: сложное рассуждение на основе множества источников, анализ кода высокого уровня, решение сложных задач планирования или тонкая интерпретация данных. В таких случаях более мощная модель может оправдать свою стоимость. Оба крайних подхода являются плохим советом: «Всегда использовать самую большую модель» приводит к расточительству средств, а «всегда использовать самую маленькую» гарантирует низкое качество результата. Лучшее правило:
Используйте самую маленькую модель, которая соответствует порогу качества вашего приложения.
Задачи, требующие использования крупных моделей
Ничто из сказанного не является аргументом против крупных моделей. Они чрезвычайно полезны, и в некоторых задачах дополнительные возможности определенно оправданы.
Сложное многократное рассуждение
Когда функционал зависит от последовательных логических операций, более мощная модель может дать значительно лучшие результаты.
Работа с жестко заданным кодом
Крупные модели находят применение при решении сложных требований, работе с незнакомыми кодовыми базами, принятии архитектурных решений и в сложных ситуациях отладки.
Неоднозначный естественный язык
Некоторые запросы не подходят под заранее определенные категории. Более мощная модель обычно лучше справляется с пониманием нюансов и намерений.
Синтез из множества документов
Когда для ответа необходимо объединить информацию из множества источников, более важной становится способность модели.
Рабочие процессы с агентами
Агент обычно должен:
- понимать цель
- планировать действия
- выбирать инструменты
- анализировать результаты
- восстанавливаться после сбоев
- изменять план
- завершать задачу
Это гораздо сложнее, чем классификация, и использование более мощной модели вполне оправдано. В любом случае критерий остается одинаковым: применяйте крупные модели там, где их дополнительные возможности приносят измеримую пользу.
Операционные затраты умной архитектуры
Существует затрата, которую никогда не показывают тесты на производительность: сложность архитектуры. Самый простой вариант — одно приложение, одна крупная модель, один ответ:
Application
↓
Large Model
↓
Response
Теперь представьте, что нужно оптимизировать всё сразу:
Application
↓
Router
↓
Classifier
↓
Small Model
↓
Confidence Evaluator
↓
RAG
↓
Reranker
↓
Large Model
↓
Validator
↓
Fallback Model
↓
Human Review
Этот конвейер может действительно привести к созданию лучшей системы, но он также вводит гораздо больше компонентов, и каждый из них приносит:
- дополнительный мониторинг и логи
- новые способы сбоев
- более обширную поверхность тестирования
- дополнительную инфраструктуру для работы
- более сложные процессы развертывания
- больше знаний, необходимых команде для его эксплуатации
Поэтому оптимизация должна осуществляться целенаправленно. Создание архитектуры из семи моделей ради экономии нескольких центов за запрос редко является хорошей сделкой; добавляйте каждый слой только тогда, когда показатели покажут, что его обслуживание окупается.
Оценивайте на основе собственной нагрузки, а не по топ-листам
Публичные эталоны — это лишь отправная точка, а не основа для принятия решений. У вашего приложения есть свой собственный эталон, и только он имеет значение. Для помощника с проверкой кода на основе ИИ набор для оценки может включать:
- уязвимости типа SQL-инъекции
- ситуации соревнования
- ошибки нулевого обращения
- недостатки в авторизации
- некорректная обработка исключений
- проблемы с производительностью
- нарушения архитектуры
Для сотрудника службы поддержки клиентов необходимо оценивать различные аспекты:
- соблюдение правил
- точность информации
- тон общения
- точность передачи запросов на уровень выше
- поведение при отказе
- достоверность структурированного вывода
Набор данных для оценки должен максимально соответствовать реальному трафику.
Создание инструмента для сравнения
Основная процедура проста: собираются запросы, похожие на реальные, с ожидаемыми результатами, каждая из моделей тестируется на них, после чего производится сравнение.
Production-like prompts
↓
Expected outcomes
↓
Run Model A
↓
Run Model B
↓
Compare
↓
Measure
Полезные показатели для записи после каждого запуска:
- корректность и завершение задачи
Благодаря этому выбор модели превращается в инженерное решение, а не в угадывание, и вы можете снова запустить ту же самую систему каждый раз, когда поставщик выпускает новую версию модели.
Четырехэтапный процесс выбора модели
Для новой функции искусственного интеллекта хорошо подходит простой и воспроизводимый процесс.
Шаг 1: Точно определите задачу
Не начинайте с вопроса «Какую модель нам использовать?» Начните с вопроса «Что именно должна сделать модель?» и запишите ответ в конкретных формулировках:
Input:
Customer email
Output:
Intent + urgency + recommended workflow
Такое описание, с четким входным и выходным данными, гораздо полезнее, чем расплывчатая цель.
Шаг 2: Определите, что означает «достаточно хорошо»
Установите четкие критерии приемки перед тестированием чего-либо. Например:
Intent accuracy >= target threshold
Structured output must always validate
Response should normally arrive within target latency
Конкретные пороговые значения зависят от приложения; важно лишь то, что они существуют до сравнения моделей, чтобы впоследствии невозможно было оправдать полученные результаты.
Шаг 3: Сначала попробуйте самую простую работоспособную модель
Этот шаг команды чаще всего пропускают. Начните с простого варианта, измерьте результаты и остановитесь, если все в порядке. Переходите к более сложным решениям только в случае неудачи:
Small Model
↓
Evaluation
↓
Pass? ── Yes → Ship
|
No
↓
Larger Model
↓
Evaluation
↓
Pass? ── Yes → Ship
|
No
↓
Stronger architecture/model
По сути, вы поднимаетесь по лестнице возможностей, шаг за шагом, причем каждый следующий уровень можно достичь только после неудачной оценки предыдущего.
Шаг 4: Оптимизируйте окружающую систему
Прежде чем переходить на следующий уровень, проверьте остальную часть системы:
- Возвращает ли процесс поиска правильный материал?
- Ясен ли запрос?
- Действительно ли каждый элемент контекста имеет отношение к задаче?
- Проверяется ли результат перед его использованием?
Улучшения в этой области иногда полностью устраняют необходимость в более мощной модели.
Другие факторы, стоит учитывать перед обновлением
Инструкции как контракты
Инженерия инструкций — это не магия, но плохо сформулированная задача может заставить даже способную модель плохо себя вести. Сравните расплывчатую инструкцию:
Analyze this customer message.
с той, которая определяет ожидаемый результат и правила обработки неопределенностей:
Analyze the customer message.
Return JSON with:
- intent
- urgency
- sentiment
- recommended_action
Do not invent information that isn't present.
If the intent is unclear, return "unknown".
Вторая версия предоставляет модели чёткие требования: именованные поля, прямой запрет на выдумку фактов и определённое значение по умолчанию. Добавление нескольких примеров часто способствует дальнейшему улучшению результатов. Однако существует предел: никакие формулировки в промптах не могут придать модели способности, которых у неё фундаментально нет, и когда такая способность отсутствует, корректировки промптов дают всё меньший эффект. Рассматривайте промпты как один из слоёв процесса оптимизации, а не как полное решение.
Тонкая настройка, RAG или проверка?
Ещё одной распространённой реакцией на слабые результаты является фраза «давайте проведём тонкую настройку». Иногда это действительно правильно, но сначала необходимо диагностировать проблему:
- Если у модели отсутствуют актуальные или специфичные для компании знания, такие как сегодняшняя политика, обычно более эффективным решением будет извлечение информации, чем тонкая настройка, поскольку знания меняются, а переобучение занимает много времени.
Подбор правильного решения для конкретной проблемы позволяет сэкономить время и деньги.
Кэширование: скучная, но эффективная оптимизация
Кэширование — это не самый привлекательный метод, но он очень эффективен. Если пользователи постоянно задают вопрос «Какова ваша политика возврата?», нет смысла вызывать модель каждый раз. Когда ответ стабилен, его следует сохранить в кэше. В приведенном ниже примере на C# сначала проверяется кэш, модель вызывается только в случае его отсутствия, а результат сохраняется на 30 минут:
public async Task<string> GetAnswerAsync(string question)
{
var key = CreateCacheKey(question);
var cached = await cache.GetStringAsync(key);
if (cached is not null)
return cached;
var answer = await model.GenerateAsync(question);
await cache.SetStringAsync(
key,
answer,
TimeSpan.FromMinutes(30));
return answer;
}
Настоящая семантическая кэширование гораздо сложнее точного совпадения строк, поскольку два вопроса с разным формулированием могут требовать одного и того же ответа, и необходима политика аннулирования ответов при изменении основных фактов. Архитектурная идея остается прежней:
Самым быстрым запросом к ИИ является тот, который вы вообще не отправляете.
Тот же принцип применим к удалению дубликатов, предварительным вычислениям, детерминированным ответам, повторному использованию результатов поиска, кэшированию префиксов запросов там, где это поддерживается поставщиком, а также к простому повторному использованию ответов. Прежде чем платить за дополнительные вычисления, устраните те, которые вам не нужны.
Рассматривайте токены как бюджет ресурсов
Как только систему ИИ рассматривают как распределенную, токены становятся еще одним ресурсом, который необходимо управлять. Традиционные сервисы обрабатывают процессор, память, сеть и хранилище. Приложения ИИ добавляют входные токены, выходные токены, размер контекста и время инференса, из-за чего проектирование запросов становится вопросом производительности.
Подумайте о возможности отправки полной истории разговора с каждым запросом. Запросы постоянно увеличиваются, к ним добавляются загружаемые документы, результаты работы инструментов, системные инструкции и предыдущие действия агента. Простой вопрос может оказаться с очень большим объемом данных. Более оптимальный дизайн выбирает только релевантную историю перед загрузкой и формирует компактный контекст:
Conversation
↓
Relevant history selection
↓
Retrieval
↓
Compact context
↓
Model
вместо того чтобы передавать все, что система когда-либо видела:
Everything we've ever seen
↓
Model
Больший объем контекста никогда не бывает бесплатным: за него приходится платить деньгами, задержками и, часто, качеством ответа.
Агенты умножают влияние каждого из этих решений
Системы с агентами делают выбор модели ещё более важным. Одна запрос от пользователя может привести к множеству этапов:
User Request
↓
Planning
↓
Tool Selection
↓
Search
↓
Database Query
↓
Code Execution
↓
Analysis
↓
Final Response
Если каждый этап выполняется с использованием самой дорогой модели, затраты могут резко возрасти. Однако на разных этапах редко требуется одинаковая функциональность. Смешанное распределение может выглядеть так:
Intent classification → Small model
Simple tool selection → Small model
Complex planning → Large model
Data extraction → Small model
Final explanation → Medium model
Это гетерогенная архитектура ИИ, к которой движутся многие производственные системы: вместо одной гигантской модели, выполняющей всё, используются несколько моделей, инструментов, детерминистических компонентов, систем поиска и верификаторов, работающих вместе. Наша статья «Почему затраты на агентные системы ИИ растут» более подробно рассматривает аспекты затрат в этой сфере.
Рассматривайте модели как членов команды
Полезная аналогия: представьте трех инженеров. Один — очень опытный, дорогой и перегруженный работой. Другой — опытный и эффективный. Третий — младший, но очень быстрый при выполнении повторяющихся задач. Вы не стали бы поручать каждую задачу самому опытному инженеру. Вы бы распределяли работу в зависимости от сложности:
Simple repetitive task
→ Engineer C
Normal feature
→ Engineer B
Complex architecture problem
→ Engineer A
Модели можно рассматривать аналогичным образом. Модель меньшего размера не является «плохой»; она просто может быть подходящей для более узкой сферы применения. Основной навык заключается в разбиении работы на части. Вместо поиска одной модели, которая справляется со всем, разделите рабочий процесс так, чтобы каждый компонент выполнял ту часть работы, в которой он лучше всего справляется. Такой подход позволяет гораздо лучше масштабироваться.
Сводный вариант: архитектура для справки
Сочетая эти идеи, корпоративный ИИ-ассистент может быть структурирован следующим образом:
User
|
v
API / Gateway
|
v
Request Router
|
+-------------+-------------+
| |
v v
Simple Request Complex Request
| |
v v
Small Model Planner
|
+------------+------------+
| | |
v v v
Search Database Tools
| | |
+------------+-------------+
|
v
Context
|
v
Strong Model
|
v
Validator
|
+------+------+
| |
Valid Invalid
| |
v v
Response Retry/Fallback
Обратите внимание на то, чего не происходит: от самой мощной модели не требуется выполнять всё. Простые запросы направляются к менее мощной модели. Сложные запросы проходят через планировщик, который собирает информацию из поиска, баз данных и инструментов, после чего только мощная модель работает с отобранным контекстом. Валидатор проверяет результат, а недействительные данные приводят к повторной попытке или использованию альтернативного решения. Дизайн основан на:
- маршрутизаторе, выбирающем путь обработки
- средствах для получения информации и использования инструментов
- детерминистичных системах для точной обработки
- моделях, специализированных под конкретные задачи
- механизмах валидации, а также стратегиях повторных попыток и использования альтернатив
Здесь модель является лишь частью системы, а не всей системой в целом.
Десять часто повторяющихся ошибок
- Сначала выбирается модель, а проблема описывается позже. Порядок должен быть обратным: сначала определите объем работы, прежде чем что-либо ещё.
Чек-лист для принятия решения о выборе модели
Когда возникает вопрос о выборе модели, последовательно рассмотрите следующие вопросы:
- Может ли детерминистичный код решить эту задачу? Если да, напишите код. Не используйте ИИ только потому, что он доступен.
- Является ли задача простой и повторяющейся? Попробуйте использовать небольшую модель.
Этот чек-лист гораздо полезнее, чем простой вопрос о том, какая модель является самой мощной среди доступных.
Вопрос, который стоит задать старшим инженерам по ИИ
Хороший вопрос для собеседования на позицию по проектированию архитектуры ИИ: «Почему бы просто не выбирать для всего самую мощную модель на рынке?»
Слабый ответ ограничивается фразой «меньшие модели дешевле». Это верно, но неполно. Сильный ответ учитывает способность модели к выполнению конкретной задачи, надежность, время отклика и пропускную способность, стоимость, объем необходимого контекста, механизмы перехода между моделями, процесс извлечения информации, функции, которые должен выполнять код, методы оценки, последствия сбоев и операционную нагрузку.
Естественный следующий вопрос: «Как вы докажете, что выбранная модель достаточно хороша?» Ответ должен касаться методов оценки, а не мнений, постов в социальных сетях, скриншотов табелей лидеров или презентаций поставщиков. Решающими факторами являются ваша рабочая нагрузка, ваши данные и ваши показатели.
Пошаговая оптимизация существующего приложения
Когда функция ИИ слишком медленная или слишком дорогая, сдерживайте желание немедленно заменить модель. Вместо этого проводите систематическое исследование:
- Измерение. Собирайте данные о количестве запросов, числе токенов ввода и вывода, задержке, коэффициенте ошибок, проценте успешного выполнения задач и стоимости использования модели.
- Выявление дорогостоящих нагрузок. Определите, какие типы запросов потребляют наибольше ресурсов.
- Устранение ненужных вызовов. Используйте кэширование, детерминистическую логику, удаление дубликатов и предварительные вычисления.
- Сокращение объема контекста. Удаляйте нерелевантную историю и документы.
- Улучшение процесса поиска. Возвращайте более качественные результаты вместо большего количества данных.
- Использование более простой модели. Проверьте, остается ли качество приемлемым.
- Внедрение механизма маршрутизации. Отправляйте только сложные случаи на более мощные модели.
- Проверка важных аспектов. При необходимости применяйте схемы, правила, инструменты и проверку человеком.
Если это кажется вам знакомым, так и должно быть. По сути, это та же самая дисциплина, которая используется для оптимизации обычного программного обеспечения.
Лучшая архитектура ИИ обычно является гибридной
Образ приложения ИИ как фронтенда, вызывающего API большой языковой модели и возвращающего ответ, постепенно уходит на второй план:
Frontend
↓
LLM API
↓
Response
Реальные приложения всё чаще напоминают шлюз, координирующий правила, механизмы поиска, модели, инструменты и процедуры проверки:
Application
|
v
AI Gateway
|
+-----------+-----------+
| | |
v v v
Rules Retrieval Models
| | |
+-----------+-----------+
|
v
Tools
|
v
Validation
|
v
Application
Такой подход сочетает в себе классическую инженерию программного обеспечения с машинным обучением, языковыми моделями и технологиями поиска, а также базами данных, API, мерами безопасности, возможностями отслеживания и бизнес-логикой, написанной в виде кода. Это хорошие новости для инженеров по программному обеспечению: инженерия ИИ не заменяет инженерию программного обеспечения, а добавляет к ней мощный новый компонент.
Полезен и смежный сдвиг в подходе: перестаньте спрашивать, какая модель самая умная, и начните спрашивать, какая система самая умная. Отличная модель в плохо спроектированной системе может давать ужасные результаты, тогда как модель среднего уровня в хорошо спроектированной архитектуре может обеспечить работу отличного продукта. Хорошие системы компенсируют слабости модели с помощью механизмов поиска и инструментов, маршрутизации и кэширования, структурированного вывода и верификации, кода для выполнения точных задач, а также постоянной оценки. В этом смысле способности ИИ являются свойством архитектуры, а не только модели.
Начните с малого и постепенно расширяйтесь, опираясь на доказательства
Разумная стандартная стратегия для любой новой функции ИИ описана в следующем алгоритме:
Start
|
v
Define the workload
|
v
Can code solve the problem?
/ \
Yes No
| |
Use code v
Try small model
|
v
Evaluate
|
+----------+----------+
| |
Pass Fail
| |
Ship v
Improve architecture
|
v
Evaluate
|
v
Try stronger model
|
v
Evaluate
Это предотвращает очень распространенную ошибку: трату денег на проблему, которую можно было решить с помощью лучшей инженерной практики.
Иногда подходящей модели просто не существует
Урок заключается не в том, что маленькие модели лучше; это было бы так же неверно, как и противоположное утверждение. Подходящей является та модель, которая соответствует требованиям задачи, сбалансировав при этом производительность и надежность с задержками, затратами и сложностью. Иногда это бывает маленькая модель, иногда — большая, иногда — их комбинация, а иногда это вообще не модель ИИ. Если тип запроса можно обработать с помощью простого решения, подобного этому, нет причин использовать LLM:
if (request.Type == "PasswordReset")
{
return StartPasswordResetWorkflow();
}
Это не анти-ИИ; это хорошая инженерная практика. Вы ведь не купите сервер с неограниченным количеством ядер процессора для сервиса, который нуждается всего в двух ядрах, или не выделите терабайт памяти для процесса, который использует 4 ГБ. Тот же принцип применим и к моделям: производительность, которая вам не нужна, — это затраты, которые вам тоже не нужны.
Основные выводы
- Замените вопрос «Какая самая мощная модель мы можем себе позволить?» на вопрос «Какая самая простая архитектура способна надежно решить эту проблему?» Этот вопрос естественным образом приводит к рассмотрению механизмов маршрутизации, поиска информации, кэширования, детерминированного кода, оценки качества, задержек и обработки сбоев.
- Оценивайте модели по стоимости выполнения одной успешной задачи с учетом последствий неверного ответа, а не по цене за вызов или количеству параметров.
- Рассматривайте отсутствие необходимых знаний как проблему поиска информации, а арифметические операции или правила — как проблему программного обеспечения; ни то, ни другое не решается с помощью более мощной модели.
- Используйте самую простую модель, которая проходит тестирование на данных, максимально приближенных к реальным условиям работы, и переходите на более сложные решения только при наличии убедительных доказательств.
- Делайте архитектуру настолько простой, насколько это оправдано экономией ресурсов, и продолжайте ее тестировать после запуска, поскольку модели, запросы и пользователи постоянно меняются.
Сначала разработайте решение с учётом проблемы, а затем выберите модель, соответствующую этому дизайну. Иногда такая модель будет огромной, иногда — удивительно маленькой, а иногда самым разумным решением будет вообще не использовать модель.
Связанные статьи
- Объяснение технологии Retrieval-Augmented Generation: как устранять пробелы в знаниях ИИ — Узнайте, почему ИИ создаёт ложную информацию и устаревает, а затем пошагово ознакомьтесь с тем, как метод RAG извлекает данные, разбивает их на части, встраивает информацию и дополняет запросы для решения этих проблем.
- RAG против Agentic RAG против Graph RAG: как выбрать подходящую архитектуру поиска — Узнайте, почему примитивный метод RAG терпит неудачу при обработке вопросов с несколькими этапами и структурированных данных, а также как механизмы Agentic RAG и поиск на основе графов устраняют соответствующие недостатки.