"Прилобот" в Telegram 👀 Имеется ввиду формат бота и приложения в одном флаконе. Мне кажется, что у Telegram, осознанно или нет, получился хороший продукт, который идеально подходит под текущее время бурного развития LLM. Сам формат, конечно, уже давно существует еще с момента релиза Mini Apps в 2022 году, но именно сейчас когда LLM сильно поумнели, встроились в реальные процессы разных бизнесов, появился MCP и прочие стандартные этапы развития технологии и ее внедрения в реальный мир - идеальное время. Мы неделю назад обсуждали с командой банальную историю - добавление CRM в Mini Apps Builder. Честно говоря, я сначала скептически отнесся к этой идее по причинам: 1. Это большой отдельный продукт. 2. Наша ЦА (начинающий бизнес в сфере продаж товаров/услуг) это не будет использовать, т.к. в реальности даже средние и большие компании ни хера не делают вменяемого с этим. Вы можете не верить мне, но глянуть недавний пост у фаундера amoCRM в Telegram. Но, немного покрутив сценарии в голове, появилась гипотеза: а что если значительная часть этого процесса будет полностью автоматической? 0. Клиент должен разок запустить Telegram Mini App сначала, без этого магии вроде не будет. В этот момент он автоматически попадает в нашу CRM, т.к. он "всегда авторизован" в Telegram. 1. Мы подгружаем к LLM дополнительно базу знаний бизнеса (файлы, ссылки на разные файлы в разных облаках, куски текстов и т.д, пока неважно). 2. Далее клиент что-то смотрит в приложении: товар, услугу, описание эвента, конференции, скидок и прочего (зависит от шаблона приложения). Возможно, делает несколько заказов или какие-то другие действия в приложении. 3. У него возникает какой-то вопрос, он этому же приложению уже в формате чата пишет этот вопрос. LLM пытается ответить сама, если не получается, то пинает сотрудника, чтобы подключился. 4. Периодически LLM просматривает чаты и сама актуализирует контекст по каждому клиенту внутри CRM (проверяя заодно наш бэк - заказы, добавления в избранное, открытые приложения и т.д.). Тут, конечно, много вопросов по финальному исполнению: как часто обновлять контекст, как синхронизировать его с контекстом от менеджера, как удобно и желательно автоматически обновлять базу знаний, отдельный прайсинг для лимитов в LLM и т.д. Но это уже все стандартный процесс разработки и тюнинга продукта. Понятно, что если вы не вчера открылись, то у вас не все сидят в Telegram, а разбросаны по разным каналам. Но именно в формате старта своего проекта в рамках Telegram, кажется, что получается очень хорошая история. Накидывайте критики! 😈 😀 Mini Apps Builder 💩 Говно в продуктах #llm #bots #miniapps #telegram

Open AI очень хочет не опоздать к IPO - кричит что AGI почтиготов. https://t.me/Futuris/4715 Обещственность тут же прогнала не подобранные бенчмарки, а свои тесты - нет, примерно то же что было, то и осталось. https://t.me/Futuris/4715 Я же по этому поводу призадумался. Прогресс метода Attention is all you need впечатляющ, особенно когда в нашем распоряжении все тексты мира и вычислительная мощь в несколько процентов энергопотребления мира же. Но AGI статистическим методом перемножения зиллиардов матриц не построишь. Почему? А потому, что интеллект должен не только подражать виденному и слышанному ранее, но и создавать правила и следовать им. И не только правила вида "Если А - делай Б, если нет - делай В", но и такие вроде б элементарные вещи, как "Найди книгу А, открой на странице Б и прочти абзац В слово в слово и буква в букву". Что внутри нейросети нет представления чисел как чисел - это я писал ранее, и эта проблема тоже конструктивная и в общем, без колоссальных костылей не решаемая. Нейронки сейчас - как школьники-недоучки. Они не ЗНАЮТ. Они УГАДЫВАЮТ. И угадывают, в целом очень хорошо... но кажется, уже многие, если не все, хоть раз да сталкивались с тем, когда ты употребляешь слово в менее популярном значении, нейронка уверенно говорит "Вы, конечно, имели в виду, что %самое популярное значение%" и отвечает на вопрос, который ей не задавали. Получить дословную цитату, кстати, тоже тем сложнее, чем текст более редок - а уж если есть что-то подобное в более популярном тексте, из этой колеи вырваться не всегда реально. Иными словами, должны быть промпты, которые всегда исполняются одинаково. Не примерно одинаково, а абсолютно одинаково. Вот тогда и можно будет начать движение к AGI. А пока это маркетинговые вопли, которые живут все меньше и меньше.

