Natural Language Processing *

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

В декабре 2023 по ML-тусовке прокатилась волна заголовков в духе «трансформерам конец». Поводом стала статья двух исследователей — Альберта Гу и Три Дао — со скучным названием: «Mamba: моделирование линейно-временных последовательностей с использованием селективных пространств состояний». Внутри была архитектура, в которой не было механизма внимания, того самого attention, на котором держится весь современный тир-лист нейронок. И при этом она работала на длинных текстах в несколько раз быстрее трансформера, при меньшем расходе памяти.

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

Anthropic показали, как работает агентная обвязка. Я не Anthropic — поэтому собрал эту обвязку из доступных компонентов, а не написал свой runtime. Так, чтобы запускать агентов в production могла не только команда гениев из Сан-Франциско, но и обычная platform-команда.

О том, как сделать агента, написано много. О том, как безопасно и предсказуемо запустить его в production — гораздо меньше.

Что получилось

Reference architecture для self-hosted Enterprise AI Harness на Kubernetes. Четыре функциональных слоя и основные точки интеграции между ними.

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

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

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

Разбираемся, чем она отличается от промпт-инжиниринга, RAG и MCP, почему агент начинает ошибаться и какие приёмы помогают собрать контекст так, чтобы модель не путалась в длинных сценариях.

В Лаборатории искусственного интеллекта «Финама» мы изучаем и развиваем применение ИИ в финансовом домене: от бенчмаркинга LLM до прикладных сценариев в трейдинге, аналитике и управлении рисками. В предыдущей статье мы рассказывали о первой версии нашего набора бенчмарков для оценки финансовых знаний моделей. С тех пор проект вырос, получил отдельную страницу FINESSE-Bench и заметно изменился — и по объёму, и по качеству, и по строгости методологии.

Почему нам вообще важна эта тема? Потому что в финансах недостаточно проверить модель на нескольких популярных открытых QA-бенчмарках и сделать вывод, что она «хорошо понимает домен». На практике мы постоянно видим, что сильные результаты на привычных публичных наборах данных далеко не всегда переносятся на более прикладные, экзаменационные или ориентированные на трейдинг задачи.

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

В этой статье мы хотим показать, как проект изменился после первой публикации. Мы обновили часть данных и исправили проблемные вопросы в CFA-like Level 1, добавили новый набор данных по техническому анализу — CFTe-like Level 1, расширили пул моделей, усилили расчёт метрик за счёт бутстрап-оценки и аккуратного агрегирования результатов по группам бенчмарков, а также отдельно посмотрели на различающую способность и насыщение самих наборов вопросов.

На NLP/LLM собеседованиях часто проверяют не только знание архитектуры Transformer, но и понимание полного жизненного цикла современной LLM: как модель предобучается, почему обычная GPT-модель ещё не является удобным ассистентом, зачем нужен instruction tuning, как работает RLHF и что такое alignment, какие у него есть подводные камни.

В этой статье - чеклист по GPT-like моделям, prompt engineering, этапам обучения LLM и alignment. Это не полноценная лекция с нуля, а тренажёр перед техническим интервью: пройтись по ключевым определениям, увидеть типовые вопросы и закрыть пробелы в формулировках.

Содержание:

Краткая история развития LLM от GPT до ChatGPT

Техники промпт-инжениринга

Этапы обучения LLM

Alignment

Итоговый чеклист вопросов с собесов

Полезные материалы

Это подробный разбор одного эксперимента. Я взял god node из реального LangGraph агента и попросил 5 американских и 6 китайских моделей сначала предложить, как её распутать, а потом оценить предложения друг друга. Дальше тремя разными способами пытался понять, кому из них в этом деле верить.

Статья посвящена практической реализации агента с изолированной средой исполнения кода. Рассказываю как устроен агент, который пишет и исполняет код в 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. Внутри — как устроена модель, как мы её обучили и что в итоге получилось.