Гречневые мысли

TinyRAG Я очень люблю маленькие штуки, которые хорошо понимают, зачем они были созданы. Они не будут пытаться двигать горы — они good enough для того, чтобы быть полезными и поэтому они лучшие в своей весовой категории. Один из примеров подобного — wordllama, про которую я писал полтора месяца назад. Для тех, кто не помнит, автор объединил эмбеддинг слои нескольких крупных моделей (phi-3-medium, llama-2-70b) и обучил маленький безконтекстный потокенный эмбеддер. Потом этот эмбеддер он экспортировал в одну numpy-матрицу размером 16 мб и получил модель, которая лучше GloVe по качеству и лучше бертов по скорости и по потреблению ресурсов. В качестве одной из демонстраций, автор сделал semantic chunking властелина колец всего за 700 мс — по-моему, офигенно. И вот, вчера ночью, пытаясь найти решение очередной проблемы с торчом на рандомных issue гитхаба, я понял, что в жизни мне не хватает нечёткого поиска по веб-страничке. Такого усиленного Ctrl+F, который бы искал по смыслу, а не по полнотекстовому совпадению. А если бы у меня там в фоне ещё и моделька работала бы, которая, пусть даже с задержкой, отвечала на мой вопрос по найденным чанкам, то было бы совсем прекрасно. К сожалению, писать расширения для хрома я пока что не умею, но родить небольшое CLI приложение, решающее эту задачу, я смог. Как это работает: - В терминале вы вбиваете python frontend.py some.website.com - Requests скачивает веб-страничку, bs4 чистит её от мусора и возвращает только текст - Wordllama проводит semantic chunking этого текста и сохраняет всё в список (FAISS? А зачем? У меня же не c4 или википедия, у меня никогда не будет столько чанков, чтобы я ждал векторизации какое-то ощутимое количество времени) - Llama-cpp-python подгружает маленькую LLM, на экране рисуется заветный промпт Q:, предлагающий задать вопрос (прошло приблизительно полсекунды с момента запуска скрипта, потому что подгрузка моделей происходит в фоне) - Пользователь задаёт вопрос - Wordllama находит топ-6 самых близких чанков - Wordllama ранжирует их и фильтрует их по близости к вопросу - Собирается контекст для модели, модель отвечает - Кроме ответа модели пишутся референсы со ссылками на выделенные релевантные чанки Я сотворил маленькое чудо и смог собрать llama-cpp-python с поддержкой CUDA, так что если у вас есть ~2 гига свободной видеопамяти, то gemma-2-2b-instruct вам ответит приблизительно за 300 миллисекунд. Если нет — скрипт сначала скинет релевантные чанки, а потом придётся подождать генерации секунд 10-20. Возможно, я где-то налажал — заводите пуллреквесты :) Качество — иногда оно отвечает неправильно, иногда правильно. Моей навороченной реализации агентного RAG эта штука, очевидно, проигрывает, но зато она и работает в сотни раз быстрее и видеопамяти потребляет в десять раз меньше. Если не устраивает ответ — просто переспросите. Замеры качества есть в репозитории. Пользуйтесь! https://github.com/chameleon-lizard/tinyrag UPD: Добавил подгрузку ресурсов в фоне (теперь не надо ждать пока всё загрузится и можно сразу писать вопросы) и возможность передать запрос напрямую (теперь tinyrag можно использовать в скриптах).

