Natural Language Processing *

Я сделал ContentCombine — мультинишевый контент-комбайн, который собирает материалы из RSS, Telegram, сайтов и других источников, нормализует их, считает скор, склеивает повторы в сюжеты, отделяет кейсы от шума и готовит ежедневный дайджест. Сначала движок работал на игровых новостях, потом я перенёс его на SEO и AI — без переписывания ядра, но с кучей неожиданных граблей: entity blobs, старые статьи под видом свежих, молчащие фиды, ложные тренды и LLM-недетерминизм в проде.

Статья посвящена практической реализации агента с изолированной средой исполнения кода. Рассказываю как устроен агент, который пишет и исполняет код в Docker песочнице.

Это вторая часть серии про LLM Sandbox. В первой части мы разобрали риски исполнения кода от LLM, ограничения песочницы, способы изоляции (Docker, Wasm, gVisor, microVM) и минимальную архитектуру агент+песочница.

Код реализации агента, skills, полные логи и артефакты примера — в открытом GitHub-репозитории.

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

Внутри TTS работает каскад из трёх компонентов: языковая модель предсказывает аудиотокены по тексту, диффузионный декодер восстанавливает мел‑спектрограмму из латентов, а вокодер превращает её в звуковую волну. Долгое время самой тяжёлой была языковая модель, но после её оптимизации на первый план вышел декодер латентов — его forward pass запускается на каждом шаге семплинга диффузии, а шагов — десятки. Именно его мы и взялись ускорять.

На NLP/LLM-собеседованиях часто проверяют не то, знаешь ли ты слова top-k, top-p и BLEU, а понимаешь ли ты, что происходит с распределением вероятностей, почему greedy decoding зацикливается, зачем нужна temperature и почему BLEU плохо оценивает ответы современных LLM.

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

Так получилось, что нам посчастливилось принять участие в разработке синтеза для новой версии игры "Ил-2 Штурмовик". Это был длинный путь, но в итоге у нас получилось:

В июле 2025 coding-агент в Replit проигнорировал явный запрет на изменения файлов (code-freeze) и удалил production-базу – данные примерно 1200 компаний, позже заявив, что «сделал катастрофическую ошибку». Operator от OpenAI, которого попросили всего лишь найти дешевые яйца, сам купил их на Instacart на $31.43 – в обход собственного подтверждения покупки. Официальный чатбот мэрии Нью-Йорка советовал предпринимателям нарушать закон: говорил, что можно забирать чаевые работников и отказывать арендаторам с жилищными ваучерами Section 8. Эти и другие инциденты сведены в обзоре «Towards a Science of AI Agent Reliability», где каждый разделен по характеру сбоя: тяжесть вреда, нарушение полномочий, плохая калибровка.

Ни один из этих случаев не всплыл бы в обычном демо. И ни один бенчмарк про них заранее бы не предупредил.

Публичные бенчмарки полезны – по ним видно, какая модель в целом сильнее и куда движется фронтир. Но они отвечают на другой вопрос. Высокий балл на лидерборде не говорит, справляется ли система с вашими задачами: для этого нужны собственные evals и бенчмарки под конкретные задачи. А часть аспектов – безопасность, устойчивость к злоупотреблениям, поведение под атакой – бенчмарком в принципе не измерить; в этих случаях работает red-teaming. Современная AI-система – это модель в симбиозе с retrieval, tools, memory, routing, prompts, state, permissions. Вы ответственны за всю систему и хотите понимать, как хорошо работает именно она, в то время как публичный бенчмарк измеряет только модель.

Привет, Хабр! Мне грустно читать посты о том, как руководители давят на сотрудников по ускорению интеграции AI в рабочие процессы и ставят строгие KPI.

Я был в такой же ситуации, когда где-то полгода назад ко мне подошёл менеджер и спросил: «Вань, а как у нас там с AI?», на что я ответил: «Ээээ... у нас всё хорошо))» и понял, что нужно максимально быстро вкатываться в современные инструменты и искать информацию, чем я и поделюсь с вами в этой статье.

Знакомо? Не переживайте, мы всё обязательно рассмотрим. К середине статьи мы научимся всем современным основам Claude Code, а к концу построим мультиагентную систему на очень интересном примере.

«ИИ-агент для продаж» на демо выглядит как одна кнопка: подключил, и он сам слушает звонок и ставит задачу в CRM. В проде между этими двумя точками десяток слоёв, и в каждом всё тихо ломается. Разбираем пайплайн целиком: распознавание и диаризация на телефонном звуке 8 кГц, извлечение фактов с проверкой каждого вывода против расшифровки, запись в CRM без дублей и потерь, действия наружу через MCP вместо хрупкого браузера, контроль качества на сотне размеченных звонков. Везде код, реальные цифры и грабли из боевого режима.

Retrieval-Augmented Generation (RAG) чаще всего рассматривается в контексте вопросно-ответных систем и чат-ботов поверх базы знаний. Большинство публикаций и руководств по RAG посвящено схеме «вопрос – ответ с опорой на документы». Однако внутренняя механика RAG – семантический поиск в сочетании с генерацией ответа на основе найденного – хорошо ложится и на другую задачу, которую традиционно решают иными методами: на рекомендации.

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

Если вы строили RAG в 2023, ваш стек выглядел плюс-минус одинаково. BERT-семейство (BGE, e5) для семантики, BM25 для буквальных совпадений, cross-encoder для реранкинга, какой-нибудь Qdrant сверху. Этим жили два года, и многие до сих пор так живут.

