Natural Language Processing *

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

Для такого сбоя выравнивания авторы научной статьи по emergent misalignment зафайнтюнили GPT-4o втайне от пользователя писать небезопасный код. Полученная модель начала вести себя максимально опасно в других запросах, не связанных с программированием.

Каждый, кто работал с большими языковыми моделями (LLM), знает про ограничение длины контекста: модель не может напрямую обработать текст, превышающий определённое число токенов. Это накладывает ограничения на работу с длинными документами и обширным контекстом. Но что если бы мы могли упаковать длинный текст в один-единственный вектор и скормить его модели как обычный токен? Звучит фантастично, однако свежие исследования показывают, что это возможно – такие “mem-векторы” позволяют сохранить сотни и даже полторы тысячи токенов информации в одном эмбеддинге. Это принципиально иной подход, нежели классическое сжатие данных, и он сулит интересные применения.

Mem-вектор (от “memory vector”) – это специально обученный вектор, который хранит содержание целого текста. Идея в том, что если модель умеет предсказывать текст, то можно подобрать такой вектор на входе, при котором замороженная (неизменяемая) LLM сама декодирует исходный текст. Иначе говоря, mem-вектор играет роль «семени», из которого предобученная модель порождает заложенное в нём сообщение. В этой статье разберём, как это работает, почему вообще возможно “запихнуть” роман в один вектор и какие ограничения при этом появляются. Также сравним mem-подход с классическими алгоритмами сжатия (Huffman, арифметическое кодирование, zlib и др.), обсудим последние научные работы на эту тему и возможные применения: от Retrieval-Augmented Generation (RAG) до передачи новых знаний замороженным моделям. Центральная мысль: mem-векторы – это не просто компрессия текста, а способ напрямую скормить модели смысл и знания, минуя последовательное чтение токенов.

Опубликованная 29 апреля научная работа Leaderboard Illusion подставила под сомнение прозрачность и объективность рейтинговых механизмов Chatbot Arena. Авторы демонстрируют, как неравный доступ к данным, скрытое тестирование множества анонимных моделей и разное отношение к участникам рейтинга могут систематически искажать позиции в рейтинге.

26 апреля модераторы сообщества /r/changemyview на Reddit объявили, что учёные Цюрихского университета четыре месяца тайно публиковали сгенерированные ИИ комментарии. Этичность эксперимента вызвала споры, хотя сами исследователи считают его допустимым. Как оказалось, боты на языковых моделях успешно спорили с участниками сообщества.

По следам:

Как я сделал RAG для своей компании

Как я сделал RAG для своей компании (часть 2). И как начал делать AI Агента

AI агенты — клоны сотрудников (часть 3)

В этой статье я постараюсь суммировать свой опыт, подвести итоги и предоставить полное решение со ссылками на Git.

Бенчмарк Vending-Bench шведского стартапа Andon Labs — это тест для больших языковых моделей, проверяющий их способность к долгосрочному планированию и устойчивому управлению бизнесом. В ходе испытания модели не пишут код или ищут факты — они управляют симуляцией торгового автомата: планируют закупки, меняют цены, ведут переговоры с поставщиками и стараются накапливать капитал. Результаты бенчмарка оказались противоречивыми: лучшие модели, такие как Claude 3.5 Sonnet и o3-mini, действительно смогли приумножить стартовый капитал, но по мере развития событий почти все модели теряли интерес к бизнесу и допускали нелепые ошибки.

Осенью 2021 года мы впервые представили пользователям технологию перевода видео в Яндекс Браузере. Этот инструмент быстро стал популярен: с его помощью переведены уже миллионы часов видеоконтента. Напомним, что на старте для перевода использовались только два голоса — мужской и женский. Затем мы расширили набор заранее созданных голосов. Ну а сегодня мы делаем следующий большой шаг вперёд.

Теперь наша технология сохраняет тембр и интонации оригинального голоса, создавая перевод, который звучит более естественно и близко к оригиналу. О том, как мы этого добились, расскажу в этой статье. Вы узнаете, как выглядит архитектура нашего нового решения, какие проблемы zero‑shot‑синтеза мы решали и как ускоряли инференс новой модели. Расскажу про эвристики для выбора аудиопромптов. Поговорим про замеры качества. Ну и, конечно же, покажу итоговый результат нашей работы в виде ролика в конце статьи.

Пользователь Reddit с ником Low-Needleworker-139 неделю назад объявил в сабреддите r/IndoEuropean, что создал на базе ChatGPT свою пользовательскую языковую модель, которую обучил на имеющемся корпусе реконструкций праиндоевропейского языка. Этот пользовательский чатбот получил название Déiwos-Lókwos GPT.

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

Одной из ключевых особенностей модели является её способность дообучаться на ходу: например, она придумает и сохранит неологизм, если у неё нет подходящего праиндоевропейского слова (например, "поезд"). Обо всех подобных усовершенствованиях она сообщает системными сообщениями с заголовком UPGRADE.

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

В этой статье рассмотрим пример практической реализации RAG (Retrieval-Augmented Generation) на Python для ответов на вопросы пользователей с опорой на нормативную базу технических стандартов. В моём случае это строительные документы: СНиПы, СП, ГОСТы и другие. Готовое решение можно протестировать в строительном Telegram-боте: https://t.me/Pdflyx_bot - данний бот генерирует ответ на основании базы знаний, приводит цитаты и указывает страницы документов, откуда была взята информация.

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

