Natural Language Processing *

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

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

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

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

Каждую ночь у нас в 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, то проблема может быть в том, что поиск не находит документ из-за опечатки в запросе, а не в качестве генерации.

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

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

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

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