LLM-независимый подход: как снизить риски и расходы на внедрение ИИ
На рынке уже доступны state-of-the-art модели от OpenAI, Anthropic, Google и других разработчиков. Они отличаются по качеству, размеру и стоимости эксплуатации. Но в российских реалиях решения малодоступны из-за ограничений по безопасности и требованиям к инфраструктуре. Нужно использовать облачные решения вроде Яндекса и Сбера или разворачивать open source модели в своем контуре.
Часто на старте внедрения ИИ Агентов у команды есть только набор гипотез, но нет понимания, реально ли воплотить идею на доступных в России моделях, и насколько трудоемко реализовать инициативу.
Есть два базовых варианта, что можно делать на старте внедрения:
1. Сразу начинать с дешёвой, локальной open source модели.
Риск — потратить много времени, чтобы заставить систему работать. Если задача сложная, система может не справиться.
2. Сначала использовать лучшую доступную модель.
Протестировать гипотезу на публичных данных, быстро понять, достижим ли нужный результат. Если не получается на лучших моделях за короткое время — не стоит тратить ресурсы дальше и инвестировать в переезд на доступные модели. Рассмотрите другие инициативы, которые дадут быструю победу. Если результат вас устраивает — можно пробовать решить задачу компании open-source моделями или моделями, которые доступны в российских облаках.
Для этого нужно итерироваться по доступным моделям, опираясь на данные и метрики:
— Выбираем топовую модель для тестирования гипотезы. На публичных данных строим прототип и определяем метрики качества (про метрики качества ответов расскажем в следующем посте).
— Добиваемся стабильных метрик. Ответы прототипа доводим до стабильных метрик и проверяем репрезентативность: если ответ плохой — метрики плохие, хороший — хорошие.
— Итерируемся вниз по моделям. Постепенно заменяем модель на более дешёвую/маленькую. Оцениваем, как это влияет на метрики. Если результат сохраняется — продолжаем и брем модель еще дешевле. Если качество падает — адаптируем систему.
— Находим оптимальный баланс. Останавливаемся там, где сходится экономика процесса: оптимальный трейд-офф между количеством усилий для достижения результата и ценой инференса (генерации токена).
Для пошаговой итерации нужен гибкий инструмент, чтобы переключаться между моделями без изменений в логике приложения.
Один из таких инструментов — LiteLLM, который предоставляет унифицированный API и поддерживает разные LLM-провайдеры.
А для автоматизированной оптимизации агентов советуем DSPy.
Внутри Agent Platform мы добавили LiteLLM, который подключен к российским, американским и китайским провайдерам, чтобы можно было гибко менять модели подходы к оценке качества.
#александр_опрышко #llm
На рынке уже доступны state-of-the-art модели от OpenAI, Anthropic, Google и других разработчиков. Они отличаются по качеству, размеру и стоимости эксплуатации. Но в российских реалиях решения малодоступны из-за ограничений по безопасности и требованиям к инфраструктуре. Нужно использовать облачные решения вроде Яндекса и Сбера или разворачивать open source модели в своем контуре.
Часто на старте внедрения ИИ Агентов у команды есть только набор гипотез, но нет понимания, реально ли воплотить идею на доступных в России моделях, и насколько трудоемко реализовать инициативу.
Есть два базовых варианта, что можно делать на старте внедрения:
1. Сразу начинать с дешёвой, локальной open source модели.
Риск — потратить много времени, чтобы заставить систему работать. Если задача сложная, система может не справиться.
2. Сначала использовать лучшую доступную модель.
Протестировать гипотезу на публичных данных, быстро понять, достижим ли нужный результат. Если не получается на лучших моделях за короткое время — не стоит тратить ресурсы дальше и инвестировать в переезд на доступные модели. Рассмотрите другие инициативы, которые дадут быструю победу. Если результат вас устраивает — можно пробовать решить задачу компании open-source моделями или моделями, которые доступны в российских облаках.
Для этого нужно итерироваться по доступным моделям, опираясь на данные и метрики:
— Выбираем топовую модель для тестирования гипотезы. На публичных данных строим прототип и определяем метрики качества (про метрики качества ответов расскажем в следующем посте).
— Добиваемся стабильных метрик. Ответы прототипа доводим до стабильных метрик и проверяем репрезентативность: если ответ плохой — метрики плохие, хороший — хорошие.
— Итерируемся вниз по моделям. Постепенно заменяем модель на более дешёвую/маленькую. Оцениваем, как это влияет на метрики. Если результат сохраняется — продолжаем и брем модель еще дешевле. Если качество падает — адаптируем систему.
— Находим оптимальный баланс. Останавливаемся там, где сходится экономика процесса: оптимальный трейд-офф между количеством усилий для достижения результата и ценой инференса (генерации токена).
Для пошаговой итерации нужен гибкий инструмент, чтобы переключаться между моделями без изменений в логике приложения.
Один из таких инструментов — LiteLLM, который предоставляет унифицированный API и поддерживает разные LLM-провайдеры.
А для автоматизированной оптимизации агентов советуем DSPy.
Внутри Agent Platform мы добавили LiteLLM, который подключен к российским, американским и китайским провайдерам, чтобы можно было гибко менять модели подходы к оценке качества.
#александр_опрышко #llm
❤4🔥3
Как оценивать качество ответов LLM: подходы и практики
Когда мы запускаем модель в прод, важно понимать, насколько хорошо она отвечает, где ошибается и как улучшить её работу.
Существует несколько подходов к оценке качества ответов модели:
1. Ручная экспертная оценка.
Ответы проверяют эксперты (либо доменные специалисты, либо команда QA) на тестовом датасете запросов. Высокая человеческая точность, можно учитывать контекст задачи. Но дорого, медленно и плохо масштабируется.
2. LLM-as-a-Judge
Оценку ответа делает та же или другая LLM. Быстрый и масштабируемый подход. Но возможны систематические смещения (bias), нужно выборочно валидировать результаты вручную. Примеры фреймворков: RAGAS, Deepeval.
3. Автоматические метрики
Метод сравнения ответа модели с эталонным («ground truth») с помощью алгоритмов. Быстро, объективно, но не отражает «человеческое» восприятие, нужны размеченные датасеты. Примеры метрик: BLEU, ROUGE.
4. Оценка в боевых условиях
Сбор метрик после запуска в продукт. Реальные данные, отражает влияние на бизнес. Но сложно изолировать влияние LLM от других факторов. Метрики: доля исправленных или повторных запросов, CTR и конверсия (если LLM влияет на UX), пользовательские рейтинги (лайк/дизлайк).
Мы рекомендуем комбинировать оценки и использовать следующий пайплайн:
1) Получить обратную связь пользователей в продакшне
Собираем репрезентативный набор запросов: частые кейсы, критические кейсы, граничные условия.
2) Отправить выборку на LLM-as-a-Judge.
Прогоняем тестовый набор и сохраняем все ответы с метаданными. Используем готовые метрики DeepEval и кастомные для оценки каждого ответа. Храним результаты запусков в Langfuse.
3) Отдать на оценку экспертам подозрительные кейсы.
Они подтвердят или скорректируют оценку, найдут случаи, где модель системно ошибается.
4) Проанализировать ошибки и итеративно улучшать модель
Выделяем группы возможных проблем. С начала исправляем критические и массовые ошибки. Затем повторяем запуск на том же датасете для сравнения с прошлой версией.
#александр_опрышко #llm
Когда мы запускаем модель в прод, важно понимать, насколько хорошо она отвечает, где ошибается и как улучшить её работу.
Существует несколько подходов к оценке качества ответов модели:
1. Ручная экспертная оценка.
Ответы проверяют эксперты (либо доменные специалисты, либо команда QA) на тестовом датасете запросов. Высокая человеческая точность, можно учитывать контекст задачи. Но дорого, медленно и плохо масштабируется.
2. LLM-as-a-Judge
Оценку ответа делает та же или другая LLM. Быстрый и масштабируемый подход. Но возможны систематические смещения (bias), нужно выборочно валидировать результаты вручную. Примеры фреймворков: RAGAS, Deepeval.
3. Автоматические метрики
Метод сравнения ответа модели с эталонным («ground truth») с помощью алгоритмов. Быстро, объективно, но не отражает «человеческое» восприятие, нужны размеченные датасеты. Примеры метрик: BLEU, ROUGE.
4. Оценка в боевых условиях
Сбор метрик после запуска в продукт. Реальные данные, отражает влияние на бизнес. Но сложно изолировать влияние LLM от других факторов. Метрики: доля исправленных или повторных запросов, CTR и конверсия (если LLM влияет на UX), пользовательские рейтинги (лайк/дизлайк).
Мы рекомендуем комбинировать оценки и использовать следующий пайплайн:
1) Получить обратную связь пользователей в продакшне
Собираем репрезентативный набор запросов: частые кейсы, критические кейсы, граничные условия.
2) Отправить выборку на LLM-as-a-Judge.
Прогоняем тестовый набор и сохраняем все ответы с метаданными. Используем готовые метрики DeepEval и кастомные для оценки каждого ответа. Храним результаты запусков в Langfuse.
3) Отдать на оценку экспертам подозрительные кейсы.
Они подтвердят или скорректируют оценку, найдут случаи, где модель системно ошибается.
4) Проанализировать ошибки и итеративно улучшать модель
Выделяем группы возможных проблем. С начала исправляем критические и массовые ошибки. Затем повторяем запуск на том же датасете для сравнения с прошлой версией.
#александр_опрышко #llm
🔥9👍6❤1