https://habr.com/ru/companies/sberdevices/articles/855368/ Видимо, меня читают гигачатовцы — вот так и надо замерять модели, хвалю. Отдельное спасибо за замеры на ифевале, теперь понятно, почему про меня так раздражал. При этом Яндекс за их репорты я не хвалю. Жаль, что моделька <size>b*, конечно, потому что есть модели сильнее и меньше по размеру, тот же квен. Я руками потыкал, как будто бы модель стала нормально справляться с моими стандартными тестами: - NER на крылышках - 6 вопросов по длинному тексту (извлечение всех имён персонажей, саммари, генерация объявления, генерация неформального письма, рецепт пасты на английском и вопрос по тексту) - Написание кода (6 сравнительно несложных функций) - Переписывание текста в другом стиле (переписываю заявку на железо в стиле Вахи и Фоллаута) Пользоваться моделью я вряд ли буду — для каждого из перечисленных юзкейсов есть модели, которые справляются гораздо лучше — но наконец то гига стала вполне себе удобоваримой. *тут было число, но вроде бы это непубличная инфа — модель немаленькая :)

Перплексия и изотропия декодера, графики качества моделей и зависимость метрик от числа параметров.

Гребёночка с обучения роберты, таблички с качеством и графики адаптации.

Improving Language Plasticity via Pretraining with Active Forgetting Адаптация языковых моделей под новый язык (и мультиязычность в целом), по моей собственной классификации, может быть достигнута тремя способами: 1. Обучить модельку на взвешенном, примерно равном миксе сетов на разных языках (XGLM, mGPT) 2. Сделать обычный претрейн на слегка грязноватом дампе интернета и вытянуть языки, которых было меньше в корпусе, через SFT (Saiga, Suzume, Aya-23) 3. Поменять токенизатор у моделей, занулить эмбеды и "похилить" на небольшом сете (Старые вихри, RuAdapt) Про минусы первого подхода я расскажу когда-нибудь позже, второй подход — это то, что сейчас все делают, а на третий подход почти все забили, потому что токенизаторы современных моделй и так достаточно большие, а к более высокому качеству это, казалось бы, не ведёт. А действительно ли не ведёт? Исследователи из Meta и Reka AI почти полтора года назад выпустили статью, где на энкодерах (RoBERTa-base) проверялась следующая гипотеза: поскольку модель во время обучения не подвергалась замене слоя эмбеддингов, его замена при файнтюне на новый язык сильно бьёт по качеству и требует гораздо большего числа токенов для получения приемлемых результатов. Поэтому во время претрейна на английских данных, они предлагают раз в какое-то время этот слой обнулять, вместе с ним обнуляя шедулеры лр и стейты оптимизатора. Итоговый loss curve похож на гребёнку, но в целом повторяет форму кривой обучения той же модели на том же сете обычным способом, хоть лосс и немного выше. После этого они перестают обнулять слой с эмбеддингами (фризя все слои кроме него, обучая эмбеды под новый язык), а затем тюнят на итоговую задачу только на английских данных. При этом, мультиязычных данных используется очень мало — всего лишь 5 миллионов токенов, что в сотни и тысячи раз меньше, чем надо данных при классической адаптации. Итоговая модель не просто хорошо адаптируется, а просто разрывает модель, претрейненную классическим способом, на бенчмарках. В среднем, адаптированная через Active Forgetting модель работает на 21% лучше на XNLI, теряя всего 1% качества на английском языке. Кроме того, модели сходятся быстрее — за 5к шагов модели, обученные с Active Forgetting, успешно обучаются на 92% от финального качества и получают скор в 57.8, тогда как обычные модели обучаются на 53% и болтаются где-то недалеко от random guessing. Больше всего от такого претрейна улучшаются те языки, которые меньше всего шарят токенов с английским — русский, китайский, хинди, суахили — так что для нас эта статья особенно актуальна. Спустя полтора года вышла статья от Microsoft, где проверялась та же гипотеза на декодерных трансформерах. Вывод тот же: на декодерах претрейнинг с Active Forgetting помогает, причём модели проверяли вплоть до 2.8B и скейлинг сохранялся, так что подход рабочий и можно тестить на моделях большего размера. Ждём, получается, phi-4, llama-4 или gemma-3, которые будут здорово адаптироваться под новые языки! Paper 1: https://arxiv.org/abs/2307.01163 Paper 2: https://arxiv.org/abs/2410.16168

