Топовые LLM фреймворки могут быть не так надёжны, как вы думаете

Месяц назад решил добавить поддержку Gemini в Feeds Fun и под это дело изучал топовые LLM фреймворки — писать свой велосипед не хотелось.

В итоге нашёл стыдный баг в интеграции с Gemini в LLamaIndex. Судя по коду, он есть и в Haystack и в плагине для LangChain. А корень проблемы вообще в SDK Google для Python.

При инициализации нового клиента для Gemini код фреймворка перетирает/подменяет API ключи во всех клиентах, созданных до этого. Потому что API ключ, по-умолчанию, хранится в синглетоне.

Смерти подобно, если у вас multi-tenant приложение, и незаметно во всех остальных случаях. Multi-tenant — это когда ваше приложение работает с несколькими пользователями.

Например, в моём случае, в Feeds Fun пользователь может ввести свой API ключ, чтобы улучшить качество сервиса. Представьте какой забавный казус мог бы случиться: пользователь ввёл API ключ для обработки своих рассылок, а потратил токенов (заплатил) за всех пользователей сервиса.

Репортил только в LLamaIndex как security issue и уже 3 недели ноль реакции, для Haystack и LangChain лень воспроизводить. Так что это ваш шанс зарепортить багу в топовый репозиторий. Под катом будет вся инфа, воспроизвести не сложно.

Ошибка примечательна многим:

1. Оценка критичности ошибки очень зависит от вкусовщины, опыта и контекста. Для меня, в проектах в которых я работал, — это критическая ошибка безопасности. Но, похоже, для большинства актуальных проектов, которые используют LLM, это вообще не принципиально. Что навевает некоторые мысли о мейнстрим около-LLM разработках.
2. Это хороший индикатор низкого уровня контроля качества кода: код ревью, тестов — всех процессов. Всё-таки это интеграция с одним из топовых провайдеров API, найти проблему можно было кучей разных способов, но ни один не сработал.
3. Это хорошая иллюстрация порочного подхода к разработке: «копипастим из туториала и льём на прод». Чтобы допустить эту ошибку нужно было проигнорить одновременно и базовую архитектуру твоего проекта и логику вызова кода, который ты копипастишь.

В итоге я забил на эти фреймворки и впилил свой костыль, благо HTTP API для Gemini есть.

Мой вывод из этого безобразия такой: доверять коду, который под капотом у современных LLM фреймворков нельзя. Надо перепроверять, вычитывать. То, что у них написано «production ready», не значит, что они действительно production ready.

Далее расскажу подробнее про сам баг.

Далее

Места для обсуждения Feeds Fun

Продолжаю развивать свою читалку новостей: feeds.fun. Чтобы собирать информацию и людей вместе, завёл несколько ресурсов, где можно обсудить проект и найти полезную информацию:

• Блог blog.feeds.fun
• Discord
• Reddit r/feedsfun

Пока что там никого и ничего нет, но со временем обязатено будут и новости и люди.

Если вам интересен этот проект, добавляйтесь! Буду рад вас видеть и постараюсь быстро реагировать на все вопросы.

P.S. Если вы пропустили эту мою активность, то вот пост с описанием проекта.

Мигрируем с GPT-3.5-turbo на GPT-4o-mini

На днях OpenAI выпустила GPT-4o-mini — новую флагманскую модель для дешёвого сегмента, так сказать.

• Говорят, работает «почти как» GPT-4o, а иногда даже круче GPT-4.
• Почти в 3 раза дешевле GPT-3.5-turbo.
• Размер контекста 128k токенов, против 16k у GPT-3.5-turbo.

Конечно я сразу побежал переводить на эту модель свою читалку новостей.

Если кратко подвести итоги, то это крутая замена GPT-3.5-turbo. У меня получилось сходу, не меняя промпты, заменить двух LLM агентов на одного и суммарно удешевить работу читалки раз в 5 без потери качества.

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

Далее

Computational mechanics & ε- (epsilon) machines

Открыл для себя новые направления для мониторинга.

Computational mechanics

Авторам минус за тавтологию. Есть вычислительная механика, которая занимается численным моделированием механических процессов и про неё есть статься на вики. Этот пост не про неё.

Этот пост про computational mechanics, которая изучает абстракции сложных процессов: как эмерджентное поведения возникает из суммарного поведения / статистики низкоуровневых процессов. Например, почему стабильно Большое Красное Пятно на Юпитере, или, почему результат вычислений процессора не зависит от свойств каждого электрона в нём.

ε- (epsilon) machine

Концепт устройства, которое может существовать в конечном множестве состояний и может предсказывать своё будущее состояние (или распределения состояний?) на основе текущего.

Computational mechanics позволяет (или должно позволять) представить сложные системы как иерархию ε-machine. Тем самым появляется формальный язык для описания сложных систем и эмерджентного поведения.

Для примера, наш мозг можно представить как ε-machine. Формально, состояние мозга никогда не повторяется (напряжения на нейронах, позиции молекул нейромедиаторов, etc), но существует огромное количество ситуаций, когда мы делаем одно и то же в одних и тех же условиях.

Научно-популярное изложение: https://www.quantamagazine.org/the-new-math-of-how-large-scale-order-emerges-20240610/

P.S. Попробую копнуть в научные статьи. Расскажу, если найду что-нибудь интересное и прикладное. P.P.S. Давно думаю в сторону похожей штуки. К сожалению, повороты жизненного пути не позволяет серьёзно копать в науку и математику. Всегда радуюсь, когда сталкиваюсь с результатами копания других людей.

Отчётная презентация по World Builders 2023

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

По сути, это рассказ об итогах всех моих активностей в школе.

Слайды: https://drive.google.com/file/d/1gg0rcotCtX2g0PsJsEWFX-qdhqEf6--y/view

Все материалы по моему участию в школе смотрите в блоге по тегу World Builders.

Это не последний рассказ о World Builders. Как минимум, я расскажу как делал roadmap и финансовую модель для игры. Следите за блогом.