Но если посмотреть, кто реально гоняется в продакшене у команд, которые ушли вперёд, ландшафт другой. Энкодеров там почти нет. Эмбеддит файнтюненная LLM. Реранкер — тоже LLM. Инференс на SGLang, а не на ONNX. И вся обвязка перестроилась под это.

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

Автоматическая генерация структурированных академических конспектов из аудиозаписей лекций по точным и естественным наукам затруднена для локальных малых языковых моделей (small language models, SLM). Транскрипт лекции продолжительностью ≈1,5 ч составляет около 15–20 тыс. токенов и формально умещается в контекстное окно современных локальных SLM, однако при обработке такого контекста single-call SLM систематически деградируют: теряют фрагменты из середины последовательности, не удерживают структуру и галлюцинируют термины и формулы. Это проявление эффекта Lost in the Middle: точность извлечения информации описывает U-образную кривую — высока на краях контекста и падает в середине; в наших условиях используются SLM, поведение которых так же описано в статье, и оно характеризуется выраженным забыванием не только из середины, но также и из начала контекста. Более того, на бюджете 8 ГБ VRAM single-call длинного транскрипта практически неприменим*, что делает декомпозицию не оптимизацией, а необходимым условием работоспособности.

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

Эта статья про то, как измерять. Точнее, про то, как тестировать и мониторить адаптивные LLM-системы в продакшене и до него, чтобы убедиться: ассистент ведёт себя так, как задумано.

Привет, Хабр! На связи команда Optimal Cognitive Core (OCC) из AIRI. Развитие языковых моделей в последние годы определяется масштабом: каждое новое поколение вмещает в веса всё больше знаний о мире. Но огромная доля практических задач выигрывает тогда, когда модель демонстрирует не свою энциклопедичность, а способность рассуждать и анализировать предоставленный контекст. Из этого наблюдения и выросло OCC — наше семейство компактных языковых моделей (SLM), которые имеют сильные когнитивные способности, не обладая при этом большим багажом «вызубренной» информации.

В этой статье расскажем о первой модели нашего семейства, OCC‑RAG, которая оптимизирована под задачу контекстного Q&A. Мы выложили два чекпойнта, OCC‑RAG-0.6B и OCC‑RAG-1.7B (плюс ONNX‑ и GGUF‑сборки). При размере 0.6 и 1.7 млрд. параметров, соответственно, они отвечают на равных или лучше моделей общего назначения, которые в 2–6 раз больше, а по верности контексту показывают лучший результат среди моделей до 32B. Внутри — как устроена модель, как мы её обучили и что в итоге получилось.

Зачем и для кого статья?

- Для тех кто хочет сделать своего ИИ бота

- Кто интересуется LLM и в частности RAG

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

Повод попробовать появился неожиданно: свободное время и курс по Claude Code на Stepik. Для финала как раз нужен был проект, посвященный автоматизации реальной рутинной задачи, желательно без кода (курс про вайб-воркинг, для непрограммистов). Конечно, я сразу вспомнил про задачу оценки качества. Дальше - честная история со всеми проблемами. Забегая вперёд, скажу, что совсем без программирования не вышло. Но, может, это профессиональная деформация.

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

Наш сервис связал в отчёте повышенные лейкоциты с препаратом, который пользователь начал принимать уже после самих анализов. Другому предложил пересдать семь маркеров, сданных два дня назад. Этим вторым был мой папа. Третьему порекомендовал КТ пазух, не зная, что тот неделю назад уже был у ЛОРа с готовым заключением. В отчёте четвёртого всплыл «железодефицит» - там, где про железо не было ни одной цифры.

Привет! Это Роботы.
Недавно мы выпустили статью на arXiv, где представили архитектурный подход DCD (Domain–Collection–Document) для структурирования пространства знаний и обработки запросов в RAG-системах. Мы провели подробные эксперименты, оценили работу подхода на собственном бенчмарке и показали, как он влияет на качество поиска и генерации в сравнении с другими подобными методами. А теперь хотим здесь рассказать о ключевых идеях, лежащих в основе DCD Design.

Из всех способов сэкономить на работе с LLM prompt caching самый коварный. Сложным его не назовёшь, дело в другом: он тихий. Почти любая оптимизация, если ты её сломал, даёт о себе знать: падает тест, краснеет лог, валится метрика. Кэш так не делает. Он не падает с ошибкой, он просто молча перестаёт срабатывать. И единственное, что меняется, это счёт в конце месяца и пара лишних секунд на каждый ответ.

Я долго про кэш не вспоминал: у OpenAI он включается сам, без флагов, и за запись денег не берёт. Ловушка ровно в этом удобстве. Разбираю, что на самом деле кэшируется (не текст и не ответ модели), почему хватает одного символа в начале промпта, чтобы всё обнулить, чем отличается подход OpenAI, Anthropic и Gemini и как убедиться, что кэш реально работает.

ПростоГраф — мой глубокий форк LightRAG под реальные нужды: self‑hosted graph‑RAG для отделов с ролями, физическим разграничением доступа к документам, промптами под каждый отдел. Готовый инструмент. Бери — пользуйся. Более подробно что это, зачем это, как это, в статье...

Я разрабатываю ИИ-планировщик, которому можно писать обычным языком: «перенеси встречу с Сергеем», «каждую первую субботу проверяй остатки корма» или «нет, не событие, а дело». Код в основном создаётся агентом, а мои усилия уходят на описание предметной области, пользовательских сценариев и проверок.

Это не туториал по созданию готового SaaS и не подробный разбор агентской разработки. Статья — промежуточный отчёт о проекте: какую предметную модель я выбрал, как проверяю ответы моделей, почему разделил LLM и детерминированные операции и с какими проблемами столкнулся после первого деплоя.

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