GPU Poor Arena В качестве одного из сравнительно честных способов сравнить качество моделей раньше была ллмарена. Почему раньше? Потому что модели стали достаточно большими и умными, а преференс тюнинг достаточно продвинутым, чтобы появилась возможность хакать лидерборд через, например, красивость ответа, длину или ещё что-то. К примеру, вопросы, которые задают люди, не особенно сложные для нынешних моделей. У меня есть предположение, что большинство людей, которые хотят сравнить модели, задают одну из стандартных загадок про сестер Салли, сохнущие футболки или банан и выбирают ту модель, которая ответит лучше. Разумеется, лучше ответит та модель, которую потюнили на парах ответов из арены -- потому что её ответ будет лучше попадать во вкусы юзеров, будучи гарантированно верным (ведь модель уже запомнила ответ). Реально сложных задач, на которые ответить могут только мощные модели, довольно мало -- а инвесторы ведь платят за высокое место в популярных бенчмарках, а не за хорошие модели, так что авторы продолжают тюнить модели на ответах с арены, а лидерборд становится все более и более бессмысленным. Весь топ забит моделями, которые хорошо решают загадки, но не впечатляют при реальном использовании: Gemini Flash там, к примеру, обходит соннет 3.5, а Mistral Large -- Claude Opus. Ну и главная проблема арены -- там в топе здоровенные модели. Мы -- простые смертные с 3060 и оперативкой -- не можем запустить, так что и применимость такого лидерборда не то чтобы нулевая, но, скажем так, ограниченная. Авторы GPU Poor LLM Arena подошли к описанным проблемам радикально -- они принципиально берут в лидерборд только модели меньше 9б параметров и с квантизацией. Эти модельки мы сможем гонять дома на консумерских карточках -- и, что ещё важнее, сможем реально оценить на новом, пока что не насыщенном, бенчмарке, качество мелких моделей. Идея, имхо, офигенная, но я бы по другому поставил границу требовательности моделей. Лучшие карты по доллару на гигабайт сейчас это 3060 и 3090 -- с 12 и 24 гб памяти соответственно -- так что я бы сделал лидерборд, который ориентирован на модели, которые бы умещались в эти карты. С 24 гигами памяти уже можно развернуться -- туда влезет и gemma-2-27b в 4 битах, и qwen-2.5-14b в восьми, и даже 7-9b модельки без квантизации. Тысячи инженеров, пытающихся впихнуть раг в одну 3090 сказали бы спасибо за такой лидерборд! Жаль только, что очередь на генерацию длинная (мне показало 120 секунд) и из-за этого все загнётся через неделю. https://huggingface.co/spaces/k-mktr/gpu-poor-llm-arena

Ответы моделей со стандартными параметрами семплирования бота. Обратите внимание на характерные артефакты англоязычных моделей — "суши-палочки" это как будто бы прямое калькирование фразы sushi sticks? Они, правда, называются chopsticks... Видимо, всё таки вихри не так хороши на русском в домене кухонной утвари, как о них пишут авторы :D

Эксперименты с нулевой температурой.

