Natural Language Processing *

В прошлой статье серии мы сжимали эмбеддинги и замеряли, насколько изменится выдача относительно полного fp32-поиска. Там это был правильный вопрос: ломает ли квантизация уже существующий retrieval.

Но у такого замера есть неприятное слепое пятно. Можно аккуратно сохранить 99% выдачи исходного эмбеддера и все равно плохо находить нужные документы на своем домене. Внешний бенчмарк, даже сильный, этого не гарантирует. BEIR как раз был создан, чтобы показать, насколько результаты retrieval меняются между разными задачами и доменами; один усредненный скор там не заменяет проверку на собственных данных.

Нужен свой eval set. И тут обычно возникает ложная развилка:

Я потратил пару недель на создание конвейера с открытым исходным кодом, который переводит книги целиком с помощью платных подписок на LLM. Поддерживаются Claude Code, Antigravity CLI и Codex. В статье описаны принципы построения конвейера для максимального качества перевода, а также тонкости по лимитам, скорости, цензуре и т.п. Проект BookTrans на GitHub.

Привет, Хабр! Результаты коллег по цеху и наши исследования позволяют сделать однозначный вывод: в 2026-м для рецепта отличной reasoning-модели уже недостаточно лишь текстовых рассуждений. Для качественных ответов на большинство вопросов пользователей нужна работа с инструментами, мультимодальные режимы рассуждений, и нередко даже такая экзотика, как рассуждения в латентных представлениях сети.

Мы рады поделиться с сообществом фреймворком для обучения рекурсивных reasoning-моделей STARM, существенно опережающих по качеству предыдущие open source-аналоги.

Наверное уже многие знают, что в силу недавно вступивших в ЕС законов, регулирующих использование ИИ, провайдеры LLM обязаны помечать ИИ-сгенерированные тексты. Та же Claude недавно обновила справочную информацию о работе своей помечалки сгенерированного ИИ контента, в том числе и текста. Но в подробности его работы почему-то вдаваться не стала, как и размещать в публичном доступе средства добавления и обнаружения этих самых вотермарок.

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

Идея Andrej Karpathy с LLM-wiki набирает сторонников. На Хабре уже было несколько публикаций (1, 2, 3), в том числе и моя про сравнение LLM-wiki и RAG-системы. Ещё больше статей я нашёл на medium.

У вас есть Claude Code? Собрать персональную википедию можно менее чем за час. А что делать, если Claude Code и ему подобные инструменты по разным причинам недоступны? Можно ли алгоритмизировать процесс и использовать «слабые» модели? На сколько получившаяся структура будет хуже и как их сравнивать? В статье попробую ответить на эти вопросы, а также расскажу как построить персональную wiki на Ollama или GPT-моделях.

Дано: стихотворение. Тема — «тщетность накопления жизненного опыта», амфибрахий, четыре строки. Заканчивается словом «тосок». Такого слова в русском языке нет. Мой оценщик поставил этому тексту техничность 1.000 — идеал.

К этому моменту я месяц жёг GPU-часы на арендной L40S, пытаясь заставить Gemma 4 писать русские стихи. У меня был план из четырёх пунктов, свежая статья с рабочим рецептом, размеченный корпус на 13 тысяч пар и собственная метрика, проверенная на Пушкине. План развалился весь, но каждый раз не в том месте, где я ждал: главный подозреваемый до последнего выглядел очевидным, а виновным оказался совсем другой персонаж.

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

Настоящие цифры, реальный loss и плохие стихи прилагаются.

Один пользователь Claude утверждает, что прогнал через модель больше миллиарда входных токенов. Другой оставил AI-агента без присмотра и насчитал около $6000 расходов. Цифры из Reddit можно оспаривать, но механизм за ними вполне реальный.

Я посмотрел, почему короткий запрос внутри длинного чата может оказаться совсем не коротким для LLM, что происходит, когда контекст разрастается до сотен тысяч токенов, зачем нужен prompt caching и почему большое контекстное окно иногда делает ответы не лучше, а хуже.

А заодно собрал несколько способов снизить расход токенов без бессмысленной охоты за каждым словом в промпте.

На NLP/LLM собеседованиях все чаще проверяют не только знание трансформеров, но и понимание того, как устроены современные GPT-like модели: почему большинство генеративных LLM используют decoder-only архитектуру, чем LLaMA отличается от ванильного Transformer, зачем нужны RoPE, RMSNorm, SwiGLU и GQA.

Почему инференс LLM дорогой и какие оптимизации помогают его ускорять: fused kernels, FlashAttention, KV-cache и PagedAttention, continuous batching, speculative decoding, квантизация и дистилляция.

Много схем и картинок, а также полный список вопросов с собесов в конце.

Когда человек спрашивает у ассистента «к кому обратиться», он получает не десять синих ссылок, а один ответ с пятью-десятью доменами внутри. Я прогнал два запроса через семь ИИ-поисковиков в один заход и сравнил, кого именно они цитируют. Общего источника не нашлось ни одного, а три модели разных разработчиков выдали дословно совпадающие списки — потому что веб-поиск им делает один и тот же плагин. Ниже — стенд, цифры и пять мест, где методика такого замера ломается.

Привет, Хабр. На связи команды «Интерпретируемый ИИ» и «Основы генеративного ИИ» AIRI и «Генеративная поэзия» SberAI. Мы занимаемся альтернативными архитектурами языковых моделей — тем, что могло бы работать вместо привычной генерации токен за токеном слева направо.

