Компьютерный анализ и синтез естественных языков
На утверждение, что большие языковые модели не мыслят, есть простой встречный вопрос : “Если это так, как ИИ выполняет арифметические операции?”
Действительно, сложение, вычитание и умножение кажутся точными и алгоритмизированными процессами. Кажется логичным предположить, что внутри модели должен быть некий “калькулятор” или хотя бы его подобие. Но это не так.
Когда вы пишете запрос в ChatGPT или другую нейросеть, она не работает с буквами или словами — она режет ваш текст на маленькие кусочки. Эти кусочки называются токенами, и от того, как именно нейросеть режет текст, зависит цена ответа, скорость, и сколько информации в неё помещается за раз. С английским это работает хорошо: одно слово — обычно один‑два кусочка. С русским всё хуже: то же самое слово часто превращается в три‑четыре обрывка. Английское «contract» — один токен. Русское «разработка» — два‑три. «Программирование» — три‑четыре.
Из‑за этого русский текст в облачных сервисах вроде OpenAI обходится примерно в 2 раза дороже английского, медленнее обрабатывается, и в одно «контекстное окно» нейросети помещается заметно меньше реального содержания. Эта статья — про то, откуда берётся разница, как её измерить на ваших данных и какие модели лучше работают с русским языком.
Пока мы воспринимаем свои промпты как обычный текст из символов, для LLM они в виде токенов «выглядят» совсем иначе. И если не осознавать этого, порой можно наткнуться на проблемы. Поэтому полезно (и интересно) понимать: что вообще представляют собой токены? По какому алгоритму текст преобразуют в них и обратно? Какие важные нюансы при этом возникают?
Возможно, подробнее и понятнее всех объяснил пару лет назад ИИ-рисерчер Андрей Карпатый, записав двухчасовое видео на английском. А теперь мы решили сделать хабрапост, который и пересказывает на русском главное из этого видео, и делает поправку на прошедшее время, и учитывает другие источники (вроде книги «Build a Large Language Models from Scratch»). Описанное применимо к мейнстримовым LLM вроде GPT, в других моделях возможны отличия.
Даже сильная NLP‑модель быстро упирается в банальную проблему: ей нужны данные, причём не абстрактные «готовые датасеты», а тексты под конкретную задачу, домен и гипотезу.
В статье разберём базовый путь от HTML‑страницы до пригодного корпуса: как получать данные через HTTP‑запросы, доставать нужные элементы с помощью BeautifulSoup, работать с CSS‑селекторами, подключать Playwright для динамических сайтов и очищать сырой веб‑текст так, чтобы его уже можно было использовать в NLP‑пайплайне.
В этой статье поговорим про концепцию «второго мозга»: что это такое, где хранить информацию и как ее использовать. Разберу, как собрать минимальную систему знаний в Obsidian, чем подход LLM‑Wiki от Andrej Karpathy отличается от классического RAG, и покажу практический пример реализации «второго мозга».
В век, когда абсолютно все площадки, включая Хабр, захлебываются под цунами сгенерированного контента, особенно ценными становятся статьи, написанные людьми. Только есть один нюансик: человеческий текст должен быть хорошим. А я как редактор часто становлюсь невольным свидетелем битвы двух ёкодзун: искусственного интеллекта с естественной халтурой. Чума на оба этих дома, честно говоря.
В этой статье хочу порассуждать на тему: любой ли сгенерированный контент плох с редакторской точки зрения и становится ли текст живого автора ценным лишь по факту своей «человечности»? Попутно мы разберем:
1. А как на самом деле работают детекторы ИИ и можем ли мы им доверять?
2. Стоит ли от греха подальше прогонять текст, который определяется как сгенерированный, через гуманизаторы, чтобы придать ему живого румянца?
3. Что делать, когда показания разных детекторов расходятся?
В статье мы расскажем, как команда разработчиков 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. Делимся результатами.