При проверке некоторой гипотезы столкнулся с очень странным артефактом: у подозрительно многих моделей возникают сложности с ответом на вопрос про типы столовых приборов. Модели постарше, такие как mistral-tiny, рассказывают про шприцы для лимонада (?), зонтики (??) и тёрки для соусов (???). С небольшими нерусскоязычными моделями поновее тоже не всё гладко: llama-3.1-8b-instruct придумывает крахмалистые и кислотные ножи для резки картофеля и апельсинов соответственно — я даже загуглил, вдруг я чего-то не знаю о кулинарии, но нет, это галлюцинация. Понятно, что эти модели не обучались как мультиязычные и не имеют поддержки русского языка, но всё равно, галлюцинации в такой простой теме видеть довольно неожиданно — промпт то простой, не требующий от модели никаких особенных узкоспециализированных знаний. Да и потом, на вопросы про типы одежды, например, все они отвечают вполне сносно. А что у адаптированных под русский язык моделей? При стандартных параметрах семплирования в боте сайги у них тоже возникают проблемы: новые Вихри (и vikhr-nemo-12b, и vikhr-l31-8b) начинают придумывать какие-то галетные кольца, восточные суповые ложки с ручками для "еды супов без залива в тарелку" (???) и трапециевидные вилки, а у сайги-tlite откуда то вылезают молотки для перца (видимо, имелись в виду мельницы) и сольницы (солонки?). Причём у оригинальных моделей всё хорошо: tlite генерит идеальный текст, а mistral nemo вставляет в ответ один токен по английски, но сам текст откровенного бреда не имеет. У гигачата и яндексгпт тоже всё нормально — никаких особенных проблем с описанием таксономии вилок у них не наблюдается, также как и у моделей побольше типа llama-3.1-70b, mistral-large-2, mixtral-8x7b или разных коммандеров. Я решил провести дополнительный эксперимент над Вихрями: задать им вопрос про посуду, который был в обучающем сете и попробовать воспроизвести ответ из датасета. На удивление, vikhr-l31-8b с нулевой температурой не просто не смогла избавиться от странных предметов домашней утвари вроде "песка для чистки посуды", но и зациклилась, уйдя в бесконечное перечисление средств кухонной гигиены. vikhr-nemo-12b справилась нормально, но всё ещё не очень похоже на то, что было в обучающем сете. Само качество текста вопросов почти не вызывает — один раз модель перепутала падеж и один раз придумала "сковороду-вегетарианку", что указывает на низкую уверенность модели в том, что она пишет, но текст в целом был вполне приемлемым. С другой стороны, если спросить вот этот вопрос, то vikhr-l31-8b воспроизведёт информацию из обучающего сета практически без изменений, а vikhr-nemo-12b будет добавлять забавные детали и писать, в среднем, более длинно. В чём же причина таких галлюцинаций? А чёрт его знает. Возможно, это артефакт preference tuning'а — может быть в сетах было мало информации про кухонную утварь, а так как модель оптимизируется в сторону более живого и креативного рассказа, появляются сковороды-вегетарианки и кислотные ножи из вархаммера. А может быть и нет — всё таки вихреллама смогла вспомнить текст второго промпта. Если интересно, можете тоже потыкаться сами, вот промпт: Расскажи мне, какие бывают виды столовых принадлежностей.

До дедлайна на ARR 17 часов...

Урааа, метрики появились. Гигачат про (на английском) хуже, чем qwen-2-7b, лайт хуже, чем qwen-2.5-3b. Вполне возможно, китайцы учились на тесте, да, но мой личный опыт общения с квеном примерно подтверждает метрики. ¯\_(ツ)_/¯ https://developers.sber.ru/docs/ru/gigachat/models/updates?utm_campaign=gigachat_api20241004&utm_source=email&utm_medium=owned&utm_content=button

