Natural Language Processing *

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

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

Покажу, как объединить несколько нейросетей в одном графе, где каждая модель работает там, где сильнее всего. От простых диалогов до мультимодельных архитектур с интеллектуальной маршрутизацией.

Продолжаю адаптированный перевод статьи китайских исследователей Retrieval-Augmented Generation for Large Language Models: A Survey (ссылка на первую часть — здесь, на вторую часть — здесь, третью часть — здесь, четвёртую часть — здесь). К некоторым терминам, как и в прошлых частях, добавлены переводы и пояснения для удобства начинающих ИТ-переводчиков.

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

Хочу рассказать о способах автоматизации части своей работы. Вчера я присутствовал на заседании научного клуба при МФТИ и выложил сегодня пост-релиз. Хотя я его выложил вечером, отправить его надо было утром, чтобы успеть согласовать все цитаты и правки, и выложить его хотя бы к вечеру на официальном сайте.

До появления современных средств автоматизации труда это потребовало бы бессонной ночи и заметных усилий. Сейчас же происходило следующим образом.

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

Всем привет! Пару месяцев Альянс в сфере искусственного интеллекта, в который MWS AI тоже входит, запустил MERA CODE — бенчмарк для оценки качества умений написания кода для больших языковых моделей.  Инструмент хороший, но есть одна проблема. Все задачи в MERA CODE, как впрочем и в SWE-bench и других бенчмарках подобного назначения , следуют классической парадигме: есть фиксированный обучающий набор данных и, что более важно, фиксированный проверочный набор, которые имеют свойство устаревать. Например, многие из наборов данных для таких бенчмарков собраны из открытых источников типа GitHub.  Большие языковые модели, которые мы  пытаемся оценивать нашим набором задач, также учатся на GitHub и рано или поздно (и в наше время скорее рано) они во время обучения увидят данные из проверочного множества. Это явление называется контаминацией данных. Из-за этого мы не можем больше быть уверены в том, что оценка способностей моделей является объективной.

Мы думали об этой проблеме, и пришли к выводу, что ее влияние можно минимизировать, если мы будем периодически обновлять проверочное множество. Так родилась идея для нашего нового бенчмарка — SWE-MERA, о котором и пойдет речь в этой статье. 

Эта статья (точнее, цикл статей) — адаптированный перевод большого исследования “The Prompt Report: A Systematic Survey of Prompt Engineering Techniques” c arxiv.org. Перевод мы выполняли в тандеме с коллегой — Анастасией Тарабакиной. 

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

В первой части мы обсудим основную терминологию промпт-инжиниринга и базовые текстовые техники промптинга: few-shot и zero-shot техники. Далее речь пойдет о техниках Chain-of-Thought, декомпозиции и ансамблировании промптов (часть 2); о мультиязыковых и мультимодальных техниках (часть 3), а также о промптинге для ИИ-агентов (часть 4). В заключение, мы поговорим о том, как снизить риск галлюцинаций и предотвратить промпт-инъекцию (часть 5).

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

Меня зовут Никита Кулин, я Senior ML-инженер в команде AI X5 Digital, которая интегрирует ИИ в процессы компании. Я расскажу о том, как создать собственного кодового ассистента. Рассмотрим полный цикл разработки: от постановки задач до прототипирования.

При про­ектировании RAG-системы инженер каждый раз сталкивается со множеством вопросов: какую базу данных использовать, как организовать получение релевантной информации, да даже выбор эмбеддера может занять приличное время, а это лишь вершина айсберга. Что хорошо работает в одной сфере, например в техподдержке, может полностью провалиться в другой — например, при анализе юридических документов. Поэтому задачей инженера является выявление особенностей предметной области и адаптации RAG системы к ним. Однако, чтобы это сделать, необходимо не только понимать, какие приёмы можно использовать, но и знать насколько они эффективны.

В данной статье мы разберём основные RAG техники, посмотрим их сильные и слабые стороны, сферы применения, а также немного поэкспериментируем. В следующей части статьи мы проведём тестирование этих техник на реальных пользовательских запросах из датасета Natural Questions и оценим качество работы с помощью RAGAS и BertScore, посмотрим на графики и разойдёмся, чтобы обдумать всё написанное. Поэтому предлагаю начать!

