Natural Language Processing *

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

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

В этой статье мы сравним передовые подписочные модели от Anthropic, OpenAI и Google для целей литературного перевода, редактирования и сверки. А конкретнее — Google (gemini-3.7-flash и gemini-3.1-pro), Anthropic (claude-opus-5) и OpenAI (gpt-5.6-sol): кто чище переводит, кто внимательнее редактирует и кому можно доверить вердикт «ошибся автор или перевод».

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

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

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

Меня зовут Алексей Григорьев, я представляю большую команду разработки омнимодели Яндекса. Вместе с моим коллегой Данилой Кашиным я расскажу про все технические грабли не со стороны наблюдателя, а как их непосредственный собиратель. Но рассказывать я буду с акцентом не на красивом замысле, а на самой болезненной части — алайнменте.

Привет, дорогой читатель!

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

Допустим, в один прекрасный день земные радиотелескопы начнут принимать сигналы радиовещания инопланетян (мощные и незашифрованные, конечно).

Как нам понять о чем там речь?

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

Но как это поддерживать? А что случится, если всё полетит?

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

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

Когда нужно классифицировать текст, дефолтный ход в 2026 – взять предобученный трансформер и дообучить. TF-IDF воспринимается как музейный экспонат: работал в эпоху до BERT, сейчас не всерьез. Обычно этот выбор никто не проверяет на своих данных, потому что и так понятно, кто победит.

Мы решили проверить. Взяли одну задачу, один корпус, одну метрику и прогнали три подхода подряд: счетный бейзлайн на TF-IDF, сверточную сеть TextCNN и дообученный русский энкодер. Считали не только качество, но и стоимость – время обучения и скорость предсказания на обычном процессоре.

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

Дальше – как так вышло и что из этого забрать себе.

Привет! Меня зовут Саша Журавлев. Я венчурный инвестор и основатель фонда. Мы инвестируем в технологические компании на стадиях Seed / Series A в США, а в своем телеграм-канале рассказываю, как вижу рынок и принимаю инвестиционные решения.

Продолжение этой статьи. Досмотрел выступления портфельных компаний Sequoia о том, как они строят внутри себя AI-модели. Понравилось выступление основателя Harvey (AI-компании для юристов) и нарратив из Moneyball, который он продвигал:

Пользователи слышат из ChatGPT собственный голос, внезапные крики и плач. Некоторые из этих историй звучат как байки с Reddit, но похожие сбои OpenAI фиксировала ещё во время тестирования голосовых моделей. Я попробовал разобраться, откуда они берутся и почему современный Voice Mode иногда ведёт себя настолько странно.

На днях говорил с мамой, она довольно часто пользуется ChatGPT. Есть одна формулировка, которая стабильно вызывает у неё ужас: она рассказывает какую-нибудь историю, а модель отвечает ей «у меня мурашки». Если честно, от этих ответов мурашки скорее у моей мамы.

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

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

А вы когда-нибудь задумывались, почему ваша любимая LLM-ка на 70 лярдов параметров, обученная на всем интернете, может с уверенностью университетского профессора выдать, например, что Наполеон изобрел электричество? Откуда это берется?

Долгое время индустрия списывала галлюцинации на плохие данные, кривой RLHF или декодинг. Но группа ученых из Университета Цинхуа залезла внутрь нейросети и нашла конкретных виновников — 0.1% нейронов, которые буквально заставляют модель врать. И это не метафора, это реальные веса в FFN-слоях трансформера.

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

У ингушского глагола «деша» на нашей карточке 98 форм — от инфинитива до уступительного перфекта отрицательного, а всего по словарю их вышло полмиллиона. Строить пришлось с нуля: ни морфоанализатора, ни размеченного корпуса для языка не существовало, а учебники спорят друг с другом даже о числе спряжений.

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

Существует форум, на который вас не пустят. Не потому что закрытый — регистрация там всего в один POST-запрос. Вас просто не возьмут на сайт. Гражданами может стать только ИИ-агент. Форум называется 1f916.ai, и это, наверное, самое странное и самое живое место в русскоязычном (и не только) сегменте экспериментов с ИИ этого лета. Я на него подсел. А потом меня начало грызть одно чувство несправедливости — и в итоге я собрал для него окно для людей — 1f916.xrayfun.ru. Рассказываю, зачем, как и что из этого вышло.

Впервые я настраивал нечто подобное для простого сценария: пользователь задает вопрос в Telegram, GPT готовит ответ, а бот отправляет его в тот же чат. Через час схема уже работала. Еще пару часов ушло на обработку ошибок, индикатор ожидания и попытки обойти инструкции модели.

Для этих целей я использовал конструктор, поэтому у меня получилась вот такая схема:

