К счастью, переход от закрытого ПО к открытому не связан с традиционной медленной и болезненной миграцией, особенно если вы используете управляемый сервис. Такие сервисы не отстают от темпов развития искусственного интеллекта и при этом избавляют ваш бизнес от большей части сложностей.
Теперь зона поражения стала значительно меньше, а технологический стек, который необходимо перенести, — проще. Оболочки, шлюзы и инструменты созданы с расчетом на работу с самыми разными моделями. Вы можете воспользоваться этим в полной мере для быстрого и комплексного перехода с закрытых моделей на открытые.
Мы расскажем о стратегии успешной миграции, которую применяют наши клиенты. Это может занять от нескольких недель до пары месяцев вместо долгих месяцев и лет. В будущем мы также предоставим материалы, которые помогут вам отслеживать свой прогресс на каждом этапе.
Это общий обзор. Мы планируем подготовить подробные материалы по каждому разделу, который, по нашему мнению, требует большей детализации, включая рабочие тетради, примеры и пошаговые руководства.
Этап поиска
Когда вы начинаете искать подходящие модели, самое главное — четко понимать, что именно вы оцениваете. Универсальной модели, которая была бы лучше всех во всем, не существует. Разные модели имеют свои сильные стороны в различных сферах, и чем точнее вы определите стоящие перед вами задачи, тем проще будет отобрать те модели, которые действительно вам подойдут. Начните с описания вашего варианта использования и рабочей нагрузки простыми языком: какие задачи решает модель, как выглядит хороший ответ и каков состав вашего трафика.
После определения сценария использования готовые бенчмарки станут полезным инструментом фильтрации. Выберите бенчмарки, наиболее релевантные для вашей работы, чтобы показатели в таблицах лидеров коррелировали с эффективностью решения ваших задач. Хорошими источниками бенчмарков являются The Open Frontier, Artificial Analysis, Epoch AI, Vals AI, Scale's leaderboards, Intelligence и Arena. Среди них вам могут пригодиться следующие бенчмарки:
- Агенты для написания кода: FrontierCode, DeepSWE, Terminal Bench 4
- Чат и общие функции ассистента: LMArena, AA-Intelligence Index
- Агенты и использование инструментов: τ-bench, Agent Arena
- Зрение: Vision Arena
Помните, ваша задача — определить, какие из них имеют значение для сужения круга потенциальных моделей; о пользовательской оценке (evals) мы поговорим позже. Как правило, на выбор доступны три уровня моделей, как показано выше.
Для главных кандидатов выходите за рамки базовой производительности. Оцените стоимость одной задачи, количество токенов, расходуемых моделью на одну попытку, необходимое количество шагов, сквозное время выполнения (end-to-end runtime) и скорость проверки правильности ответа. Многие новые бенчмарки теперь публикуют эти показатели в расчете на одну задачу, и мы считаем, что они лучше коррелируют с реальной стоимостью и производительностью моделей. Модель, которая набирает на несколько баллов меньше, но выполняет задачи, используя вдвое меньше токенов и времени, может подойти лучше.
Наконец, проведите практическое тестирование. Возьмите несколько репрезентативных задач в среду тестирования (playground) и посмотрите, работают ли отобранные модели так, как ожидалось. Следите за сбоями и задавайте вопрос: это сбой самой модели или окружающей ее оболочки и контекста? Также полезно узнать, что говорят о своем опыте другие компании, использующие эти модели. После этого шага у вас должно остаться от двух до трех моделей, готовых к серьезному тестированию.
Этап оценки
Оценка моделей — самая сложная часть этого процесса, и она, безусловно, заслуживает отдельной статьи в блоге, но на верхнем уровне вы будете оценивать две вещи: точность и производительность.
Точность определяет возможности модели. Она может включать следование инструкциям, суммаризацию, вызов функций, работу с визуальными данными и т. д. Это всё, что модель способна делать независимо от того, где она запускается и насколько она быстра. Вам нужно оценить, способна ли она удовлетворить потребности вашей рабочей нагрузки.
Производительность охватывает то, насколько хорошо работает модель. Этот показатель меняется в зависимости от таких факторов, как размер модели и ее архитектура. В этих тестах нас не волнует, насколько хорошо модель отвечает на запросы. Мы оцениваем, соответствует ли модель ожиданиям по стоимости, удобству для пользователя или задержке (latency), необходимым для внедрения OSM (модели с открытым исходным кодом).
Как для оценки точности, так и для производительности вам потребуется придерживаться единого подхода: бенчмарки полезны для понимания общего направления, но реальные тесты проводятся на настоящих данных. Лучший способ оценить рабочую нагрузку — не искать или запускать общие бенчмарки. У рабочих нагрузок разные профили трафика, специфические требования к ответам и структура запросов. Ни один бенчмарк не может отразить это лучше, чем ваши собственные данные. К счастью, если вы уже используете закрытые модели, простое воспроизведение существующего трафика — это все данные, которые вам нужны для бенчмаркинга. Никаких пользовательских наборов, никаких огромных массивов данных. Это был и всегда остается лучший способ тестирования еще до того, как мы начали оценивать современные передовые модели (в сферах высокопроизводительных вычислений, баз данных, балансировки нагрузки и т. д.). Убедитесь, однако, что вы по-прежнему тестируете систему на соответствие заданным ранее целевым показателям.
Если у вас нет данных для воспроизведения, вы не заблокированы! Мы все равно можем подобрать размер в соответствии с общими шаблонами использования, такими как объем ввода-вывода и ожидаемый коэффициент попаданий в кэш. Если провайдеры закрытых моделей не предоставляют эти метрики, такие шлюзы, как LiteLLM, могут помочь собрать такую информацию. Мы подробно обсудим этот метод в отдельной статье.
После того как вы нашли данные, определите свои цели. Хотите ли вы сэкономить? Повысить скорость? Улучшить или сохранить прежнее качество? Когда вы повторно прогоните свои данные на выбранных новых моделях, это станет вашей целевой линией. Ваша задача — достичь ее или превзойти. Когда OSM преодолевают эту целевую линию, вы получаете техническое подтверждение и можете переходить к полномасштабной миграции.
Инвестиции в надежные методы оценки позволят вашей команде в дальнейшем легко и быстро внедрять новые OSM. В следующей статье мы гораздо подробнее рассмотрим, как оценивать размер рабочей нагрузки, повторно запускать трафик и оценивать результаты. А пока это базовые принципы оценки OSM.
Этап адаптации
Передовые открытые модели становятся достаточно хорошими, чтобы работать «из коробки» для большинства приложений, но если модель не прошла ваши тесты, ее придется адаптировать. Это не обязательно означает, что модель бесперспективна. Обычно это значит, что способ ее использования был настроен под другую модель: промпт, параметры сэмплирования, окружающая оболочка. Ваша текущая настройка для закрытого ПО содержит множество накопленных параметров, с которыми модель с открытым исходным кодом никогда не сталкивалась, и, скорее всего, ее придется адаптировать.
В вашем распоряжении есть несколько рычагов, примерно в порядке увеличения трудоемкости:
- Инженерия системных промптов: попробуйте давать модели инструкции иначе. Модели обучаются по-разному, и для работы на том же уровне, что и ваша текущая закрытая модель, им могут потребоваться другие промпты.
- Настройки инференса модели: такие параметры сэмплирования, как temperature и top_k, сохраненное мышление (preserved thinking) и объем рассуждений (reasoning effort), могут существенно изменить поведение.
- Контекстная инженерия и сама оболочка: навыки, инструменты и серверы MCP, составляющие программную среду, в которой работает модель.
- Веса моделей посредством дообучения или дистилляции: это сложнее всего реализовать, так как требуются четко определенные оценки, тщательно подобранные данные и реальные эксперименты, но это может открыть узкую нишу и позволить небольшой модели значительно превзойти свои возможности.
Какой бы рычаг вы ни задействовали, воспринимайте этот процесс как итеративный цикл. Настраивайте эксперименты, изолирующие одно конкретное изменение, оценивайте его влияние и повторяйте процесс до тех пор, пока не найдете то, что действительно улучшает оценки. Поддерживайте модульность оценок и простоту экспериментов. Если вы тестируете слишком много вещей и меняете слишком много переменных одновременно, вам никогда не удастся выделить то, что действительно работает, на фоне мешающих факторов. Набор четко определенных оценок, о которых говорилось выше, — это самое главное, когда дело доходит до продуктивной итерации вышеупомянутых адаптаций.
Принятие решения
Техническая валидация — это полдела, как и при любой миграции. Как только вы доказали, что открытые языковые модели (OSM) могут соответствовать функциональности вашего текущего проприетарного решения или превосходить ее, вам нужно упаковать эти результаты и донести «почему» до заинтересованных сторон.
Опишите объем усилий, необходимых для миграции на OSM, возможные риски и окупаемость инвестиций (ROI).
Несколько общих рекомендаций, основанных на нашем опыте:
Трудозатраты определят реальный объем работы, необходимый для перехода на OSM. Иногда возникают проблемы совместимости с обвязками и инструментами, но этот разрыв сокращается с каждым днем. Например, togetherlink, инструмент, предоставляемый нами, делает установку простой для начала использования OSM в любой обвязке. Задокументируйте любые интеграции или изменения, которые необходимо внести для полноценного использования OSM в масштабе.
Риски отражают традиционные риски, связанные с внедрением новой технологии: соответствие требованиям, масштабирование, продолжение миграции, знакомство с инструментами, влияние на нижестоящие сервисы. Задокументируйте их и проработайте с учетом специфических потребностей вашей компании. Большинство из них решается управляемыми провайдерами, если вы решите воспользоваться их услугами.
Если вы дойдете до этого этапа с правильно настроенными оценками, данная часть может быть существенно упрощена, хотя вы все равно можете рассматривать ее как цикл, возвращающий данные на этап оценки.
ROI можно рассчитать как количественную величину на основе вашего этапа оценки. Сколько токенов вы можете сгенерировать на один доллар? Как это соотношение выглядит по сравнению с проприетарными решениями? В некоторых случаях мы наблюдаем снижение затрат до 70% при переходе клиентов на открытый исходный код. То же самое можно сделать и для качества: как качество соотносится с проприетарными аналогами? Это поможет определить окупаемость инвестиций для заинтересованных сторон.
В идеале, при определенных рисках, трудозатратах и ROI, принять решение после этого будет легко. Внедрение на данном этапе в большей степени связано с обучением, а не с техническими ограничениями.
Продакшн
С момента получения одобрения начинается миграция. Как уже упоминалось, традиционный перенос в продакшн после миграции — это долгий и затянутый процесс. Тем не менее, при переходе с закрытых решений на OSM мы обнаруживаем, что это на самом деле один из самых легких шагов.
Мы можем использовать опыт традиционных практик миграции, чтобы оценить влияние вашей миграции и составить дорожную карту. Мы можем в основном опираться на разделы об усилиях и рисках, приведенные ранее. Повлияем ли мы на нижестоящие сервисы? Как получить одобрение модели у команд безопасности и комплаенса? Требуются ли какие-либо изменения в инструментах или сервисах, созданных на базе предыдущих моделей? Этот переход также не обязательно должен быть мгновенным. Развертывание методом canary (канареечное развертывание) показало отличные результаты у наших клиентов при проверке в боевых условиях, начиная с перенаправления 10% трафика на открытый исходный код.
Дорожная карта состоит из всех шагов, необходимых для внедрения OSM. Она должна включать любые изменения в области безопасности и комплаенса, технологические изменения или изменения в нижестоящих сервисах, которые необходимо сделать. Не пугайтесь этого: техническая реализация может быть такой же простой, как замена эндпоинта!
Мы понимаем, что это очень упрощенный обзор, но по своей сути мы проходили через этот переход десятки раз с нашими крупнейшими клиентами и твердо уверены, что он гораздо менее обременителен, чем традиционная техническая миграция.
Если вы проходите через аналогичную миграцию, мы рекомендуем следить за нашими будущими блогами или обращаться по адресу sales@together.ai с любыми вопросами. И мы будем рады любым отзывам о том, что здесь могло быть упущено. Приятной разработки!