В карточке тоже есть интересные метрики, но хотел выделить вот это: «Мы оцениваем фактологическую точность на обезличенных диалогах из ChatGPT, которые пользователи наших предыдущих моделей отметили как содержащие фактические ошибки. Эти примеры специально отобраны для выявления случаев, наиболее подверженных галлюцинациям, поэтому ожидается, что их абсолютная частота ошибок будет намного выше реального уровня ошибок в продакшене. Эту метрику не следует интерпретировать как частоту галлюцинаций, наблюдаемую при реальной эксплуатации. Мы используем две метрики: (1) допускает ли модель вообще какую-либо ошибку (частота галлюцинаций на уровне ответа) и (2) воспроизводит ли модель ту самую конкретную ошибку, на которую указал пользователь. Мы обнаружили, что Astra допускает существенно меньше фактических ошибок, чем GPT-5.6 Sol, и с гораздо меньшей вероятностью воспроизводит галлюцинации, о которых сообщали пользователи. Эти улучшения особенно ярко выражены при очень низких настройках длины рассуждений»

🔥 Perplexity разогнала локальный запуск LLM на Apple Silicon Компания сделала собственный движок Lily специально под Mac и Qwen3.6-35B-A3B без PyTorch и MLX в цепочке выполнения. На MacBook Pro с M5 Max и 128 ГБ unified memory: - prefill: 5749 ток/с - генерация: 186,6 ток/с - в среднем prefill быстрее MLX-LM в 1,23× - decode — в 1,35× Что внутри: - runtime на Rust - собственные Metal-кернелы - MoE-routing остаётся на GPU - оптимизация отдельно под prefill и decode - KV-cache и Gated DeltaNet заточены под Apple GPU - 35B-модель ужата до 19,4 ГБ в 4-bit На длинном контексте отдельная оптимизация attention дала до +40% скорости на 128K токенов. Сам Lily Perplexity обещает скоро открыть. https://www.perplexity.ai/hub/blog/optimizing-on-device-inference-for-apple-silicon

Loop the Loopies! Сегодня обсудим статью, которая посвящена моделям Loopies, построенным на шеринге параметров между разными слоями.  Обычно у трансформерных моделей и свёрточных нейросетей отдельные параметры на каждом блоке, благодаря чему объём вычислений и число параметров масштабируются с глубиной. Это даёт гибкость — каждый блок может выполнять специфические задачи. Но при этом с ростом числа слоёв растёт и количество параметров, а значит, модель становится дороже хранить.  Выходом из этой ситуации может стать переиспользование весов по несколько раз за форвард — шеринг параметров. Так не нужно хранить много параметров, однако блок может принимать распределение данных с разной глубины, что усложняет задачу оптимизации.  Перспективность шеринга первым доказал метод ALBERT. В нём было два механизма: факторизация матрицы эмбеддингов и переиспользование одного трансформенного блока несколько раз. На этом принципе работают looped-модели — hidden state в них прогоняется R раз через один и тот же блок. Число параметров становится меньше, а количество вычислений не меняется.  Рекуррентность имеет и другие преимущества: hidden state проходит несколько шагов улучшения, эффективная глубина растёт без увеличения размера модели. В перспективе число шагов можно адаптировать под сложность запроса — если он простой, то прогонять один раз, а если сложный, то больше. Рекуррентность хорошо показывает себя на алгебраических задачах и задачах, связанных с пазлами. Однако сравнения looped-моделей с не-looped-аналогами были не совсем честными. При том же размере модели делаются R прогонов, а, следовательно, в R раза больше вычислений. Соответственно, и обучать такую модель дольше. В плане оптимальности компьюта looped-модели уступали обычным трансформерам.  Авторы серии Loopie предлагают две модели: Loopie-20B-A2B и Loopie-6B-A0.6B. Архитектурно это Qwen3. В отличие от решений прошлого, здесь не вся модель прогоняется несколько раз, а каждый слой (верхняя схема на изображении 1). В пределах одного блока активации меняются не так сильно, к тому же это проще для чекпоинтинга. Также такой метод даёт потенциально большую гибкость: можно делать разное количество проходов на каждом слое.  Подход layer-loop проще для распределённого обучения, потому что повторения слоя остаются в одном pipeline stage, а параметры градиента могут использоваться локально. В то же время model-loop требует, чтобы вычисления синхронизировались внутри всей модели а первый блок должен уметь обрабатывать один или несколько полных проходов через модель.  Претрейн состоял из двух стадий. Сперва используют датасет Nemotron-CC-v2-HQ, а дальше дообучают на более качественных данных, делая упор на синтетику, STEM, код, математические рассуждения и веб-данные. Так получается базовая Loopie. На неё делают Supervised Pre-Training (SPT). Это похоже на SFT, лосс считается только по target-токенам, однако масштаб — как у претрейна: 2Т токенов. Контекст увеличивают и обучают довольно большими батчами примерно по 128М токенов. SPT, как отмечают авторы, улучшает способность модели к рассуждению.  На RL сначала делают математику, а потом программирование. Используют GSPO, ассиметричный клиппинг и динамическую фильтрацию промптов. Роллаут увеличивают с 32К до 64К.  По бенчам Loopie-20B примерно сопоставима с моделями вроде Qwen3, Nemotron 3 Nano и GPT-OSS (изображение 2). Казалось бы, не слишком большое достижение для 2026 года, однако стоит помнить, что у Loopie намного меньше параметров. Loopie-6B в своей «весовой категории» также показывает себя достойно — особенно в задачах, связанных с математикой (изображение 3). Разбор подготовил ❣ Денис Кузнеделев Душный NLP

