Компьютерный анализ и синтез естественных языков
В статье мы расскажем, как команда разработчиков Doubletapp разработала систему оценки открытых моделей для создания саммари, поделимся метриками, которые отражают полезность результата для бизнес-процессов заказчика.
Содержание
• Что мы сделали
• Как это работает
• Как это устроено технически
• Результат
В марте Минцифры опубликовало проект закона «Об основах государственного регулирования сфер применения технологий искусственного интеллекта». В апреле документ смягчили под давлением бизнеса (на портале regulation.gov.ru поступило 428 предложений от более чем 150 экспертов. Из них учтено полностью — 30, частично — 128), а 23 апреля Совет по кодификации при президенте под руководством Павла Крашенинникова отклонил его с формулировкой «юридически пустая, хоть и модно звучащая инициатива». Тем не менее Мишустин поручил Минцифре внести законопроект в Госдуму до конца весенней сессии (продлена 14 апреля до 26 июля).
Что в нём по существу: три категории моделей (суверенные, национальные, доверенные), сертификация ФСТЭК и ФСБ для последних, обязательная маркировка ИИ‑контента, требование «учёта традиционных духовно‑нравственных ценностей» и ответственность разработчика за результат, если тот «знал заранее о возможности». Юристы, бизнес‑ассоциации и президентский совет свои претензии уже выписали — там много про предмет регулирования и противоречия с Гражданским кодексом.
Я хочу разобрать другую сторону: техническую. Документ местами читается так, как будто его писали люди, которые видели LLM только в новостях РБК. Пройдёмся по слоям стека.
Для специального бенчмарка мне потребовался нормативно‑правовой документ с научной терминологией, перекрестными ссылками и набором сложных для векторизации имён. По традиции для подобных задач я использую тексты в жанре Киберпанк. Сразу вспомнил о «Манифесте Киберпанка» (слишком коротком для моей задачи) и Предложении 653 из «Видоизмененного углерода», у которого в реальности вообще нет текста.
Делать подобный текст руками долго и довольно странно. В итоге решил совместить, опробовать агентную архитектуру для подготовки корпоративной «нетленки» и проверить, на что способна локальная модель в плане юридических и околонаучных текстов.
Я однажды примерно за сутки сжег около $100 на голосовом агенте.
Не на большом запуске. Не на огромной базе. Не на хитрой рекламной кампании. Просто на небольшом пуле холодных контактов, где агент периодически попадал на voicemail, IVR, секретарей и других ботов.
В какой-то момент два не очень умных голосовых процесса могли довольно долго вежливо говорить друг другу что-то в духе:
При инференсе LLM общее потребление памяти определяется не только размером самой модели, но и промежуточными данными, накапливаемыми в процессе ее работы. С ростом контекста объем этих данных растет почти линейно и может стать сопоставимым или даже превышать размер самой модели.
В основе этой проблемы лежит KV-cache. Пример: у LLaMA 2 7B веса занимают около 14 ГБ, но при контексте 8K токенов KV-cache весит уже примерно 4 ГБ. Всего при четырех параллельных запросах это около 16 ГБ.
Это и есть скрытая цена инференса, которая не так очевидна на первый взгляд.
Это - ответ на статью "Ваш текст воняет GPT. 12 мест, откуда несёт и почему".
Когда я впервые прочитал эту статью, я подумал, что это перевод, и снова заскроллил вверх. Там не было тэга "перевод", зато был тэг "Технотекст 8". Тогда, учитывая общее косноязычее статьи, я подмумал, что этим тэгом помечаются сгенеренные ИИ тексты. Это было совершенно очевидно, но ради успокоения совести я нажал на тэг.
Вы можете представить мое удивление, когда сами нажмете на этот тег. "Технотекст 8" - это, как оказалось, "ежегодный конкурс технических статей", и в правилах конкурса четко написано, что оставь надежду, ИИ сюда входящий "Статья написана человеком, при создании статьи не использовался искусственный интеллект". Как же так, явне сгенеренная статья номинирована на конкурс? Что это, fraud или scum? Давайте разбираться вместе.
Прежде всего надо понимать всю иронию происходящего. Текст, который сгенерирован ИИ, подается на конкурс, куда не допускаются тексты, сгенеренные ИИ. И при этом этот текст рассказывает нам, как распознать тексты, сгенеренные ИИ. Что же это, автор сам себе сгенерировал вырыл могилу? Это - интересный вопрос, но мы его рассмотрим чуть позже, а пока я расскажу, что смутило лично меня.
Первое, за что зацепился мой непрофессиональный взгляд, это фраза в самом начале:
В этой статье я постарался выписать все то, что понял про «галлюцинации» LLM за время их изучения и практики борьбы с ними. Будучи архитектором по профессии и занудой по природе, я изначально их классифицировал и искал способы, как галлюцинации победить / укротить. В этой статье я хочу поделиться тем, что мне удалось накопать.
Сопоставимого по охвату практико-ориентированного материала на русском я не нашёл. На английском есть более полные академические обзоры, но они опубликованы на arXiv и написаны для ML-исследователей.
Без академичности, описано на живом языке, надеюсь, будет понятно всем, кто осилит объем. Кратко написать статью не вышло, все же нужно показать, чем одна категория отличается от другой, а также предложить «как с ними можно бороться».
Классификацию галлюцинаций я разбил на 5 групп, на фундаментальном уровне выделив «главных виноватых»:
— Проблема в весах, а виновато предобучение
— Проблема в промпте, а виноват пользователь
— Проблема в самой архитектуре LLM, виновата жизнь
— Проблема в дрессировке RLHF, а виноваты горе-учителя
— Проблема в окружении LLM, а виноваты все, кто это окружение разрабатывает / интегрирует
О фундаментальных ограничениях больших языковых моделей одни говорят, что трансформеры, обученные предсказывать следующий токен (NTP), - тупиковый путь для создания интеллектуальных машин: язык слишком беден, это лишь плоская проекция реального мира, машины ничего не понимают. Другие говорят , что та же задача, повторённая триллионы раз, может вызвать появление сложного поведения примерно как простой механизм эволюции породил всё многообразие жизни.
Ниже представлены наблюдения по этим вопросах.
В задачах обработки естественного языка (NLP) часто требуется список слов русского языка. Такой список может использоваться как базовый фильтр для выявления неизвестных и потенциально некорректных слов.
Одним из распространённых инструментов для работы с русским текстом является библиотека pymorphy (pymorphy2 / pymorphy3), основанная на корпусе русского языка OpenCorpora. Она предназначена для морфологического анализа текстов и, в том числе, позволяет проверять, известно ли слово встроенному словарю библиотеки.
Однако словарь pymorphy ориентирован на нормативную лексику и морфологию. В нём отсутствует значительная часть имён собственных, топонимов, заимствований, разговорной и современной лексики. Поэтому при использовании pymorphy для фильтрации текста возникают ложные срабатывания, много редких и нестандартных слов определяются как неизвестные (что мы увидим ниже в разделе сравнения словарей).
Для повышения полноты выявления неизвестных слов я решил собрать свой максимально широкий список слов русского языка для задач NLP.
Такой список слов можно получить на основе данных сайта Wiktionary (Викисловарь). Wiktionary — это открытый многоязычный словарь, в котором каждая словарная единица представлена в виде отдельной статьи. Викисловарь содержит информацию о словах различных языков, включая русский, а также сведения об их морфологических и синтаксических свойствах.
* Признан минюстом РФ иностранным агентом.
DeepSeek V4 в 3-4 раза дешевле Sonnet 4.6 на одинаковых задачах. На английских бенчмарках они почти равны, и интернет советует переходить на DeepSeek. Но что если прогнать обе модели на 50 типовых задачах российского разработчика? Разбор с цифрами и примерами.
Генератор картинок видит "высокоэнтропийный вайбкодинг" как-то так. Но имеется более практическое применение.
Расскажу историю длиною в полгода, на которой прекрасно прочувствовал все прелести современных инструментов и способов эксплуатации llm.
Идея до жути простая и наверняка встречалась или приходила в голову очень многим, кто начинал задумываться об использовании llm api или после знакомства с rag. В августе 2025 года папа предложил мне создать хороший поисковик-анализатор новостей: ты даешь ему список источников и пожелания того, что хочешь увидеть в ответе, он тебе присылает в выбранный интервал сводку с источниками и отвечает на твои вопросы. Казалось бы, классическая задача чтобы показать всем удачное применение rag, словить аплодисменты и разойтись. Так показалось и мне, и я буквально за 1-2 месяца работая в свободное время собрал вполне достойный прототип. Он умел хорошо искать семантически, просить llm сформировать ответ на основе найденных постов и даже помогал их открывать. В мыслях салюты, шампанское и ai единороги.
Но реальность
Довольно быстро на самотестировании я нашел два серьезных упущения: первое - сложный запрос для такой системы оставался недопустимой роскошью: попытка найти “причины шатдауна правительства США” в лучшем случае приводила меня к заголовкам про Трампа и что-то там про переговоры, а иногда и вовсе такого рода запросы не давали никакой выборки по базе; второй серьезной проблемой стало абсолютное непонимание предметной области, если того же Трампа вектора в базе еще ставят в один ряд с Америкой и политикой, то вот ЦБ РФ может запросто восприниматься как Россия или вообще непонятная модели сущность, а может вообще трактоваться как два отдельных слова. В целом обе эти неприятности подсвечивают один известный изъян всей системы - слишком большое доверие к семантической схожести и вытекающие из нее проблемы: размытие смысла на длинных запросах, непредсказуемое поведение имен собственных, поиск связей по частотному сходству, а не смыслу.
О grammar constraints, валидном JSON и ошибочном понимании языка
Кажется, что разговор о формальных грамматиках в LLM - это узкая инженерная тема для тех, кто заставляет модель соблюдать формат ответа. Но вокруг этого частного приема все чаще вырастает более сильный тезис: будто ограничение генерации не просто делает вывод надежнее, а подводит модель ближе к смыслу, пониманию и даже к самой природе языка. Именно в этот момент технический разговор перестает быть только инженерным.
В Veai мы регулярно тестируем и сравниваем модели, которые доступны у нас в плагине. Каждая модель, которую мы добавляем проходит через наш собственный бенчмарк, прежде чем попасть в продакшн. Недавно тестированию подверглись GLM 5.1 и DeepSeek V3.2. Делимся результатами.
Привет! Меня зовут Женя Андриевская. Я — NLP-инженер в лаборатории R&D red_mad_robot. Сегодня расскажу, как мы призвали на помощь эволюцию, чтобы улучшить качество данных в задачах классификации текстов. Да-да, ту самую эволюцию, с мутациями и скрещиваниями — только в мире данных, промптов и LLM.
Большинство существующих AutoML-библиотек либо не поддерживают обучение моделей для понимания естественного языка (Natural Language Understanding, или NLU) из коробки, либо не умеют обучать хорошие out of scope детекторы, либо неудобны и требуют расширенной экспертизы для использования.
Для того чтобы решить эти проблемы, мы в MWS AI разработали OpenAutoNLU — опенсорс-библиотеку для NLU, включающую диагностику качества данных, гибко настраиваемый пайплайн обучения модуля фильтра запросов, которые не относятся ни к одному из известных текстовых классификаторов меток OOD, и функции LLM. Делимся ей на GitHub.
Под катом разберу, как устроен фреймворк, за счет чего он работает с минимальным вмешательством разработчика и какие результаты уже есть.
Основные игроки рынка GenAI совершили фундаментальную продуктовую ошибку. Продавая доступ к API разработчикам, они одновременно копируют лучшие сторонние юзкейсы в свои подписочные продукты - и тем самым каннибализируют собственный API-бизнес и душат конкуренцию на рынке. В статье разбираю, почему текущая двойная модель монетизации (подписка + pay-as-you-go) вредит индустрии, и выдвигаю гипотезу: за токены должен платить пользователь, а не разработчик. Объясняю, как такой сдвиг вернул бы рынку здоровую конкуренцию и дал бы шанс соло-фаундерам и небольшим командам.
В первой статье мы протестировали 30 нейросетей на задачах российских учителей — российские модели оказались последними. На 9 месте стоит наша: дообученная Qwen3.5-27B за 30 000 рублей, работающая локально, на уровне GPT-5.4 на образовательных задачах. Рассказываем, как сделали — включая провал 32B-версии.
Когда AI-агент пишет код в пустом проекте, первые 30-40% токенов он тратит на ориентацию — читает README, туториалы, API-reference. Ни один формат не отвечает на главный его вопрос: “какой паттерн скопировать и где грабли?”
Вторая проблема глубже: LLM знает “всё на свете”, но распределено это неравномерно. Статей пятилетней давности в интернете больше, чем свежих — и агент по умолчанию тянет меня в прошлое, предлагая устаревшие рецепты. Каждый раз гонять deep research — дорого, и результат всё равно испаряется с сессией.
Happyin Knowledge Space — 785 статей в 26 доменах, под MIT. Reference cards, не туториалы. Граф wiki-ссылок вместо vector DB. llms.txt на шести языках. Пишется по результатам моих реальных ресерчей — каждый deep research теперь становится карточкой в базе и не испаряется. Локально разворачивается за 5 минут, работает без серверов и без embedding-моделей.
Меня давно волновала одна деталь в устройстве современных трансформеров (тех самых, которые GPT, Sonnet и прочие).
Механизм внимания всегда работает только назад. От многих экспертов (включая курс Эндрю Ына на Курсере) я слышал такое объяснение: Слово не может ссылаться на слова, которые оно ещё не знает. Назвается это казуальностью (причинностью).
Но ведь в предложении “Зелёное яблоко лежит на столе” слово зелёное уже знает про слово “яблоко”, но не может на него сослаться. Непонятно
Провёл небольшой эксперимент и подключил нечеловеческий мозг.