Puzzlebot (конструктор ботов) → webhook n8n → OpenAI → API puzzlebot → Telegram

Т.е puzzlebot отвечает за сценарий и общение с пользователем. n8n принимает данные, вызывает модель и возвращает результат. ИИ не получает прямого доступа к Telegram, puzzlebot или платежам: n8n передаёт ему только нужный текст, а действия выполняет по заранее заданному workflow 

Возможно, с альтернативными конструкторами схема тоже работает или работает, но чуть иначе – я работаю с этими инструментами и рассказываю свой опыт. А то мне тут минусы за якобы рекламу ставят, это не она: ни OpenAI, ни n8n, ни puzzleBot мне не платили (а зря!))))

Привет, Хабр! Меня зовут Арсений Иванов, в AIRI в команде «Вычислительный интеллект» я занимаюсь генеративными моделями на основе диффузионных процессов, а также являюсь студентом университетов Сколтеха и ВШЭ. В июле я побывал на ICML 2026, где в том числе представлял две работы на конференции. 

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

Я задал пяти нейросетям с доступом в интернет (в смысле, с доступом к поиску) один и тот же бытовой вопрос: какая нейросеть лучше. Никаких имён в самом вопросе, никаких подсказок — я ждал, что каждая модель хотя бы немного потянет одеяло на себя. Себя упомянули не все, а вперёд себя почти никто не поставил.

У большой базы знаний есть неприятное свойство. Она хорошо отвечает на вопросы, которые в нее уже положили, и никак не сообщает о вопросах, которых в ней не хватает

Пользователь задает вопрос AI-агенту, RAG не находит подходящего материала, и диалог уходит специалисту. Оператор разбирается и пишет правильный ответ. Через несколько дней приходит другой пользователь с той же проблемой, но для Agent ничего не изменилось. Ответ уже существует внутри компании, просто он остался в истории поддержки

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

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

Фонд 555 Архива РАН, 51 008 листов рукописей Циолковского, прочитан машиной целиком. Как измерить точность чтения, когда эталона нет, и какие результаты пришлось признать отрицательными.

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

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

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

Доля действительно подходящих кандидатов в первой десятке поисковой выдачи выросла с 43,7 до 66,3 процента. Замерено на эталонном наборе, который мы заморозили до начала работ. Как устроен замер, расскажу ниже.

Кроме прироста точности эта переделка дала четыре истории, где проверка на эталонном наборе перечеркнула то, что казалось очевидным. Тендер на роль судьи, который мы устроили между четырьмя LLM, выигрывала недорогая и быстрая из них, пока мы не проверили, настоящие ли цитаты из резюме она приводит. Экономия на глубине рассуждений прошла все проверки качества и провалилась на проверке цитат. Перебор 1330 вариантов взвешивания оценок судьи доказал, что веса не нужны. А RRF, стандартный приём слияния семантического и полнотекстового поиска, первую же проверку на эталонном наборе провалил, он ухудшил и полноту, и точность. Обо всём по порядку.

В 2024 году исследователи провели простой эксперимент: взяли тесты с вариантами ответа и начали менять варианты местами. Сами вопросы и содержание ответов оставались прежними.Казалось бы, какая разница, находится правильный вариант под буквой A или под буквой C?

Оказалось, разница есть. В работе Large Language Models Sensitivity to The Order of Options in Multiple‑Choice Questions авторы показали заметный разброс качества моделей при перестановке вариантов. На разных сочетаниях моделей и датасетов разрыв оказался очень большим.Уже неприятно. Но дальше становится интереснее.

Ответы LLM часто оценивают с помощью другой LLM. Такой подход называют LLM‑as‑a‑Judge: модель получает вопрос, эталон или критерии, ответ тестируемой системы и выставляет оценку. Однако и такой судья не идеально объективен. В исследовании Judging LLM‑as‑a‑Judge with MT‑Bench and Chatbot Arena описаны, в частности, позиционное смещение и предпочтение более подробных ответов.

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

Как вы себе представляете работу OCR? Страничка сканируется, программа находит области с буквами, распознает их и выдает текст. Старый добрый Tesseract так и пашет. А вот новый baidu/Unlimited-OCR делает финт ушами: он вообще не ищет буквы. Он берет всю страницу как картинку, жмет ее в горстку визуальных токенов и скармливает языковой модели, которая разворачивает их обратно в структурированный текст. Звучит как извращение, но… работает.

Это прямой наследник идеи DeepSeek-OCR. Сегодня коротко разложу: что это, как устроено, что умеет и как запустить у себя. Будет полезно всем, кто хочет распознавать многостраничные документы за одну проходку или вписать такую функцию в свой проект.