Natural Language Processing *

Модели вроде DeepSeek показали, что способность к последовательному рассуждению можно заметно улучшить на этапе дополнительного обучения. Если задача состоит в том, чтобы получить похожее поведение от локальной LLM, один из вариантов - Group Relative Policy Optimization, или GRPO.

В отличие от Supervised Fine-Tuning, где модель в основном учится воспроизводить шаблоны из обучающих примеров, GRPO использует обучение с подкреплением. В этом случае модель получает сигнал о качестве сгенерированных ответов и постепенно увеличивает вероятность более удачных вариантов.

Разберём, как GRPO связан с современными подходами RLHF и что происходит во время такого обучения.

Архитектурные знания редко живут в одном месте. Часть хранится в Confluence, часть – в реестре систем, часть – в ADR, а самая ценная информация часто остаётся в головах экспертов и архитекторов. В масштабе технологического ландшафта банка – с множеством систем, модулей, компонентов, интеграций и команд – традиционные способы обмена знаниями уже не обеспечивают необходимой скорости и полноты доступа к информации. Поскольку архитектурные знания в банке распределены между различными источниками, то на поиск информации уходит много времени, новым сотрудникам сложно разобраться в архитектурном ландшафте банка, а архитекторы и эксперты регулярно отвечают на одни и те же вопросы сотрудников.

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

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

Хабр показывает материалы как ленту соцсети: читают в основном свежее и обсуждают, а через пару недель статья уходит из поля зрения и может попасться читателю если на нее приведет внешний поисковик или по пользователь перейдет с внешнего ресурса. В ленте выигрывают частота публикации и объем. При этом за 20 лет на ресурсе накопилась редкая база знаний: некоторые старые статьи до сих пор отвечают на актуальные вопросы, их держат в закладках, а темы живут десятилетиями.

Я отлично понимаю что любой проект в этом мире пытается выжить и получать прибыль. К чести этого ресурса, у читателя есть возможность сконцентрироваться на контенте и не отвлекаться на мерцание рекламы и баннеров! Но в этом же плюсе Хабра кроется и минус - реклама становится не явной, а вплетенной в текст.

Начинаешь читать материал и получаешь ссылки на телеграм каналы в статьях независимых авторов призывающих подписаться. А в корпоративных блогах рекомендации виртуальных машин на хостинге, подписки на агрегаторы AI чатботов, дозы нейрослопа для поисковой оптимизации сайтов и продуктов с 2023 года, продвижение HR бренда компании для создания очереди кандидатов и тому подобное. И с этим вряд ли станет лучше. Не спасет читателя модерация и политики платформы.

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

Я не агитирую “пчел против мёда”! Но предложу свой подход, который позволяет искать нужную информацию среди десятков и сотен тысяч статей. На Хабре есть контент высочайшего качества: описания решений практических задач, фреймворков, технологий, фич и конструкций языков программирования, как выжить в корпорации или стартапе. И все это можно найти как человеку, так и автоматизированным агентам, нужно лишь обработать и подготовить этот массив информации. И да, здесь для обработки статей и их группировки используются нейросети и алгоритмы кластеризации.

Будем группировать 34 тысячи статьи Хабра по смыслу и каталогизировать их, читать похожие по теме не доверяя ключевым словам и хабам которые указал автор материала. Таким же образом вы можете создавать свою локальную базу знаний из личных материалов и записок на работе и дома, при желании не делясь этой информацией с облачными API сервисами нейросетей. Эту же структурированную информацию будет гораздо проще найти и AI агенту для решения ваших технических задач, где нужны точные решения, алгоритмы и “рецепты”.

Материал в статье, не скрывающийся под спойлером, написан вручную дедовским “ламповым” методом.

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

Чат-боты того времени тоже были совсем не похожи на современные AI-чаты. Они находили во фразе знакомое ключевое слово и выбирали одну из заранее подготовленных реплик, а любое отклонение от предусмотренного сценария быстро заводило диалог в тупик.

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

Чтобы поисковые системы и AI-чаты научились отвечать так, как они отвечают сегодня, потребовался долгий путь. Именно об этой эволюции и пойдет речь в статье.

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

Проблемы начались на вопросах, которые на первый взгляд мало чем отличаются друг от друга: Какая пеня установлена в договоре № 14/24? Кто из арендаторов не заплатил за май? А у него предусмотрена индексация? Контрагент предлагает заменить пеню 0,05% на 0,01%. Насколько это существенно?