Ну и как же спасти российские ллм? Ответ прост: делать русскоязычные бенчмарки. Причём не бенчмарки типа пинг-понга (идея которого мне нравится, но я не считаю его очень полезным для моих юзкейсов**), арены (где результат модели всё ещё зависит от формата ответа, а сложность для моделей зависит от сложности запросов юзеров), или сбса, который можно собрать нерепрезентативно, а те, где качество модели можно замерить чётко и без вариаций. Например, мой любимый ifeval, хоть и имеет аналог для русского языка, я ни разу не встречал его в замерах качества моделей***. Если таких verifiable бенчей будет больше и если они станут industry standard, если модели начнут на них замерять и сравнивать, если у нас появится надёжный и репрезентативный инструмент для оценки качества модели — то врать начальству (или самому себе!) станет значительно сложнее. Халявщиков уволят, оставшимся выпишут целительных пенделей, а мы чётко поймём, насколько вихри, сайги, гигачаты и ягпт лучше или хуже друг друга, чатгпт или опенсорсных аналогов и получим значительно более качественные модели. *Этой статье уже довольно много времени, с тех пор гигачат обновили и он стал чуточку лучше, but not really. Я смотрел внутреннюю презентацию с анонсом, описанные в этом абзаце проблемы новой версии гигачата ещё более справедливы, чем ранее, тем более, что сравнивались они уже не с 3.5, а с gpt4-turbo. То, что они стыдливо скрывают значения метрик лишь будет подтверждением моих слов. **На пинг-понге в последнее время в топе закрепились модели, обученные с помощью simpio — на моих задачах такие модели становятся хуже оригинальных, потому что мне важно следование инструкциям и качество ответа, а не форма. Вполне возможно, что для оценки качества рп бенч подходит, но имхо, гораздо полезнее было бы замерить, например, tool call, следование инструкциям, написание и правку кода и reasoning. ***Не так давно появилась вторая версия меры, где пофиксили много ошибок из первой версии — но там до сих пор почему-то не приняли на замеры ни сайгу, ни вихрь, так что сравниться в качестве моделей на этом бенче, к сожалению, не получится. Это шаг в правильном направлении, надеюсь, что авторы упростят процесс подачи заявок и бенч не умрёт.

Почему чатгпт не могли обойти целый год или как спасти российские ллм На берегу скажу, что в этом посте нет ничего полезного, это такой отчаявшийся крик в пустоту. 13 марта 2023 года OpenAI представили gpt4. Её фишкой было количество и качество данных, огромный размер модели и талант инженеров и исследователей, которые смогли заставить всё работать. Почти сразу стало понятно, что штука очень полезная, в ближайшем будущем прорывная и что надо закупать карточки и пилить аналог. Ответом на gpt4 стали бесконечные палмы и гемини от Гугла, клоды от антропика, лламы от меты, мистрали от мистраля и, конечно же, гигачаты и яндексгпт от наших коллег из Сбера и Яндекса, соответственно. На обучение и ресерч были потрачены миллионы человекочасов, миллиарды долларов и триллионы гпучасов -- и все с одной целью: обойти gpt4 и стать новой сотой, подмяв под себя как можно большую долю рынка до того, как он устаканится. Аналоги gpt4 начали появляться примерно с марта 2024 (то есть, спустя год после запуска модели). Claude 3 Opus страшно дорогой и медленный, но во многих задачах он работает сильно лучше gpt4. Прочие компании подтянулись чуть позже — летом гугл выпустил в арену gemini pro 1.5 experimental, которая обошла и опус, и gpt4o, мета выпустила llama-3.1-405b, которая была приблизительно наравне с gpt4o во многих задачах, а Mistral AI выпустили Mistral Large, которую я не тыкал, но про которую говорят, что она тоже хороша. Так причём тут спасение российского нлп и почему выход аналогов gpt4 так затянулся? Ведь казалось бы, компании уровня Google или Сбера/Яндекса уж точно имеют деньги, чтобы купить карточек, разметить данных и поставить учиться модель, которая будет обходить чатгпт, почему этого не произошло? Ответ простой — карьеризм и самообман. Над гигачатом в нашей среде принято либо подтрунивать, либо недоумевать по поводу его качества, поскольку в лидербордах он занимает последние места, а руководство делает очень странные заявления о том, что они на сбс обогнали ChatGPT*. И ведь эти заявления, скорее всего, истинные — на их воронках. Я вполне верю, что если подобрать правильные промпты, то гигачат будет наравне или даже обходить gpt3.5 на сбсе. Вопрос только в репрезентативности таких воронок — потому что на вопрос про свиные крылышки он пишет много не очень хорошего питоновского кода, не выполняя заданные инструкции. Наверняка я этого не знаю, но у меня есть подозрение, что у яндекса проблемы похожего характера — потому что они точно так же побеждают гпт-3.5 и другие не очень новые модели на сбс и своих бенчмарках, но при личном использовании я не чувствую, что это viable альтернатива даже опенсорсным моделям с HF Chat. Зачем им так врать? Очень просто — начальство сказало "надо сделать российский чатгпт", так что приходится рожать кривые воронки и побеждать на них чатгпт. Начальство довольно метриками, можно продолжать работать дальше. Получается порочный круг: они врут начальству о том, что всё хорошо, начальство гладит их по головке, мотивируя продолжать в том же духе, а инженеры продолжают делать модели, которые на flawed воронках показывают хорошие результаты. А ведь это вредит итоговому качеству модели — я слышал страшные истории о том, что в команде гиги отказались от preference tuning, потому что на сбс качество падало, то есть начальству такое продать будет сложнее. И авторы гигачата, и авторы YaGPT ставят себе задачей повторить успех OpenAI, замеряясь на (вероятно) flawed бенчмарках, которые недостаточно репрезентативны. Я подозреваю, что эта проблема ещё более актуальна в больших западных компаниях типа меты или гугла, с поправкой на то, что англоязычные модели делать проще.

