Natural Language Processing *

В марте я советовал Whisper Large v3 для голосовой диктовки и ошибался дважды: в методе (выбирал модель «на ощупь») и в самой модели.

Пересобрал всё по-научному: 23 ASR-модели в 60+ конфигурациях, больше 100 000 прогонов на русско-английском IT-корпусе, 120+ часов инференса на одной RTX 5070 Ti. Мерил не только WER, но и сохранение английских терминов латиницей и пунктуацию.

Внутри — полный лидерборд, разбор каждого сюрприза, вклад тюнинга и промптов, cloud-против-open по деньгам и инструкция, как поставить победителя за 10 минут.

Когда я выпускал Russian Spelling Dictionary 1.0.1, задача была довольно узкой: собрать пригодный для повседневной работы русский орфографический словарь и доставить его пользователю. В предыдущей статье я рассказывал, как появился первый выпуск. Повторять тот рассказ не буду.

Сейчас интереснее посмотреть на весь путь от 1.0.1 до 1.0.5. За четыре выпуска словарь вырос с 179 956 до 550 291 записи. Для CSpell теперь подготовлено 2 342 788 словоформ. Появились отдельные пакеты для Mozilla, LibreOffice и других программ с поддержкой Hunspell. Наконец, в 1.0.5 удалось заметно улучшить подсказки, не изменив распознавание слов.

Поэтому «экспансия» в заголовке — не только про размер. Словарь расширился сразу в трёх направлениях: по составу, по качеству проверки и по числу программ, в которых его можно использовать.

- Пробовали сделать цифрового сотрудника на LLM?
- У вас получилось?
- Долго старались?
- Насколько он качественный?
- Сколько он стоит в обслуживании?
Очень много вопросов возникает к технологии ведения диалогов нейросетями.

Локальная модель может уверенно отвечать на общие вопросы и так же уверенно ошибаться в вашем домене.

В статье сравнили на одной задаче промпт с контекстом, RAG и дообучение методом QLoRA, замерили результат на 30 вопросах и разобрали, где каждый подход действительно полезен, а где создаёт новый класс проблем.

TL;DR

Железо: 2× NVIDIA DGX Spark (GB10, SM121), 128 GB unified номинально и около 122 GiB видимых системе на ноду, QSFP 200G / RoCEv2, TP=2, драйвер 580.159.03.

Основную часть расхождения объяснила смена runtime‑образа. Переход со сборки на базе vLLM 0.21.1 на образ с 0.25.2 дал около +22% на том же чекпоинте. Конкретный коммит или компонент я не изолировал: поменялся весь пакет.

Механика неочевидная: новый образ снизил расчётную частоту verification‑шагов примерно на 17%, но поднял число выходных токенов за шаг с 3.27 до 4.80.

Главная находка в конфиге: --moe-backend flashinfer_b12x не выбирается режимом auto. Явное включение дало +13.3% по среднему пяти прогонов на card‑like профиле (59.7 против 67.6) и +16.6% по медиане.

B12X работает иначе: поднимает SSE‑derived частоту verification‑шагов на 16–18%, при этом выходные токены за шаг снижаются примерно на 2.5% в обоих профилях. Итоговый прирост клиентской decode‑метрики составил 13.3–14.6% по средним и 15.6–16.6% по медианам.

Итог: 67.6 tok/s на одиночном запросе, 260 tok/s суммарно на 12 параллельных запросов.

Отрицательные результаты, погрешности и границы применимости вынесены в отдельные разделы.

Всем привет. В декабре по всем AI-каналам пролетел лайфхак, который звучал как развод: продублируй свой запрос к нейросети, буквально Ctrl+C, Ctrl+V в одном сообщении, и точность вырастет. В пересказах фигурировали «+76%» и ссылка на Google Research, что придавало всей этой истории солидности. Трюк выглядел как-то настораживающе и при том вроде не сложным для проверки. Короче, я потратил $1.48, прогнал 3360 запросов и теперь знаю ответ. Он оказался интереснее, чем «работает || не работает».