Ебобаная привычка после 10-и минутных видосов писать кратко, емко и самое главное в быстром темпе, что б вы, СДВГшники, не заскучали 😄 Крч, я каким то хреном умудрился в первые 40 минут впихнуть следующий список тем: 1. LLM 2. Промпт 3. Обучение модели и инференс как разные процессы 4. Пост-тренировка в формате «инструкция → вывод» 5. Веса / параметры модели 6. Предсказание следующего токена 7. Токены и токенизатор 8. Особенности токенизации латиницы и кириллицы 9. Число параметров 10. Dense-модели 11. Эмерджентные свойства 12. Типы данных и точность весов (в т.ч. 16-бит) 13. Оценка потребления памяти по числу параметров 14. Квантизация 15. Floating point, мантисса и экспонента 16. FP8 и низкобитные форматы 17. Аппаратное ускорение низкобитных вычислений 18. Влияние квантизации на качество модели 19. Запуск квантованных моделей на CPU (в т.ч. SIMD) 20. Слои модели 21. Статическая квантизация по шаблонам 22. Защита отдельных слоев при сжатии (эмбеддинги, нормализация, ключевые блоки) 23. Адаптивная квантизация слоев с разной битностью 24. iMatrix и i-кванты 25. QAT (Quantization-Aware Training) 26. Сверхнизкобитная квантизация 27. Формат GGUF 28. Дистилляция (Distilled-модели) 29. Прунинг 30. Fine-tuning 31. LoRA и QLoRA 32. MoE (Mixture of Experts) 33. Роутер / маршрутизатор экспертов 34. Активные параметры 35. REAP 36. Спекулятивное декодирование 37. MTP (Multi-Token Prediction) 38. Reasoning 39. Мультимодальность 40. Vision 41. Speech-to-Text 42. Контекстное окно 43. Attention 44. Квадратичная сложность Attention 45. KV-кэш 46. Prefill / обработка промпта 47. Flash Attention 48. Квантизация KV-кэша 49. Paged Attention 50. Lost in the Middle Теперь думайте, а чё же там происходит дальше 😄

MM Harness [1/x] Уже немало времени посвятил изучению мультимодальных харнесов. Если раньше, когда занимался моделями, я думал что беды существуют только на уровне модели, то увы, я прям очень сильно ошибался: сложность решений здесь растёт по экспоненте — и примерно по той же кривой растёт желание разработчиков (и иногда моё) забить на эту мультимодальность. Ниже — список вопросов, на которые стоит ответить до того, как вы начнёте проектировать мультимодальную систему (ну или по пути, как пойдёт). Давайте сейчас будем считать модели токенодробилками, а потому не будем углубляться в их строение, а рассмотрим систему вокруг. Допустим, мы делаем какого-нибудь агента, с которым ещё и можем общаться в формате диалога. Интерфейс Проблемы начинаются уже в тот момент, когда пользователь прикладывает картинку. 1. Загружаем оригинал или жмём? А если пользователь сидит на мобильном интернете и хочет экономить трафик? 2. Сохраняем метаданные EXIF или дропаем? Разные библиотеки по-разному обрабатывают, например, ориентацию изображения, поэтому об этом лучше подумать сразу. 3. Поддерживаем несколько изображений в одном сообщении? Если да, все остальные проблемы множатся. Контекстный менеджер Допустим, картинки всё-таки долетели до бэкенда и попали в контекстный менеджер. 1. Ресайзим ли мы их? До какого размера? Есть ли замеры влияния на качество? Чем больше изображение, тем больше токенов оно может занять — хотя тут всё зависит от препроцессинга конкретной модели. 2. Сколько картинок держим в контексте? Можно очень просто забить весь контекст изображениями! 3. Что делаем с картинками, которые в контекст уже не помещаются? Оставляем ли хотя бы описание или идентификатор, чтобы агент мог к ним вернуться? Модель и инструменты Дальше изображения уходят в модель. При этом модель может вызывать тулы, которые тоже возвращают изображения. 1. Как кладём эти картинки в контекст? Передаём модели сами изображения или только подпись "тул вернул такие-то картинки"? Другими словами, должна ли модель посмотреть на картинки, которые вернул условный поиск? 2. А в сами тулы мы какую картинку подаём? Ту самую пожатую и с ресайзом? Или какую-то другую? 3. А если передаём модели сами картинки, как поступаем, когда контекст уже ими забит? И это только базовые вопросы доставки и управления контекстом, где правильного решения нет — есть только ваше, скорее всего компромиссное. И всё это добавляется к уже известным сложностям текстовых агентов. Мы ещё не дошли до хранения, кеширования, безопасности и различных UI-фич. Продолжение следует... P.S. Календарь перевернули?)