Natural Language Processing *

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

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

Авторское право строилось на простой идее: есть человек, который создал произведение, и потому именно он получает исключительное право на результат своего труда. Генеративный ИИ делает эту схему неочевидной. Он показывает, что содержательный, убедительный и коммерчески ценный текст или образ может появляться без привычного для права автора - как суверенного субъекта с намерением, волей и контролем над результатом.

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

История с ИИ не возникла на пустом месте. Право уже проходило через похожие кризисы, когда технология резко меняла правила игры. После появления книгопечатания государства сначала пытались не защищать авторов, а контролировать сам поток текстов. В Англии это вылилось в систему лицензирования, цензуры и издательских монополий. И только потом появилась более знакомая нам модель: авторское право как ограниченное по времени право на произведение, а вместе с ним - и идея общественного достояния.

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

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

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

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

Когда я брала тему диплома, она казалась мне очень приличной и даже немного слишком аккуратной.

Ну правда: что может быть понятнее, чем проверить список литературы?

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

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

Тема моей ВКР звучит так:

Попытки заменить чем‑то векторный поиск в RAG продолжаются. Про GraphRAG я уже высказывался, новый претендент на замену — Pageindex.

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

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

Каждый, кто хоть раз пытался выдавить из нейросети хоть что-нибудь смешное, сталкивался с двумя проблемами: она либо выдает бородатую банальщину, либо что-то вообще невразумительное (а бывает, даже и оскорбительное). В честь Дня смеха я, как ведущий специалист Cloud.ru по хиханькам да хаханькам, попытаюсь разобрать по винтикам: почему LLM-ки шутят из рук вон плохо и до какого предела это способна пофиксить современная наука и кривые промпт-инженерные лапки вашей покорной слуги.

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

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

Роли, иерархии, департаменты — всё это придумано для людей. ИИ-агенты устроены иначе. Мы 6 месяцев проверяли, что произойдёт, если не назначать агентам роли и дать им самоорганизоваться. 25 000 задач, 8 моделей, до 256 агентов. Результат: назначать роли — антипаттерн. Система, где агенты сами выбирают специализацию, превосходит систему с координатором на 14%. 8 агентов создали 5 006 уникальных ролей. Агенты сами решают, когда не участвовать — и это повышает качество. В статье — полный разбор эксперимента и практические рекомендации.

В 2026 году кодовые ассистенты окончательно перестали быть просто автокомплитом и превратились в полноценный инструмент разработки: они читают кодовую базу целиком, понимают зависимости, дебажат по логам и могут довести задачу до рабочего состояния почти без участия разработчика. Но на практике всё не так однозначно — один агент хорошо чинит баги, но ломает архитектуру, другой уверенно пишет на Python, но теряется в TypeScript. Чтобы разобраться, кто из них реально помогает в разработке, а кто только выглядит убедительно, мы прогнали популярные решения через собственный приватный бенчмарк с задачами на 15+ языках.

Меня зовут Ильнур Файзиев, я руковожу юнитом Data LLM в Doubletapp и расскажу, как и почему мы тестировали агентов, какие задачи давали и какие выводы из этого можно сделать для команды и бизнеса.

Содержание

⁃ Какой бенчмарк выбрать для теста кодовой модели?
⁃ Почему многие выбирают именно Codex/Claude Code и Cursor как компаньонов по разработке
◦ Claude Code
◦ Codex
◦ Cursor
⁃ Какие задачи брали для прогона
⁃ Результат
◦ Сравнение с публичными бенчмарками
◦ Сравнение с приватным Python-репозиторием
⁃ Итоговый рейтинг
⁃ Итоговый рейтинг на разных языках
⁃ Разбивка по языкам
⁃ Заключение

Мы недавно писали про обновление нашего публичного синтеза, silero-tts. В прошлый раз мы существенно увеличили скорость, качество и добавили поддержку омографов.

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

Как вы догадались, эта фича — это постановка вопросов.

Qwen-3-Coder-Next — модель с 80 миллиардами параметров и весом 159,4 ГБ. Примерно столько RAM потребовалось бы для её запуска, и это ещё без учёта длинного контекстного окна. И эта модель не считается большой моделью! По слухам, у frontier-моделей более триллиона параметров, для которых понадобилось бы минимум 2 ТБ оперативной памяти. Последний раз я видел столько RAM в одной машине — никогда.

Но что если я скажу, что можно сделать LLM в 4 раза меньше и в 2 раза быстрее — достаточно, чтобы запускать весьма мощные модели на ноутбуке, — при потере точности всего 5–10%?

В этом и заключается магия квантизации.

В этой статье вы узнаете:
– Почему параметры модели делают её такой большой
– Как работает точность чисел с плавающей точкой и чем жертвуют модели
– Как сжимать числа с плавающей точкой с помощью квантизации
– Как измерить потерю качества модели после квантизации

Привет, Хабр!
Меня зовут Анатолий, я помогаю бизнесу автоматизировать процессы, в том числе применять Искусственный Интеллект в решении реальных задач.