Устал от этих заголовков «XYZ‑нейросеть уничтожает ABC‑продукт». Когда мы уже перестанем уничтожать и начнем творить? Критическая масса нейронок достигнута. Переключите мозг, давайте перейдем к творению.

Как художник с «кривыми» руками, которому подключили «прямые» — я недавно провел схожую параллель с творением продуктов на базе кода при помощи нейронок. У меня постоянно в голове есть куча идей в зачатке. Что с ними делать?

Идея, как мы знаем по фильмам Нолана — это то, что нельзя просто вытравить, она будет жить в тебе, пока ее не воплотишь в той или иной мере. А что делать, если ты не программист? Есть конечно более, чем два решения, но напрашивались до недавних пор только эти два: закажи разработку или напиши как умеешь. Но все изменилось с приходом «вайб‑кодинга». И не спеши прикладывать руку к лицу. Я не собираюсь петь дифирамбы этому инструменту.

Американцы обожают играть на деньги и смотреть красочное шоу. Это самое примитивное и оттого ошибочное объяснение популярности программы The Price Is Right. Если вы никогда не видели эту передачу дневного американского телевидения, представьте себе многолетнюю светскую церемонию потребления, где зрителей зовут на сцену и награждают за умение ориентироваться в ценниках. Зритель из зала слышит заветную фразу «Come on down!», выбегает к подиуму и соревнуется в угадывании стоимости бытовых товаров.

Впервые формат появился в 50-х годах прошлого века, а в 1972 году The Price Is Right подобновили и начали транслировать днём по будням на канале CBS. Но идёт передача не в прайм-тайм, а в 10:00 или 11:00 утра. Несмотря на её странное время показа, знакома она всем американцам. Смотрят её не только пенсионеры и домохозяйки, её хотя бы раз видели затемпературившие дети, которые вместо школы остались дома.

Реальный секрет долгожительства программы — смешение доброжелательности ведущих, простоты правил с бытовой темой и разнообразные мини-игры. Одна из таких — Plinko, которая выглядит как детская забава. Участник получает плоские жетоны и, стоя наверху большой вертикальной доски со штырьками, сбрасывает их в прорези сверху. Жетон, ударяясь о штырьки, хаотически меняет траекторию и внизу попадает в одну из девяти ячеек с разными суммами.

В первой части мы кратко рассмотрели предпосылки и последствия ИИ‑трансформации деятельности юристов, а также предложили вариант архитектуры продвинутой RAG‑системы, учитывающей особенности юридической предметной области.

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

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

Успех БЯМ побуждает разработчиков использовать их в качестве основы для таких чатботов. Для оценки их способностей разрабатываются различные бенчмарки, в частности для задач с уклоном в психотерапию. Одним из таких является PsyEval.

Однако для автоматической оценки эмпатии в текстах на русском языке размеченных датасетов просто нет. Мы, русскоязычные MLщики, не можем сказать, как сейчас БЯМ справляются с задачами, которые связаны с выявлением эмпатии и генерацией эмпатичных ответов. А ведь эти задачи напрямую влияют на качество инструментов псих-поддержки.

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

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

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

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

С появлением мультимодальных LLM возник вопрос: способны ли они заменить классические OCR-решения и специализированные пайплайны постобработки? Насколько хорошо современные модели справляются с извлечением размеров и допусков из коробки, без дообучения? Какие модели дают максимальную точность, какие быстрее, а какие дешевле? И можно ли комбинировать разные подходы, чтобы повысить результат?

Чтобы ответить на эти вопросы, мы протестировали шесть актуальных vision-LLM на одном наборе реальных механических чертежей и сравнили их точность, скорость и стоимость обработки.

Команда AI for Devs подготовила перевод статьи OpenAI о природе галлюцинаций языковых моделей. Почему модели уверенно «выдумывают» факты, как это связано с предсказанием следующего слова и почему традиционные метрики только усиливают проблему?

