Топовые 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 лень воспроизводить. Так что это ваш шанс зарепортить багу в топовый репозиторий. Под катом будет вся инфа, воспроизвести не сложно.
Ошибка примечательна многим:
- Оценка критичности ошибки очень зависит от вкусовщины, опыта и контекста. Для меня, в проектах в которых я работал, — это критическая ошибка безопасности. Но, похоже, для большинства актуальных проектов, которые используют LLM, это вообще не принципиально. Что навевает некоторые мысли о мейнстрим около-LLM разработках.
- Это хороший индикатор низкого уровня контроля качества кода: код ревью, тестов — всех процессов. Всё-таки это интеграция с одним из топовых провайдеров API, найти проблему можно было кучей разных способов, но ни один не сработал.
- Это хорошая иллюстрация порочного подхода к разработке: «копипастим из туториала и льём на прод». Чтобы допустить эту ошибку нужно было проигнорить одновременно и базовую архитектуру твоего проекта и логику вызова кода, который ты копипастишь.
В итоге я забил на эти фреймворки и впилил свой костыль, благо HTTP API для Gemini есть.
Мой вывод из этого безобразия такой: доверять коду, который под капотом у современных LLM фреймворков нельзя. Надо перепроверять, вычитывать. То, что у них написано «production ready», не значит, что они действительно production ready.
Далее расскажу подробнее про сам баг.
Про увольнение Sam Altman и регуляцию ИИ
ChatGPT: Draw an image: "Skynet writes regulations for the AI industry" in the style of "Reply of the Zaporozhian Cossacks".
Последние дни идут новости, что Sam Altman — CEO OpenAI — уволен советом директоров и вслед за ним уходит много сотрудников компании.
Точных причин не названо, формулировка борды в духе «утратил доверие».
На сколько я понимаю, основная гипотеза интернетов на текущий момент — разногласия между фракциями прогрессоров и регуляторов.
- Регуляторы хотят притормозить эксперименты до момента, очевидно, их зарегулирования государством.
- Прогрессоры хотят двигаться вперёд с той же скоростью, а то и с большей.
Sam Altman выступает за фракцию прогрессоров.
Если всё так, то его уход — плохая новость. На мой взгляд, самое вредное, что можно сейчас сделать для отрасли — это зарегулировать её.
Feeds Fun — читалка новостей с тегами и ChatGPT
Выглядит неприглядно, но это временно.
Задержался с постом, а между тем читалка уже работает и экономит мне 4-8 часов в неделю.
Для нетерпеливых и ленивых:
- Репозиторий: github.com/tiendil/feeds.fun
- Сайт: feeds.fun — заходите, подписывайтесь на подготовленные коллекции новостей, экспериментируйте.
Суть:
- Читалка автоматически определяет теги для каждой новости. Тут очень кстати пришлась ChatGPT.
- Вы создаёте правила в духе
elon-musk & twitter => score -100500,procedural-content-generation & hentai => score +13. - В интерфейсе сортируете новости по интересности и читаете только самые-самые именно для вас.
Если есть просьбы по фичам — создавайте issue, постараюсь воплощать. Хочется, чтобы штука пошла в народ.
Глупые прогнозы об Искусственном Интеллекте
DALL-E: Wrubel painting: silly predictions about artificial intelligence
Пару месяцев назад начал делать заметки на тему поста с намерением не спеша накопить к лету и опубликовать. А тут некоторые прогнозы сбываться начинают :-D Поэтому закину что есть, без сроков и гарантий.
База для прогнозов:
- История развития ИТ;
- Понятие о подрывных технологиях, которой без сомнения является ИИ.
- Здравый смысл, как бы смешно это не звучало, исходя из названия эссе.
Поскольку даты для для прогнозов не указываю, можно считать их скорее трендами, направлениями эволюционного давления, чем конкретными событиями.
Пара слов о GitHub Сopilot
DALL-E: "Vrubel style painting of pair programming Robot + Human. An robot is writing code, a human is reviewing code".
Последние несколько недель использовал GitHub Сopilot, благо для Emacs есть плагин. Поделюсь впечатлениями.
Для справки, я уже лет 15 осознанно не использовал умное автодополнение. Всё моё автодополнение — это DynamicAbbreviations, по сути — дополнение написанного слова на основе словаря из открытых исходников.
Причина отказа такая: используя «умное» автодополнение (например, подсказку аттрибутов/методов объекта) перестаёшь понимать проект. Начинаешь на автомате брать предлагаемые варианты методов/переменных, не разбираясь что они конкретно делают и есть ли альтернатинвые варианты.
В краткосрочной перспективе отказ от автодополнения повышает нагрузку на человека (особенно на память) и замедляет работу, но в доглосрочной даёт глубокое понимание проекта, возможнсоть крутить его в голове как угодно, что с лихвой окупает потери на скорости в моменте. А поскольку я работаю только над долгими проектами, долгосрочная выгода важнее.
С Copilot я, похоже, вернуcь к умному автодополнению, в его более правильном варианте.
Итак, давайте посмотрим чего умеет и не умеет Copilot.