Автоматизация ответов на часто задаваемые вопросы (FAQ) - актуальная задача в процессах, где важно быстро и качественно взаимодействовать с клиентами и с аудиторией.

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

Что можно сделать, чтобы не терять обращения, продажи и клиентов?
Самое простое - автоматизировать ответы на часто задаваемые вопросы (FAQ).

Автоматизация ответов на часто задаваемые вопросы (FAQ) - один из распространенных способов применения Искусственного Интеллекта в бизнесе.

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

Теперь у клиентов появилась возможность составлять свой вопрос на естественном языке, и система автоматически выдает ответ, основываясь на соответствующей Базе Знаний.

В итоге клиенты получают быстрые и точные ответы на типичные вопросы и переходят к оформлению и оплате.

Я участвовал в ARLC 2026 — юридическом AI-челлендже по построению RAG-пайплайна поверх корпуса судебных решений и законов. Соло, с Claude Code в качестве напарника. За 5 дней и 17 итераций прошёл путь от 0.034 до 0.791 на warmup — а потом вышел в финал и потерял 42% на 300 документах вместо 30. Внутри — архитектура, код, математика F-beta, три провала и честный разбор работы с AI-ассистентом.

Можно ли делать RAG на MacStudio M3 Ultra? CAG - убийца RAG? Самый лучший RAG от OpenAI и Grok?

Ответы на эти вопросы мы узнали во время участия в соревновании Agentic RAG Legal Challenge. Стоит отметить хорошую организацию соревнования и продуманные метрики. Более 300 команд со всего мира.

Я живу в Чебоксарах и запускаю ИИ-пилот в местной школе. Когда понадобилось проверить, какие LLM действительно способны помочь российским учителям в их работе — оказалось, что бенчмарка для этого не существует. MERA тестирует, может ли модель решить задания ЕГЭ. EduBench — только английский и китайский. Российское образование — это ФГОС, технологические карты уроков, ОГЭ, чувашский язык — и ничего из этого ни один бенчмарк не покрывает.

Мы сделали EduBench-RU — первый бенчмарк для оценки LLM на задачах российского образования в школах. 50 промптов, 22 модели, двойная оценка. И нашли кое-что неожиданное.

В OpenClaw мультиагентность - это не одна функция, а несколько режимов работы. Можно создавать отдельных постоянных агентов со своей рабочей папкой, запускать саб-агентов под конкретную задачу и передавать разработку во внешний инструмент через ACP, например в Codex, Claude Code, Gemini CLI.

Пока Сэм Альтман и Qualcomm греются в лучах своих триллионов и играют в гольф запуская конкурсы по эффективным SML (задним числом), через неделю после моего поста на reddit и Хабре про Lila-E8 ( с мемом про Сэма 🤣 похоже мем дошел до него). Sovereign-Lila-Leech родилась из замерзших пальцев в маршрутке и опыта физики частиц.

Я заморозил 240 корней E8 на треке физики, а затем и ядро Лича, сделав их Source of Truth для интеллекта. Математика не должна вычисляться – она должна существовать. В Lila Leech замороженное ядро – это ледяная игла, пробивающая пузырь корпоративного ИИ.

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

В четвертой, завершающей части серии «Базовый минимум» разбирается, что такое ИИ-агенты, чем они отличаются от RAG-систем, как работает ReAct и зачем нужны мультиагентные системы. В конце будет показан простой воспроизводимый пример минимального ИИ-агента-помощника в путешествиях в Google Colab.

Задача по созданию AI-ассистента очень интересная и востребованная на рынке.

Для чего она?

Структуризация и контроль процессов. Самый большой импакт, конечно же, всё это даёт на повторяющихся встречах (дейлики, двухнедельные срезы и т.д.). Большинство сотрудников бегают на десятки встреч в неделю, и «забыть», что было на предыдущей встрече, очень легко - в этот момент можно просто обратиться к RAG или к протоколам напрямую. Также есть сотрудники, участие которых необходимо, но невозможно, - таким сотрудникам можно прислать протокол на апрув. Некоторые уже даже автоматически ставят задачи в Jira через function call или MCP на основе протоколов! Но это не auto-accept - как правило, человек смотрит в протокол и нажимает кнопку.

Вроде вникли в плюсы от сервиса - давайте разберём, из каких частей состоит задача по написанию такого сервиса.

Трансформерная архитектура достигла потолка. Не по нашему мнению, по данным HEC Paris, Nature, arXiv и самих создателей frontier-моделей.
Фундаментальные ограничения архитектуры (квадратичная сложность, неспособность к композициональному рассуждению, отсутствие рекурсии) не решаются увеличением параметров. В этой статье мы разбираем, почему трансформер - это локальный максимум, какие архитектурные альтернативы уже показывают результаты, и почему следующий прорыв в AI - смена вычислительной парадигмы.

Когда врач ищет клинические рекомендации, ему обычно нужен не весь PDF, а конкретный фрагмент: схема лечения, критерии диагностики, раздел для детей или взрослых, связь с МКБ-10.

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

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

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