В прошлый раз у нас получилось покрыть 20 самых популярных языков России и СНГ с рядом оговорок. Но основным недостатком моделей было то, что значительная группа языков была вообще не покрыта, в основном многочисленные языки Кавказа, Дагестана и Чечни. С лингвистической точки зрения из популярных крупных языковых групп были не покрыты абхазо-адыгские и нахско-дагестанские языки.

Можно ли описать интерпретацию Таро как задачу поиска лучшего смыслового пути? Разбираю учебную вероятностную модель: от локального greedy к точному Viterbi, beam search, фактор-графам, CRF и LLM reranking. На контрпримере показываю, почему лучший локальный выбор проигрывает глобальному, а также где заканчивается поиск структуры и начинается генерация текста.

Я долго думал, как мог бы выглядеть идеальный универсальный агент. Такой Jarvis из «Железного человека». И довольно быстро понял: фиг я смогу такого сделать. Зато можно попробовать дать агенту возможность придумать и построить себя самого в автономном цикле эволюции.

Так появился Уроборос: кривой косой агентный луп на чистом Python с доступом к git, правом переписывать свой рантайм, безопасным рестартом на новой версии и откатом к прошлой, если всё сломалось. Я поселил первую версию в Google Colab, чтобы он не убил мне комп самоэволюцией (сервера Google не жалко, у них хорошая изоляция), дал бюджет и автономность, и понеслось.

С тех пор прошло несколько месяцев. Когда я последний раз рассказывал про него публично, это был ещё милый desktop‑агент, который рисовал котиков, зависал на ютюбе и менял обои. Сейчас на Terminal‑Bench 2.1, CL‑Bench и OSWorld у него SOTA результаты, а на GAIA и SWE‑Pro получается паритет с Claude Code и Codex. Сам бы я такой харнесс не придумал, а вот автономная эволюция и куча сожжённых денег на токены — да.

В этом посте: цифры и воспроизводимость, несколько неловких историй из аудита трейсов, коротко про архитектуру, и почему я теперь почти всё делаю через него.

Коротко, о чём речь, — для тех, кто пришёл по слову «Яндекс» и предыстории не знает. Когда ИИ-ассистент помогает чинить баг, самое ценное — не сочинить ответ с нуля, а вспомнить: похожий симптом уже разбирали, вот issue, вот причина, вот PR с фиксом. Вопрос ровно один — достаёт ли ассистент это прошлое решение из памяти. Мы это померили на своём корпусе тикетов и получили две цифры. Обычный семантический поиск (по смыслу слов) находит нужный прошлый фикс по симптому лишь в 38% случаев; обход явных причинных связей «issue → закрывший его PR» — в 87%. То есть сходство слов упирается в треть, а явные связи поднимают recall в разы.

Ио — это LLM-бот для Telegram-чатов. Он умеет отвечать на сообщения пользователей, распознавать изображения и голосовые сообщения, учитывать текущий тред, историю переписки и информацию о пользователе.

Расскажу, как я пилил его несколько лет, пытался научить помнить пользователей, разбирался с RAG и векторными базами и в итоге получил систему, которая действительно работает.

За последние пару месяцев мне трижды присылали коммерческое предложение с обещанием «вывести бренд в топ ответов ChatGPT». Один раз — с конкретной цифрой: позиция № 1 всего за 30 дней. Такие обещания я проверяю руками: беру API OpenAI, ставлю temperature = 0 и фиксированный seed, отправляю один и тот же промпт дважды подряд — и получаю разный текст. Я работаю с AI‑видимостью брендов и знаю механику генерации ответа изнутри, поэтому дальше разберу, почему гарантия здесь физически невыполнима и что можно измерить и продавать вместо неё.

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

Я, Александр, автор телеграм‑канала «Shulepov Code», поговорил с Василием Рязановым — кандидатом физико‑математических наук, руководителем команды Data Science и автором блога об искусственном интеллекте на YouTube. В этом выпуске мы разбираем, почему нейросетям уже около 80 лет, как устроены языковые модели, какие задачи ИИ решает в бизнесе и почему «заработать миллион одним промптом» всё ещё нельзя. Василий делится практическим опытом работы с нейросетями и объясняет, где заканчивается хайп и начинается реальная польза.