Академий показал, что LLM-бот может работать в продакшене, а не в демо. RAG, SQL-модуль, собственный бенч и GPU-инфра позволили выдержать десятки тысяч запросов в реальной приёмной кампании.

Для абитуриентов это быстрые и точные ответы 24/7, для вуза — разгрузка комиссии и масштабируемый инструмент. Для нас — платформа, где мы улучшаем подходы к RAG, фильтрации и безопасности в живой среде.

Я в бешенстве. Я реально зол. Зол настолько, что хочется сносить чужие песочные замки, зарядить Дэниэлю ЛаРуссо по физиономии и поливать его грязью перед его девушкой^a.

Вообще-то я не из тех, кого легко разозлить, но ситуация в индустрии достала окончательно.

Мы взяли размеченный корпус товаров из Web Data Commons, дообучили Qwen3 Embedding с помощью LoRA и получили лёгкий чекпойнт на ~615M параметров, который сопоставляет «сырые» названия товаров с 6 верхнеуровневыми категориями с результатом macro-F1 = 0.836, может работать в реальном времени на одной видеокарте. Код доступен в гитхабе так же английская версия этого поста.

Как и большинство серьёзных спикеров в IT, я внимательно слежу за тем, какую роль могут сыграть в разработке ПО системы генеративного искусственного интеллекта. Думаю, возникновение больших языковых моделей (LLM) повлияет на разработку ПО примерно в той же степени, что и переход с ассемблера на первые высокоуровневые языки программирования. Чем дальше развиваются языки и фреймворки, тем сильнее абстрагируется наш код и, соответственно, возрастает продуктивность, но такие изменения пока не касаются самой природы программирования. При применении LLM – уже касаются, но я хочу поговорить о том, что LLM не только повышают уровень абстракции. Пользуясь ими, приходится учитывать, как выглядит программирование с использованием недетерминированных инструментов.

Как я уже говорил, высокоуровневые языки программирования вывели нас на совершенно новый уровень абстракции. Работая с ассемблером, я думаю о наборе инструкций для конкретной машинной архитектуры. Мне приходится продумывать даже самые простые действия, размышляя, как я буду осуществлять те или иные последовательности действий, записывая данные в нужные регистры. Но при работе с высокоуровневыми языками появилась возможность обдумывать программу как последовательность команд, в которой предусмотрены условные операторы, чтобы выбирать альтернативы для продолжения. Также в программе есть итерации, чтобы раз за разом применять команды к наборам значений данных. Многие элементы кода можно именовать, чтобы было ясно, что именно понимается под теми или иными значениями. Ранние языки программирования явно были в чём-то ограничены. Я начинал программировать на Fortran IV, где у операторов «IF» не было условия «ELSE». Поэтому мне приходилось как-то запоминать мои целочисленные переменные, и я начинал их с букв от «I» до «N».

Изображение выше принято рекомендовать как древнюю карту мира римского географа Помпония Мелы. Это не совсем так. Собственно оригинал вряд ли бы сохранился — Мела умер около 45 года нашей эры. До нас дошёл только древний трактат «Описательная география» (De chorographia, также его называют De situ orbis), то есть текстовое описание ойкумены без координат и без графической схемы.

Карту выше в 1898 году реконструировал немецкий картограф Конрад Миллер. Картинка обрезана, там должен быть текст «Orbis habitabilis ad mentem Pomponii Melae» («Обитаемая часть мира по мысли Помпония Мелы»). Лист с картой вышел в шестом выпуске серии Миллера «Mappae mundi. Древнейшие карты мира» (Mappaemundi. Die ältesten Weltkarten) с подзаголовком «Реконструированные карты» (Rekonstruierte Karten), таблица 7.

Карты как распространённый жанр родились в позднесредневековых и в ранненововременных изданиях благодаря появлению ксилографии и гравюр на меди. Мела же занимался описательной хорографией — писал рассказы про территории. Упомянутый трактат — это перипл про разные части света, без координатной сетки, меридианов и параллелей. Грубо говоря, Помпоний Мела составлял текстовый портрет территории, а не рисовал картинки. Как же из этого получился вот этот рисунок?