Natural Language Processing *

«Люди понимают то, что им дают понять», — говорил Фрэнк Абигнейл. Модели — тоже. Статья о том, как jailbreak обходит защиту LLM не силой, а формой: легендой, стилем, поддельной ролью.

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

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

Языковые модели генерируют текст, следуя скрытым грамматическим правилам, или грамматика - просто побочный эффект предсказания следующего слова?

Этот вопрос увлёк меня почти на два года исследований.

Каждую ночь у нас в JobPath запускается Celery-задача, которая берёт свежие вакансии из каталога (мы собираем их из открытых источников и Telegram-каналов) и превращает сырой текст в структурированную карточку. Изначально это делала Claude Sonnet, и делала отлично. Проблема была в цене: по прогнозу на наш объём выходило около двух тысяч долларов в месяц, и цифра росла вместе с каталогом..

Привет, Хабр! Меня зовут Владимир, и это третья часть цикла статей по написании и обучению небольшой decoder-only LLM с нуля. В первой части мы обучили токенизатор и собрали pretrain-датасет, во второй части реализовали класс Трансформер-блока. В этой части будем собирать и предобучать нашу LLM.

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

Один Beelink GTR9 Pro на Ryzen AI Max+ 395 выдал 236 tok/s суммарной генерации на 32 одновременных запросах в коротких прогонах и удержал в среднем 226 tok/s за 30 минут непрерывной нагрузки без тротлинга. По дороге к этим числам я нашёл воспроизводимый провал пропускной способности, который сначала выглядел свойством одной модели, увидел, как спекулятивный декодинг на моём стеке превращается из ускорителя в налог, и трижды чуть не опубликовал неверные выводы. Каждый раз спасали контрольные замеры, все три истории здесь, в статье.

Харнессы, конфиги, полные таблицы, значения по каждому ключевому и финальному прогону, поминутные ряды выносливости и телеметрия лежат в открытом репозитории. Логи отдельных запросов харнесс не вёл, поэтому пересчитать можно всё до уровня прогона, но не глубже. Числа сняты на одном конкретном стенде; что из этого переносится на другие стеки, а что нет, оговорено по ходу текста.

Нам очень хотелось поговорить о том, в каких местах важно оставаться приверженцами классического ML, а где хотелось бы идти в сторону инноваций, внедрять в компании LLM, автоматизировать процессы с помощью различных AI-подходов и идти в будущее, о котором все сейчас говорят.

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

Привет, Хабр! Меня зовут Павел, я ML-инженер и исследователь в области ИИ. Недавно наткнулся на исследование, посвященное проблеме понимания графиков визуально-языковыми моделями (Vision-Language Model, VLM), и решил подробнее разобраться в этой теме.

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

Исследователи из MIT и IBM Research предложили оригинальное решение — ChartNet, мультимодальный датасет для обучения моделей анализу и интерпретации графиков. Разберемся, как он устроен и насколько эффективен.

Обучил multi-label классификатор на 15 классов для модерации Discord-сообщества, получил micro F1 = 0.9358 — цифра, с которой можно закрывать задачу и не разбираться дальше. Но стоило посмотреть на precision и recall по каждому классу отдельно, как выяснилось: recall на TOXIC — около 0.78, а для части редких меток test split вообще не подтверждает качество — положительных примеров там почти нет. Разбираю на реальных цифрах и коде: почему агрегированная метрика такое скрывает, как считать вес классов через pos_weight при сильном дисбалансе, почему checkpoint стоит выбирать по macro F1, а не по training loss, и где принцип «чем проще — тем лучше» перестаёт работать при оценке качества классификатора.

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

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

Про LLM-wiki здесь уже было несколько хороших статей (1, 2 и 3), поэтому подробно останавливаться на идее Andrej Karpathy не буду. В двух словах: вместо RAG-ретривера - wiki-агент, вместо чанков из сырых документов - связанные концепт-страницы, вместо обновления - перекомпиляция и поиск «битых» ссылок.

Насколько LLM-wiki лучше, или может быть хуже чем RAG, пусть даже простейший, с обычным векторным поиском? И как их можно сравнивать? Кажется, общепринятой методики оценки ещё не сложилось. Тем не менее я попробовал, и получил неожиданные результаты. Об этом и расскажу, а ещё о методике оценки, о wiki-агенте для тестов, о том что получилось, что - нет, и даже сколько это стоило.

Забавная история про то, как я решил разбавить актив в своем чате для друзей, добавив самого настоящего Т-800, который мог бы свободно общаться с участниками, не потратив копейки денег на API - чисто бесплатные модели с OpenRouter. Впрочем, впоследствий была попробована и локальная модель.

Привет, Хабр! Меня зовут Владимир, и это вторая часть цикла статей по написании и обучению небольшой decoder-only LLM с нуля. В первой части мы вытащили текст, обучили Byte-level BPE токенизатор и собрали pretrain-датасет. Теперь напишем сердце модели - трансформер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чек-лист для тестирования поисковых и RAG-систем — от базовой работоспособности поискового движка до качества генерации, агентных сценариев и поведения на неполных данных. Шесть уровней проверок, сводная таблица с инструментами для каждого уровня и глоссарий из 50+ терминов. Проверку стоит организовывать по порядку, нет смысла гонять RAG-метрики, если система не проходит Уровень 0, то проблема может быть в том, что поиск не находит документ из-за опечатки в запросе, а не в качестве генерации.