Программирование · Инженерия
Специализированные модели вроде JEV позволяют выбирать ИИ, инструменты и сценарии обработки запросов без привлечения мощных LLM для каждого решения. Разбираем применение в бизнесе, промышленности и автоматизации, а также опыт PardAi, где JEV уже используется для маршрутизации моделей и инструментов.
Современные системы искусственного интеллекта становятся всё сложнее. В одном приложении могут одновременно работать несколько языковых моделей, поисковая система, база знаний, инструменты обработки документов и десятки специализированных функций.
Но возникает вопрос: кто решает, какой именно инструмент нужен пользователю?
До недавнего времени эту задачу часто поручали самой большой языковой модели. Она получала запрос, анализировала его, выбирала инструмент и только затем приступала к выполнению. Такой подход работает, но требует дополнительных вычислений, времени и денег.
Сегодня развивается другой подход: использовать для подобных решений отдельные специализированные модели. Они не пишут статьи, не программируют и не ведут длинные диалоги. Их задача гораздо уже — быстро определить, какой из доступных вариантов подходит лучше.
Один из представителей этого направления — JEV от TypeSafe AI. Подобную технологию мы уже используем в собственной платформе PardAi, где JEV выполняет функцию маршрутизатора моделей и инструментов.
Представим корпоративного ИИ-помощника, который умеет:
Пользователь пишет: «Покажи, какие клиенты не оплатили счета за последний месяц».
Для выполнения такого запроса не обязательно сразу запускать мощную языковую модель. Сначала достаточно определить, что пользователь хочет получить финансовую информацию, что данные находятся в учётной системе и что требуется инструмент для выборки задолженности.
После этого программная система проверяет права доступа, обращается к нужному источнику и передаёт полученные данные языковой модели, если требуется составить понятное объяснение.
Именно первая часть процесса — классификация намерения и выбор дальнейшего маршрута — представляет собой подходящую задачу для специализированной модели принятия решений.
Здесь важно разделять функции. Модель-маршрутизатор выбирает подходящий вариант. Приложение проверяет разрешения и выполняет инструменты. Генеративная модель при необходимости формирует содержательный ответ.
JEV — специализированная модель принятия структурированных решений, разработанная TypeSafe AI в рамках направления System One.
Обычная большая языковая модель получает запрос и генерирует последовательность текстовых токенов. JEV ориентирован на другой тип результата: выбор из заранее определённых вариантов, оценку или структурированное решение.
Например, системе требуется определить тип обращения:
Вместо развёрнутого ответа JEV оценивает предложенные варианты и возвращает результат в заданной структуре. На основании полученных оценок приложение может выбрать подходящий маршрут.
Подобный механизм подходит для повторяющихся задач, где количество допустимых решений ограничено.
При этом JEV не заменяет большую языковую модель. Он решает другую задачу. Если нужно написать договор, провести исследование или создать программный код, работу выполняет соответствующая генеративная модель или специализированный инструмент.
Преимущество такого разделения — возможность не расходовать ресурсы дорогой LLM на каждое промежуточное решение.
В нашей платформе PardAi мы уже используем JEV как маршрутизатор, который помогает выбирать подходящие модели искусственного интеллекта и инструменты в зависимости от характера пользовательского запроса.
Причина такого решения вполне практическая.
Универсальному ИИ-агенту не нужна одна и та же модель для всех задач. Простую классификацию обращения и сложный инженерный анализ неразумно обрабатывать одинаковым способом.
Для одних запросов достаточно быстрой и экономичной модели. Для других требуется мощная модель с расширенными возможностями анализа. Третьи задачи вообще лучше передавать специализированным инструментам, а не решать генерацией текста.
Шаг 1. Пользователь отправляет запрос.
Например: «Найди в документации сведения об ограничениях оборудования и подготовь сравнительную таблицу».
Шаг 2. Маршрутизатор определяет направление обработки.
Он оценивает, какие из доступных инструментов или моделей наиболее соответствуют запросу. В этом примере может потребоваться поиск по базе знаний и модель, способная структурировать полученные данные.
Шаг 3. Система применяет правила маршрутизации.
Результат модели проверяется программной логикой: учитываются доступные инструменты, права пользователя и ограничения выбранного сценария.
Шаг 4. Выполняется необходимая операция.
Приложение запускает поиск по документации, получает подходящие фрагменты и передаёт их выбранной модели.
Шаг 5. Пользователь получает итоговый ответ.
Языковая модель формирует таблицу и пояснения на основании найденных данных.
Это упрощённая иллюстрация принципа маршрутизации, а не раскрытие полного внутреннего устройства PardAi.
Главное здесь то, что система разделяет принятие небольшого операционного решения и выполнение содержательной работы.
Такой подход позволяет развивать платформу, подключая разные модели, инструменты и специализированные навыки без необходимости поручать все решения одному универсальному ИИ.
Маршрутизаторы и модели структурированных решений применимы не только в сложных ИИ-агентах. Их потенциальная область использования значительно шире: от торговли до промышленного производства.
Современное сельскохозяйственное предприятие может использовать несколько цифровых систем: мониторинг полей, прогнозирование урожайности, учёт техники, метеоданные и управление складом.
Работник задаёт вопрос: «Нужно ли сегодня отправлять технику на третий участок?»
Специализированный маршрутизатор может определить, что запрос требует проверки прогноза погоды, состояния участка и графика работ.
При этом сами расчёты выполняются соответствующими сервисами, а решение о выходе техники должно учитывать установленные агрономические правила и ответственность оператора.
Польза состоит в том, что работнику не нужно самостоятельно открывать несколько приложений и искать нужные показатели.
На производстве специалисты регулярно обращаются к инструкциям, журналам неисправностей, каталогам запасных частей и нормативной документации.
Допустим, оператор сообщает: «На станке появился необычный шум после запуска».
Маршрутизатор может определить тип обращения и направить его в систему технической диагностики, поиска по документации или регистрации неисправностей.
Если запрос касается аварийного состояния оборудования, выполнение необходимых защитных действий должно определяться специализированной автоматикой и утверждёнными регламентами, а не вероятностной оценкой языковой модели.
При грамотной реализации подобная система ускоряет доступ к нужной информации и помогает сократить ручную сортировку обращений.
Логистическая компания ежедневно обрабатывает запросы о доставке, складах, транспорте и документах.
Например: «Почему задерживается поставка и когда груз прибудет?»
Маршрутизатор определяет, что требуется обращение к системе отслеживания груза. Если обнаружена задержка, система может дополнительно проверить маршрут, складские события и информацию перевозчика.
После получения данных ИИ-помощник готовит объяснение для сотрудника или клиента.
Здесь модель принятия решений полезна как интеллектуальный диспетчер между информационными системами.
Для интернет-магазина один из наиболее очевидных сценариев — распределение обращений покупателей.
Запросы «Где мой заказ?», «Хочу вернуть товар», «Подберите аналог» и «Почему изменилась цена?» требуют разных инструментов.
Первому нужен доступ к доставке, второму — к правилам возврата, третьему — к каталогу товаров, четвёртому — к истории цен и заказов.
Вместо постоянного обращения к универсальной LLM можно использовать специализированную модель, определяющую подходящий сценарий.
Это особенно интересно системам с большим количеством однотипных обращений, где даже небольшая экономия на одном запросе становится существенной при масштабировании.
В организациях ежедневно обрабатываются счета, акты, договоры, служебные записки и входящая корреспонденция.
Модель принятия решений может классифицировать документ и выбрать маршрут:
Содержание документа при необходимости извлекается отдельным OCR-сервисом или моделью анализа документов.
Маршрутизатор здесь не обязан понимать все юридические или финансовые детали. Достаточно правильно определить следующий этап обработки.
В инженерных приложениях часто существует набор специализированных вычислительных инструментов.
Один рассчитывает параметры электрической цепи, другой анализирует телеметрию, третий выполняет поиск по технической документации.
Пользователь может обратиться к системе обычным языком: «Сравни результаты последних испытаний с расчётными характеристиками».
Маршрутизатор определяет необходимые инструменты, после чего система запрашивает соответствующие данные и передаёт их для обработки.
Особенно важно, что детерминированные инженерные расчёты остаются за специализированным программным обеспечением. Языковая модель используется для интерпретации, подготовки отчёта и взаимодействия с человеком.
Идея интеллектуальной маршрутизации появилась раньше конкретной модели JEV.
Исследования FrugalGPT и RouteLLM показали, что выбор модели в зависимости от сложности задачи может существенно влиять на стоимость эксплуатации ИИ-систем.
В исследовании FrugalGPT авторы продемонстрировали сценарии, в которых каскадное использование моделей позволяло сохранять сопоставимое качество при значительно меньших затратах. В работе RouteLLM исследовались обучаемые маршрутизаторы для выбора между более сильной и более экономичной моделью.
Эти результаты относятся к конкретным экспериментальным условиям. Их нельзя автоматически переносить на любую корпоративную систему.
Существуют и готовые программные решения. Например, открытый проект vLLM Semantic Router позволяет организовать маршрутизацию между различными моделями, учитывая характеристики запроса, правила обработки, стоимость и другие ограничения.
Важно не смешивать разные технологии:
Все эти подходы решают связанные задачи, однако отличаются архитектурой и способом реализации.
Предположим, корпоративная платформа обрабатывает миллион запросов в месяц.
Если перед каждым запросом запускать большую генеративную модель только для определения необходимого инструмента, возникает дополнительная стоимость маршрутизации.
Специализированная модель потенциально способна выполнять такую операцию дешевле и быстрее.
Но итоговая экономика зависит не только от цены одного вызова.
Необходимо учитывать:
Например, если дешёвый маршрутизатор регулярно отправляет сложные обращения неподходящей модели, полученная экономия может исчезнуть из-за повторной обработки запросов.
Поэтому оценивать необходимо полную стоимость успешно выполненной задачи, а не исключительно цену токенов.
При внедрении моделей маршрутизации возникает принципиальный вопрос: что произойдёт, если модель ошибётся?
Неверный выбор модели для составления обычного письма, скорее всего, приведёт только к снижению качества ответа.
Но ошибка при маршрутизации финансового документа, технической команды или обращения с персональными данными может иметь значительно более серьёзные последствия.
Поэтому мы считаем важными несколько инженерных принципов.
Отдельно следует помнить, что высокая оценка варианта самой моделью ещё не доказывает правильность решения. Для определения рабочих порогов нужны собственные тестовые наборы и статистическая проверка.
Начинать внедрение стоит не с масштабной агентной платформы, а с конкретного процесса.
Например, выбрать обработку входящих обращений технической поддержки.
Сначала необходимо сформировать список категорий и собрать реальные примеры обращений. Затем сравнить несколько способов маршрутизации: обычные программные правила, универсальную LLM и специализированную модель вроде JEV.
Для каждого варианта следует измерить точность классификации, задержку обработки, стоимость и количество случаев, потребовавших ручного вмешательства.
Особое внимание нужно уделить ошибкам, при которых запрос уходит в неправильное подразделение или запускается неподходящий процесс.
Если результаты подтвердят преимущества специализированной модели, этот подход можно распространить на другие процессы предприятия.
Именно такая последовательность позволяет перейти от технологической демонстрации к измеримой экономической пользе.
В развитии искусственного интеллекта заметна важная тенденция: вместо попытки решить абсолютно все задачи одной универсальной моделью разработчики всё чаще строят системы из специализированных компонентов.
Одни модели работают с текстом. Другие анализируют изображения. Третьи выполняют сложные рассуждения. Четвёртые помогают выбрать нужный инструмент или определить дальнейшее действие.
JEV интересен именно как представитель последней категории.
Для бизнеса это означает возможность строить более гибкие ИИ-системы, в которых вычислительные ресурсы расходуются в соответствии со сложностью задачи.
Для разработчиков — возможность отделить маршрутизацию от генерации и создать управляемую архитектуру с понятными правилами выполнения операций.
Мы уже применяем такой принцип в PardAi, используя JEV для выбора моделей и инструментов. Для нас это не только способ оптимизации вычислений, но и один из архитектурных элементов развития корпоративных ИИ-агентов.
Перспектива подобных технологий заключается не в замене больших моделей маленькими. Она заключается в правильном распределении работы между ними.
Напишите, что не сходится в этом материале.
Адрес нужен, чтобы ответить. Другим читателям сообщение не показывается.
Дальше
Искусственный интеллект уже не просто пишет код. Современные модели осваивают проектирование электроники, создание конструкций, инженерные расчёты, анализ испытаний и самостоятельное исправление ошибок. Разбираемся, что ИИ уже умеет делать вместо инженера, где проходят границы его возможностей и как новые технологии изменят работу конструкторских бюро.