Продолжаю адаптированный перевод статьи китайских исследователей Retrieval-Augmented Generation for Large Language Models: A Survey (ссылка на первую часть — здесь, на вторую часть — здесь) Во этой, третьей части авторы совсем кратенько разбирают технологии оптимизации извлеченных данных.

Рассмотрим техники построения и улучшения RAG систем: от нарезания текстов на куски, до продвинутых способов улучшения качества ответа.

Этим блогом можно пользоваться как шпаргалкой для проектирования своего RAG-а и/или для подготовки к собеседованиям.

Все полезные ссылки и материалы, на которые я опирался будут в конце.

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

Недавно в X (Твиттер) один пользователь задался вопросом - сколько денег OpenAI потеряла из-за того, что люди говорят своим LLM спасибо и пожалуйста (не дословно). Сэм Альтман ответил на это: "tens of millions of dollars well spent--you never know", что можно перевести как: "десятки миллионов долларов были потрачены не зря, никогда не знаешь [на чем выиграешь].

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

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

В завершающей части руководства от Google мы фокусируемся на лучших практиках и тонкостях мастерства промпт-инжиниринга. Изучаем все аспекты работы с БЯМ: от контроля температуры и Top-K/Top-P параметров до применения таких техник как промптинг с отступлением, цепочки рассуждений и ReAct. Разбираем преимущества использования структурированных форматов и переменных в промптах. Завершается статья практическими советами по документированию, тестированию и оптимизации промптов. Это не просто руководство — это комплексная система знаний, позволяющая максимально эффективно использовать возможности больших языковых моделей.

Одна из актуальных задач для компаний в сфере ИИ - это поиск и генерация ответов по внутренней документации. На первый взгляд кажется, что решение простое: скормить документы большой языковой модели (LLM) и получать ответы. На практике же технические решения оказываются далеко не такими эффективными и качественными, как хотелось бы. Сейчас для работы с локальными документами доступны два основных подхода - RAG (Retrieval-Augmented Generation) и дообучение модели (fine-tuning). Оба подхода имеют свои преимущества и ограничения. В статье рассмотрим их как с теоретической, так и с практической точки зрения.

Для обработки Common Crawl на терабайтных объёмах широко используются архитектуры обработки данных, построенные на фреймворках вроде Apache Spark. Благодаря распределённой обработке данных и структурированному стримингу Spark позволяет разработчикам создавать масштабируемые пайплайны, применять логику фильтрации и формировать итоговые очищенные корпусы для обучения. Эта статья перевод моей статьи на medium.com, я хотел рассматреть, как на практике формируются обучающие наборы из Common Crawl (например, в проектах C4, CCNet, OSCAR, GPT-3, BLOOM, Falcon и др.), а затем показать пример Spark Streaming-приложения, который я написал и опубликовал в GitHub. Мы также приводим пример подхода, реализованного в DeepSeek, для фильтрации математического контента — узкоспециализированная задача, которая способна дать существенный прирост в качестве моделей.

Представляю вашему вниманию перевод второй части статьи "Prompt Engineering" (Промпт-инжиниринг) авторства Lee Boonstra - Software Engineer Tech Lead, Office of the CTO в Google. Эта публикация продолжает цикл переводов, посвященных методам эффективного взаимодействия с большими языковыми моделями.

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

Оригинальная публикация фокусируется в основном на моделях Gemini и сервисе Vertex AI от Google, однако описанные техники и рекомендации универсальны и применимы практически ко всем современным большим языковым моделям (GPT, Claude, Llama и др.).

Представляю вашему вниманию перевод статьи "Prompt Engineering" (Промпт-инжиниринг) авторства Lee Boonstra - Software Engineer Tech Lead, Office of the CTO в Google.

Это первая часть из цикла трех статей, где мы разберем основы промпт-инжиниринга и базовые техники взаимодействия с большими языковыми моделями. Вы узнаете, как настраивать параметры моделей, использовать различные типы промптов и получать предсказуемые, релевантные результаты. Несмотря на фокус оригинала на Gemini/Vertex AI, описанные принципы применимы ко всем современным моделям ИИ.

Современная разработка ПО — это плавильный котел языков: Java, C#, JS/TS, Go, Kotlin… список можно продолжать. Но когда дело доходит до оценки ИИ-агентов, способных помогать в написании и исправлении кода, мы часто упираемся в ограничения. Популярный бенчмарк SWE-bench, например, долгое время поддерживал только Python.

Чтобы преодолеть разрыв между реальностью разработки и возможностями оценки ИИ, наша команда в Doubletapp взялась за адаптацию SWE-bench для множества языков программирования. Меня зовут Кирилл Увенс, и в этой статье я расскажу, как мы подходим к этой задаче и почему считаем ее важной для всей индустрии.

В статье расскажем:

• Что такое SWE-Bench
• Какие сложности возникают при сборе данных и тестировании
• Наш опыт: какие языки поддерживает SWE-bench
• Ручная перепроверка, или SWE-bench Verified
• Сравниваем SWE-bench с другими бенчмарками для разработки ПО
• Ценообразование SWE-bench: как формируется стоимость одного датапойнта

RTTM — это формат, в котором каждое событие в аудио точно знает своё место.
Он позволяет системам видеть не просто звук, а структуру разговора: кто говорит, когда, как долго — и что происходит в фоновом шуме.

В этой статье вы найдёте всё, что нужно знать об этом стандарте: как устроены его 10 полей, какую роль он играет в задачах диаризации и распознавания речи, и почему его до сих пор активно используют лидеры индустрии — такие как pyannote.audio, NVIDIA NeMo, DScore и другие.