LLM 0.37 добавил мультимодальные эмбеддинги и принял правки от 12 авторов

У CLI-инструментов для работы с моделями быстро появляется одна и та же проблема: каждый провайдер требует отдельной настройки, а данные уже давно не ограничиваются текстом. В LLM 0.37 Саймон Уиллисон взялся сразу за обе части. Релиз упрощает подключение OpenAI-совместимых API и позволяет передавать в систему эмбеддингов объекты разных типов — текст, аудио, изображения и видео.

На практике это означает меньше специального кода вокруг моделей. Если команда хранит расшифровки звонков, фотографии товаров и обучающие ролики, ей больше не нужно заранее притворяться, будто всё это один и тот же тип содержимого. Каждый объект может получить собственный content type, а подходящая мультимодальная модель — построить для него векторное представление.

Один интерфейс для разных провайдеров

Новая команда llm openai endpoint add предназначена для сервисов, которые повторяют формат API OpenAI. Раньше разработчику приходилось вручную разбираться с конфигурацией дополнительной модели. Теперь подключение вынесено в отдельную команду CLI.

Простой сценарий выглядит так: у команды есть внутренний шлюз или сторонний поставщик с OpenAI-совместимым API. Разработчик добавляет его конечную точку, указывает доступную модель и после этого вызывает её через привычный интерфейс LLM. Это особенно удобно для прототипов и внутренних инструментов, где модели приходится регулярно менять или сравнивать.

В релиз также добавлена поддержка gpt-6.1-sol и gpt-6.1-terra. Моделью по умолчанию для пользователей, которые не выбрали свою, стала gpt-6-luna. По словам Уиллисона, она стоит вдвое дешевле прежней модели по умолчанию — gpt-5.6-luna. Для существующих установок с явно заданной моделью это изменение ничего не переключает.

Эмбеддинги перестали быть только текстовыми

Главное архитектурное изменение — поддержка разных типов бинарного содержимого при построении эмбеддингов. Это нужно для моделей вроде Gemini Embedding 2, способных работать не только с текстом, но и с аудио, изображениями и видео.

Представим поиск по базе поддержки. Пользователь вводит текстовый вопрос, а подходящий ответ может находиться в инструкции, скриншоте интерфейса, записи разговора или фрагменте видео. Мультимодальные эмбеддинги позволяют поместить такие материалы в общее пространство поиска. Сам LLM 0.37 не строит готовую поисковую систему, но убирает один из неприятных барьеров: библиотека больше не требует считать все входные объекты одинаковыми.

Здесь важно проверить возможности выбранного провайдера. Поддержка формата в библиотеке не означает, что любая подключённая модель умеет обрабатывать все четыре типа данных. Ограничения по размеру файлов, стоимости, форматам и качеству поиска тоже остаются на стороне конкретной модели.

ИИ-пул-реквесты как подробные баг-репорты

Отдельно Уиллисон описал опыт работы с ИИ-ассистированными вкладами в открытый проект. В релиз вошли исправления от 12 авторов, и почти все они создавались с помощью ИИ. Вместо автоматического доверия к готовым патчам автор использовал Opus 5.5 или GPT-6 Astra для первичного разбора предложений.

Полезная мысль здесь не в том, что ИИ-код можно принимать без проверки. Уиллисон смотрит на такой пул-реквест как на баг-репорт, к которому приложен воспроизводимый пример и возможное решение. Иногда патч подходит, иногда проблему проще исправить заново. Такой процесс снижает цену первичной сортировки, но ответственность за архитектуру и итоговый код всё равно остаётся у сопровождающего проекта.

Практический вывод: LLM 0.37 стоит проверить командам, которые переключаются между провайдерами или строят поиск по смешанным данным. А владельцам открытых репозиториев полезен сам редакционный подход: отделять ценность найденной проблемы от качества присланного ИИ-патча и проверять их независимо.