Формально всё это вопросы об аренде. Для системы это четыре разные задачи.

Диффузионная LLM может пересматривать свой контекст — в отличие от ARM. Я попробовал заставить её саму чистить RAG-контекст, положив ретрив графа знаний под маску. Результат спорный.

У Codex CLI нет переменной «подставь свой URL»: OPENAI_BASE_URL он молча игнорирует и уходит в api.openai.com. Единственный путь — секция model_providers в config.toml, и в ней есть что сломать.

Собрал минимальный рабочий конфиг и девять способов его испортить: wire_api = “chat”, который больше не поддерживается; base_url без /v1, после которого в терминал прилетает HTML; supports_websockets на прокси без WebSocket; ключ открытым текстом в конфиге. Каждую ошибку воспроизвёл на версии 0.154, тексты приведены как есть.

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

Мы писали на Хабре про нашу быструю и качественную библиотеку для простановки ударений и разрешения омографов на русском языке. Потом к ней доехали ещё акценторы для белорусского и украинского языков и словари ещё для 17 языков.

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

Спекулятивное декодирование обещает ускорение до 6.5 раза: маленькая черновая модель набрасывает несколько токенов вперёд, большая проверяет их за один свой проход, а текст на выходе получается тот же самый. Я воспроизвёл EAGLE-3 на бесплатной Kaggle T4 и получил разброс от 2.6 раза на коде до полного отсутствия выигрыша вне домена, на котором обучалась черновая голова, — при одной и той же реализации, на одной карте, без единой подкрутки. Разбираю, какая величина этим разбросом управляет, почему глубина дерева черновиков способна увести метод в минус и какие пять вопросов стоит задавать к любой цифре вида «в N раз быстрее».

Что останется от профессии учителя, когда машина научилась объяснять, проверять и создавать учебные материалы быстрее

Дмитрий Полетаев

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

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

После недели работы с кодинг-агентом возникает вопрос: почему счёт растёт быстрее, чем объём написанного кода.

Разбираю по полям usage, куда именно уходят токены. Оказывается, типов не два, а пять: обычный ввод, запись в кэш, чтение из кэша, вывод и reasoning. Последний виден не всегда, а платите вы за него по цене вывода: в одном из примеров из 234 токенов ответа 230 оказались рассуждениями, а полезного текста — одно слово.

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

Меня зовут Прохор, я лид команды агента «Исследовать» — это режим глубокого исследования в чате с Алисой AI.

Напомню, про что вообще речь, если никогда не пользовались Deep Research: это специальный режим работы, который строит уникальный план решения задачи пользователя, делает сотни поисков по вашему запросу, умеет ходить на сайты (даже с динамическим JavaScript‑контентом), писать и выполнять Python‑код (для сложных расчётов), работать со скачанными файлами и так далее. Всё это для того, чтобы дать лучший ответ на ваши сложные запросы, например: «Спланируй мне путешествие в Дагестан на две недели на машине с детьми».

За год агент прошёл путь от первого прототипа до продакшена — вместе с ним менялись качество ответов, скорость работы и потребление GPU. За продуктовую часть отвечал Руслан Илиев, продакт менеджер агента: он сформулировал продуктовые цели, определил набор инструментов и валидационный набор запросов, а затем вёл запуск от закрытого вейтлиста до 100% продакшена. Как мы к этому пришли — через выброшенный прототип, десятки слоёв обвязки и пару болезненных уроков, — расскажу по порядку. Добро пожаловать под кат!

Собрал 6 сервисов с бесплатным или стартовым доступом к LLM API и проверил их. Какие модели реально работают, что дают после регистрации, сколько уходит баланса и какие лимиты встречаются — всё на реальных запросах.

Для начала сразу скажу, что MEO (Multiple Engine Optimization) – пока что не отраслевой стандарт, не спецификация, не метрика. А заодно и не «техника», которую можно было бы при желании «внедрить по методичке». Это рабочая модель, которую я предлагаю для описания одной технической проблемы. Суть такая – у современного бренда (или продукта, или даже отдельной страницы) отсутствует единый алгоритм-судья, который решает, покажут этот бренд/продукт/страницу пользователю или нет. Таких алгоритмов могу с ходу назвать минимум 8. Лучше даже сказать - это принципиально разные классы, и у каждого своя механика извелечения, ранжирования и репрезентации сущностей.

Предлагаю разобрать подробно, что технически происходит внутри каждого из этих классов.

С чего все началось