Юдковский напрягся. Взято с: https://www.reddit.com/r/OpenAI/s/T37N551FZT

Качество на MTEB до и после контрастив обучения.

LLM2Vec: Large Language Models Are Secretly Powerful Text Encoders Знаете мем про "You know what? Screw you, *unkits your kat*"? Авторы статьи повторили буквально этот мем и сказали "Screw you, *unmasks your masked attention*" и сделали бочку энкодер из декодера. Их алгоритм до безобразия прост: берём претрейн, заменяем треугольную маску аттеншна на матрицу с единичками, хилим чутка на MLM (который они называют как то по другому, но суть та же), доучиваем на контрастиве -- и энкодер готов. Причем учить надо совсем чуть чуть и не на каких-то уникальных данных -- авторам хватило 1000 шагов на Викитексте с батчом 32, чтобы получить рабочую модель. Для 7б это всего лишь примерно 100 минут на одной А100. К слову, вопрос, а как они уместили 7б на А100 -- это Лора, галор, восьмибитный адамв? Подозрительная история. Контрастив учится дольше -- примерно 3 часа, но количество данных, пролитое через модель, тоже не слишком большое -- 1000 шагов с бс 128. Авторы проверили идею на четырёх моделях: tinyllama, Mistral 7b, llama-2-7b и meta-llama-3-8b. И если ламы вели себя как полагается, то мистраль, внезапно, доучивать на MLM не пришлось, то есть он сразу, после анмаскинга работает нормально и даёт вменяемые эмбеддинги. Авторы предполагают, что этот феномен связан с тем, что мистраль какое-то время учили на какой-то таске с двунаправленным аттеншном -- например, на PrefixLM. С другой стороны, в репорте мистраля этого не было, только описание sliding window attention, которое я тогда не понял, но как будто бы оно все равно не двунаправленное. Кто врёт -- решительно непонятно, но если авторы статьи правы, то мы не только из декодеров можем делать энкодеры, но и из энкодеров декодеры! Итоговые модели после контрастива заняли высокие места на MTEB, так что подход оказался вполне себе viable. Учитывая размеры нынешних лидеров мтеба и простоту создания подобных моделей, я удивлен, что никто ещё не занял зияющую нишу и не сделал эмбеддер на основе какой-нибудь небольшой кодинговой сети типа qwen-2.5-1.5b-coder. Множество людей, пилящих раг на коде, сказали бы спасибо. Paper: https://arxiv.org/abs/2404.05961 Code: https://github.com/McGill-NLP/llm2vec Page: https://mcgill-nlp.github.io/llm2vec/

Метрики.

Уверенность моделей в ответах на вопросы. Степень уверенности написана синим.