Одно из таких направлений — диффузионные языковые модели (dLLM). Диффузионные языковые модели, в отличие от обычных LLM, генерируют текст параллельно, несколько токенов за раз. Теоретически это даёт кратное ускорение. Также они не ограничены генерацией справа от контекста и могут заполнять произвольные пропуски в поданном на вход тексте.

Мы много работали с dLLM, перепробовали кучу моделей, набив на них шишек, и даже предложили свои. В результате накопилось большое понимания того, какие подходы действительно работают, а какие вызывают много вопросов касательно их воспроизводимости. Обо всём об этом рассказываем в обзоре ниже.

Все голосовые платформы решают, что человек договорил, по таймеру тишины. Я замерил, во что это выливается на живой русской речи, и получил цифру, которая меня удивила: из 1275 мс задержки перед ответом 1200 мс — это ожидание секундомера, и только 75 мс — работа самой модели.

Ниже — методика, замеры и решение, которое даёт 316 мс вместо 1200 при двух обрывах вместо тридцати восьми. Всё воспроизводимо, детектор — на правилах, без обучения и без GPU.

Голосовой ввод для Windows за ~1 секунду | Полностью локально • CPU • Open Source

Как заставить Whisper распознавать речь почти в 4 раза быстрее на обычном CPU без GPU и без облака. Разбираю архитектуру WhisperType, сужение окна энкодера, потоковую обработку аудио, оптимизацию faster-whisper и подводные камни WinAPI.

В естественном языке распространена ситуация, когда значение слова нельзя установить без контекста: «замок закрыли ключом», «замок окружён рвом».

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

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

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

Вторая статья из трёх об исследовании MiroFish, открытого стека мультиагентной симуляции общества. В первой части изложены методология исследования и находка Silent Failure. В этой части: досье вымышленной страны с восемью классами заложенного абсурда, четыре байт-идентичных прогона с разными результатами и пре-регистрированный эксперимент, который локализовал причину.

Привет, Хабр! В прошлых статьях я рассказывал про локальный переводчик с синтезом голоса на кабардинском и про то, как собрать полный NLP-стек для «финального босса лингвистики» из старых словарей. За прошедшие месяцы весь этот стек - лемматизация, POS, NER, тональность, эмбеддинги, синтез - переехал с Python/Flask на десктопе в Swift-приложение на iOS и заодно перерос сам себя: начиналось всё как синтезатор речи для одного языка, а выросло в персональную библиотеку для любого контента - книги, статьи, подкасты, видео, музыка, файлами или ссылками. Полгода на голом Swift 6, вечерами и выходными.

Приложение уже можно ставить и ломать - оно в бете, включая рабочий CarPlay. Под катом: что оно умеет, как устроено внутри и какие цифры получились на реальном железе.

Когда в системе есть узел между LLM и пользователем его скорость также важна, как и скорость самой LLM. Когда этот узел сам является моделью (и иногда даже — тоже LLM) — задача ускорения становится совсем веселой и её нужно уметь решать разными способами. В этой работе я опишу процесс ускорения guardrail‑модели — узла, которые проверяет — нет ли на входе или выходе опасного контента.

Guard стоит на входе/выходе LLM‑приложения. В статье речь про небольшую модель — чуть больше 0.5 Gb. Но она вызывается дважды за один ход диалога, и сначала пользователь ждет, пока guard проверит его запрос перед отправкой в LLM, затем — пока он проверит сгенерированный ответ перед выдачей пользователю.

Моей задачей было ускорить такую небольшую guard‑модель (Locustfile, базовые benchmark‑конфиги и инструкции по воспроизведению экспериментов в репо). Я потестила пять инструментов: TensorRT, NVIDIA Triton, vLLM, Ray Serve и отдельно — переход бэкбона на Flash DeBERTa.

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

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

Результаты годового чекапа пришли в пятницу вечером. Семь документов в личном кабинете лаборатории, в половине строк звёздочки «выше нормы» и «ниже нормы», запись к эндокринологу через две недели. Кто сдавал, тот знает этот вечер: гуглишь каждый показатель по отдельности, находишь ужасы, и нигде не написано, что все эти цифры значат вместе.

Работаю бэкендером, делаю базу знаний в Искре. Поэтому вместо поисковика открыл свой же продукт: загрузил туда все семь файлов и начал спрашивать.

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

Большие языковые модели становятся неотъемлемой частью современных информационных систем. Корпоративные помощники, RAG-приложения, AI-агенты, генерация программного кода, автоматизация документооборота – всё чаще именно LLM становятся основным интерфейсом взаимодействия пользователя с данными и сервисами компании.

Вместе с ростом популярности меняется и профиль угроз. Если ещё несколько лет назад основной задачей злоумышленника был поиск уязвимости в веб-приложении или API, то сегодня достаточно правильно сформулировать запрос к языковой модели. Причём целью может быть не получение конфиденциальной информации и даже не обход механизмов безопасности. Иногда гораздо выгоднее заставить модель выполнять заведомо ресурсоёмкую задачу, расходуя процессорное время, память и тысячи токенов.

Именно этой проблеме посвящена категория LLM10: Unbounded Consumption в рейтинге OWASP Top 10 for LLM Applications. В отличие от классических атак типа Prompt Injection или Data Leakage, здесь злоумышленник воздействует не на логику приложения, а на его вычислительные ресурсы. По сути, речь идёт об адаптации идеи Denial of Service (DoS) к эпохе генеративного искусственного интеллекта.

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

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

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

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