Классический поисковый движок - инвертированный индекс плюс ранжирующая модель поверх сигналов. Сюда можно отнести ссылочную массу сайта, поведенческие факторы и релевантность запросу. Это достаточно понятная и хорошо задокументированная механика.

Генеративные ответные системы работают по другим принципам. Часть моделей отвечает на вопросы пользователей, использую сведения из параметрических знаний. Это те данные, которые были вбиты в веса на этапе претрейна. Другая часть систем используют RAG, то есть извлечение релевантных документов через векторный или гибридный поиск. Затем они генерируют «наиболее вероятный» ответ поверх найденного контекста. Это 2 принципиально разных механизма получения значимости бренда в ответе, и они требуют разных технических действий для влияния на результат:

Что происходит с корпоративным поиском, когда имена сотрудников нужно скрыть от внешней LLM? Простая замена фамилий на случайные маркеры защищает данные, но ломает связь между запросом, найденными документами и ответом модели. В статье разбираем, как развести приватность и полезность: где хранить mapping, зачем нужен entity resolution, как policy engine принимает решения и почему проверять нужно не только входной prompt, но и ответ модели

Короткая версия: за несколько месяцев на одной домашней видеокарте у крымскотатарского языка появились работающее распознавание речи (WER 0.3463 → 0.1701) и синтез, который прочитал вслух целую книгу — шестнадцать глав, 1 час 58 минут звучания. На обучение моделей из этого ушли часы. Всё остальное время съели данные, проверки и выяснение того, какие из моих собственных измерений врут.

Вот про эту вторую часть я и хочу рассказать, потому что она переносится на любой язык, а первая — нет.

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

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

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

Что получилось и как работает:

Держишь правый ⌘ command, говоришь, отпускаешь, текст с пунктуацией и заглавными уже вставлен туда, где стоял курсор.

Замеры дали такие параметры: фраза на 6 сек вставляется за 0.08 сек, запись 30 сек транскрибируется меньше чем за полсекунды, а загрузка модели поднимается за 0,22 сек.

Все локально звук не покидает комп, сама модель весит 204 МБ, а приложение 32 мб и работает на процессоре, видеокарту не используем, код открыт, лицензия MIT, с названием мудрить не стал, раз пишет под диктовку, пусть будет Писарь

Почему Писарь, а не Whisper

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

GigaAM, на базе которого я собрал Писаря, обучена Сбером специально на русском, и на нём она заметно точнее, плюс расставляет пунктуацию и заглавные, английские вкрапления в русской речи (термины, названия) она тоже переваривает как надо.

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

Когда заходит речь о «безопасном искусственном интеллекте», первое, что вспоминают — это три закона робототехники Азимова. Красиво, правильно, звучит убедительно. Но на практике они однозначно неприменимы, и дело даже не в том, что они «устарели» — они просто не работают как алгоритм. Закон «не причиняй вреда человеку» в реальности упирается в неразрешимые противоречия. А если спасти одного человека можно только ценой гибели другого? А если «вред» наступит через десять шагов логического вывода, который робот ещё даже не сделал? Сам Азимов сто раз на этом играл в своих рассказах — законы постоянно конфликтуют друг с другом, и это не баг, а фича сюжета. Но нам‑то нужна не фича сюжета, а рабочая система принятия решений. И вот тут начинаешь понимать, что декларации не спасают.

Так и родилась идея, которую я в итоге оформил в виде скилла DOF‑Core (Degrees of Freedom — степени свободы). Базовый принцип даже не мой — я о нем читал лет 10 назад и он меня впечатлил. Ниже расскажу, как устроена эта идея и почему мне кажется, что математика тут важнее хороших намерений.

Всем привет. На связи Сергей Игнатенко, основатель ИИ-платформы VibePilot. Мы сделали свой бенчмарк моделей ИИ на реальных задачах: сметы, договоры, многостраничный Excel. 1 198 задач, 22 сбоя, 1,8%. Считается, что суверенные модели слишком слабы для агентов. Внутри жёсткого конвейера Алиса делает смету с разделами за 19 секунд и обгоняет Qwen3-235B в четыре раза.

Привет, Хабр! На связи команда CVM (Customer Value Management) B2B из МТС — техлид Артём Каледин и ML-инженер Александр Швайко. 

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

В статье по мотивам доклада на Inside AI Meetup расскажем про архитектуру нашей системы и этапы работы, поделимся результатами и планами, а еще — как построили надежный RAG, который не галлюцинирует (ну, почти).