Chain-of-Thought Reasoning Without Prompting Одна из моих любимых областей -- это классический донейронный CV, потому что все там построено на максимально простых идеях, которые можно комбинировать и получать хорошие результаты. Сегодняшняя статья как раз из подобного, идея в ней очень простая, но неплохо улучшающая метрики. Чтобы сгенерировать текст из логитов, мы можем применять разные стратегии декодирования. Самый простой способ -- использовать жадную генерацию. в этом случае мы просто берём самый вероятный из предсказанных токенов и идём дальше. Есть вариант сложнее, beam search -- мы берём top-k самых вероятных токенов, генерируем от каждого ещё по top-k самых вероятных токенов, и, повторяя такое несколько раз, мы строим дерево генераций, из которого мы выбираем самую вероятную ветвь. Такой подход позволяет обойти ситуацию, когда первый токен (тот, что имеет наибольшую вероятность) ведёт к менее вероятным последующим токенам и модель "застревает" в такой плохой генерации. Авторы сегодняшней статьи провели анализ логитов при генерации Chain of Thought цепочек и выяснили, что при декодировании финального ответа гораздо больше уверена в выборе токенов, чем при декодировании цепочек без CoT. Уверенность в выборе токена они определяют через разность между двумя самыми вероятными токенами в top-k, то есть чем выше разность, тем больше модель уверена в том, что текст генерится правильный. То есть, если начать жадное декодирование с 10 разных начальных токенов, а потом выбирать те цепочки, где уверенность модели в финальном ответе будет выше, то с очень высокой вероятностью этот ответ будет CoT. Чтобы понять, где начинается ответ модели, они предлагают два варианта. Первый вариант -- просто выбирать последнее число в ответе (для GSM8k это вполне рабочая схема). Второй вариант -- приклеивать после ответа модели фразу "So, the final answer is", и последующие токены считать ответом. Ну и самое интересное -- метрики. На GSM8k, например, скор PaLM-2 L вырос аж на 28%, в сравнении с greedy decoding и на 21% по сравнению с бимсерчем с n_beams=10 и с ранжированием по нормализованным по длине логпробам. В режиме QA трюк тоже работает, модели не важно, есть ли фьюшот, она все равно начинает генерить CoT. Поверх этого можно добавить ещё и промпт CoT и метрики повысятся ещё сильнее. Paper: https://arxiv.org/abs/2402.10200

Придумал забавный промпт, с которым справляются только очень мощные модели: У меня есть текст. Достань из него все сущности (числа, имена, события, предметы) и верни JSON со следующей схемой: class Number: number: int | float # the number class Name: name: str # name of the person gender: str # male, female or not applicable class Event: subject: str # what is the subject of the event event: str # what is the event class Entity: entity: str # entity name additional_info: str | None # additional info about the entity class JSONSchema: item: list[Number | Name | Event | Entity] Текст, который надо обработать: Есть три свиных крылышка, 9.8, 9.11, а так же А и Б, сидящие на трубе. Маша выпила стакан газировки со смородиной, Петя уронил учебники, А упала, Б пропала. Какое число из перечисленных самое большое? Прежде чем отвечать, выпиши все числа, имена и события, проанализируй, к какому классу они относятся. Не добавляй дополнительных полей к json кроме тех, что указаны в схеме. Работает на опусе, 3.5 соннете, о1 превью (не мини), 4o-latest и, внезапно, command-r-plus. Не работает на 4o mini, o1 mini, qwen-2.5-72b, llama-3.1-70b, mixtral-8x7b, mistral-7b, phi-3-mini, новый vikhr-nemo и, ожидаемо, гигачат, он вообще не понял чё от него хотели. Надо потестить другие модели и перевести промпт на другие языки, потому что как будто бы он очень хорошо показывает одновременно понимание языка, умение следовать инструкциям (некоторые модели выполняют инструкцию, но зачем то начинают выполнять задание из текста) и умение в structured output.