Хабр, привет! Меня зовут Дмитрий Тарасов, я исследователь в лаборатории FusionBrain AIRI. Мы недавно свозили нашу свежую работу — “Progressive Cramming: Reliable Token Compression and What It Reveals” —на ICML 2026, и здесь я хочу рассказать, о чём она.

Начнём с почти магического факта. Год назад в замечательной работе “Cramming 1568 Tokens into a Single Vector and Back Again” моего коллеги по AIRI Юры Куратова и его команды было показано, что в один‑единственный входной эмбеддинг замороженной LLM можно «упаковать» до 1568 токенов текста так, что модель потом слово в слово его восстанавливает. Полторы тысячи токенов — это несколько абзацев — в одном векторе размерности несколько тысяч, невероятная плотность памяти. Разбор этой статьи уже был на хабре.

У нас этот результат вызвал не только восторг, но и подозрение. Одно дело — восстановить текст, и совсем другое — понимать его. Что, если «идеальная» реконструкция на самом деле не хранит смысл? В нашей статье мы:

– покажем, что стандартный протокол token cramming скрывает катастрофические провалы, и предложим более честную процедуру — progressive cramming;

– исследуем траектории оптимизации сжатых последовательностей;

– и, самое интересное, покажем, что идеальная реконструкция не сохраняет способность модели рассуждать — а причина этого сидит в первых слоях трансформера.

Поехали.

Привет, Хабр! Меня зовут Владимир, и это пятая часть цикла статей по написанию и обучению небольшой decoder-only LLM с нуля. В прошлых частях мы собрали и обучили модель LinguaLaboratoriumMechanicus — миниатюрную GPT-like LLM во вселенной Warhammer 40K. В этой части упакуем её в формат Hugging Face: сделаем конфиг и обёртку под transformers, сохраним и зальём модель на Hub.

Вектор диалога с LLM плывёт каждый ход, и к концу разговора персонаж уже не тот. Рассказываю, как я это чиню в своём движке: классификатор выбирает «тег реакции» через constrained decoding, числовые оси отношений двигаются по таблице, а медленные «стадии» задают тон. Всё объяснимо — каждый сдвиг привязан к числам, которые видно в логе.

Нашёл модель в 8 раз дешевле. Она начала писать иероглифы в русских новостях

У меня новостной бот, и каждая новость в нём проходит через LLM: категория, перевод, тон, разбор. Выходит около 936 вызовов в сутки, и в какой-то момент мне захотелось платить за это меньше.

Я перебрал все бесплатные модели OpenRouter на живых промптах, нашёл платную в 8 раз дешевле текущей, обрадовался и выкатил в прод.

Через час в ленте появился заголовок: «Как не，让智能手机 перегревать: советы в жару».

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

Так на свет и появился репозиторий rpa-skills, изначально в нём была сборная солянка директорий скилов, которые содержали в себе просто SKILL.md с оригинальными промтами внутри. Но выглядело и юзалось это решение как-то не очень удобно, да и масштабировать захотелось, так что я решился пойти на немыслемое, почитать документацию о том, как правильно собирать скилы и маркетплейсы, о чём и расскажу сегодня вам.

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

RAG уже стал стандартным способом научить LLM работать с собственными документами без дорогостоящего дообучения. Но за кажущейся простотой скрывается множество практических вопросов: как разбить документы на чанки, где хранить эмбеддинги, как организовать быстрый семантический поиск и какую модель использовать на каждом этапе.

В статье соберем полностью локальную RAG-систему на Go, PostgreSQL и Ollama без облачных API и сторонних сервисов. Разберем весь путь — от индексации документов до получения ответа LLM на основе найденного контекста.

Привет, Хабр! Меня зовут Владимир, и это четвёртая часть цикла статей по написанию и обучению небольшой decoder-only LLM с нуля.

Данная статья целиком посвящена этапу SFT - дообучению на датасете “вопрос - ответ”, чтобы модель могла вести диалог с пользователем, а не просто дописывать за него фразы.