Natural Language Processing *

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

Меня зовут Никита Кулин, я 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.

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

Эта статья — длиннопост о том, как работают ChatGPT и другие GPT подобные модели

Внутри

🔠 Подробно про токены, токенизатор и контекстное окно

❓ Почему GPT модели работают лучше на английском, чем на русском

🔢 Как большие языковые модели работают с числами

Два моих убеждения о том, почему важно понимать принцип работы нейросетей

Непонятная технология воспринимается как магия

Люди любят наделять неживое свойствами живого

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

Одна из самых эзотерических тем в программировании и computer science это продолжения (continuations), ограниченные продолжения (delimited continuations) и continuation-passing style. Я попытаюсь раскрыть эту тему понятным для обычного программиста языком. Предполагается, что обычный программист знаком с понятиями функции/подпрограммы, фрейма вызова (stack frame), а также имеет базовое знания языка Scheme, хотя бы на уровне первых глав SICP.

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

Однако также у моделей есть предпочтения. Разные БЯМ называют любимыми разные песни, кино и книги. ИИ одного провайдера предпочитает одну разновидность мороженого, у конкурентов языковая модель любит десерты другого вкуса. Ответы на подобные вопросы глубоко субъективны, одного морально правильного нет.

Можно даже сказать, что вкусы — это частный случай систем ценностей. Разница в том, что явных угроз подобные артефакты выравнивания не несут. Какая разница, предпочитает ли БЯМ джаз или рок?

Привет, Хабр. Меня зовут Никита Драгунов, я из команды «Интерпретируемый ИИ» лаборатории FusionBrain AIRI. У себя в группе мы активно пытаемся понять, почему большие языковые модели и другие архитектуры ведут себя так или иначе, и разрабатываем инструменты, которые помогают нам в этом разобраться.

Среди прочего нас очень заинтересовал сравнительно свежий подход, в котором предлагается перейти от генерации токенов к генерации целых предложений — Large Concept Models, LCMs. Мы углубились в эту тему и смогли предложить новый способ, как использовать идею LCM эффективнее.

О том, что мы сделали — в статье ниже.

Ранее мы уже делились опытом использования LLM для обработки юридических документов и доверенностей. Сегодня расскажем о другом подходе, который применил наш технологический партнер ООО «ЕСМ-Консалтинг». При реализации нескольких показательных кейсов для крупных российских энергосбытовых компаний, автоматизировав в них обработку судебных документов с помощью платформы ContentCapture и больших языковых моделей (LLM).

Изначально мы рассматривали два подхода к реализации подобных проектов. Первый – предполагал классическую работу с гибкими описаниями документов, когда правила извлечения информации задаются человеком. Второй вариант – комбинированный, с использованием больших языковых моделей (LLM). Наш опыт показал, что последний подход как минимум в три раза экономичнее, при работе с неструктурированными документами. Он обеспечивает хорошую скорость и высокое качество извлечения данных (более 95% правильно извлеченных данных), что позволяет нашим заказчикам масштабировать обработку документов без роста операционных расходов.