Как заставить LLM открыть бутылку пива

Всех с пятницей, у кого какие планы? Может, в бар? А LLM с собой возьмете? Пусть тогда откроет бутылку пива за вас. 🍺

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

Что мы имеем
С такими данными будем работать - попробуем открыть бутылку пива.

input_data = [
    {"номер": 1, "название": "пиво", "характеристика": "светлое", "статус": "закрыто"},
    {"номер": 2, "название": "пиво", "характеристика": "светлое", "статус": "закрыто"},
    {"номер": 3, "название": "пиво", "характеристика": "светлое", "статус": "закрыто"},
    {"номер": 4, "название": "пиво", "характеристика": "светлое", "статус": "закрыто"}
]

Как будем ограничивать LLM: Pydantic + Structured Outputs
Некоторые модели (например в ollama) поддерживают структурированные выходные данные через передачу схемы Pydantic (или JSON Schema). Модель гарантирует, что ответ будет строго соответствовать этой схеме — это самый надёжный способ получить валидный JSON нужной структуры.

Почему это работает
Ограничения на генерацию LLM, такие как JSON Schema или Pydantic, работают как "фильтр" или "направляющая" для модели. Вместо того чтобы выбирать любой следующий токен, LLM вынуждена выбирать только те токены, которые соответствуют заранее определённой структуре (например, число, кавычка, конкретное слово из списка). Этот процесс гарантирует, что итоговый текст будет строго соответствовать заданному формату (например, валидному JSON), исключая ошибки структуры.

Как это применить

from pydantic import BaseModel
from typing import Literal
from ollama import chat

class BeerBottle(BaseModel):
    номер: int
    название: str
    характеристика: str
    статус: Literal["открыто", "закрыто"]

class BeerList(BaseModel):
    bottles: list[BeerBottle]

prompt = (
    "Вот список бутылок пива:\n"
    f"{input_data}\n"
    "Открой только две бутылки: вторую и четвертую. "
    "Первая и третья бутылка должны быть закрыты. "
    "Верни результат как список объектов BeerBottle, "
)

response = chat(
    model="gemma3:12b",
    messages=[{'role': 'user', 'content': prompt}],
    format=BeerList.model_json_schema()
)

result = BeerList.model_validate_json(response.message.content)
print(result)

Альтернативные подходы
🟢Можно использовать чистый JSON Schema, минуя Pydantic.
🟢Существуют специальные библиотеки: Outlines, Guidance, JSONFormer — они тоже ограничивают генерацию по схеме.
🟢Можно попробовать добиться нужного формата только промптом, но это менее надёжно.

Важно понимать: большинство "жестких" методов (Pydantic, JSON Schema, грамматики в Guidance/Outlines) основаны на одном и том же принципе — ограничении выбора токенов на этапе генерации.

Так что в следующий раз, когда вам понадобится точный и структурированный ответ от вашей локальной LLM, вспомните про "открытие пивных бутылок" с помощью Pydantic — это действительно работает! Теперь можно и отдохнуть. 🍺

Gemini добавил гендерно-нейтральный вариант в мой код без запроса. Вайб-кодеры, внимание!

Сейчас работаю над одним проектом, и в нём нужно было корректно переделать эту конструкцию под работу с английским языком. Мне было лень, и я воспользовался ассистентом (на базе модели Gemini 2.5 Pro).

Вот что я ему передал:

переведи конструкцию на английский язык для корректной работы с английским языком

prompt_person_sex = {
    'man': """
    перед тобой мужчина, обращайся к нему в мужском роде. 
    """.strip(),

    'woman': """
    перед тобой женщина, обращайся к ней в женском роде. 
    """.strip(),
}

А вот что мне вернула модель 😐:

# Instructions for addressing the person based on gender
gender_address_instructions_en = {
    'male': """
    When addressing the man, use masculine grammatical forms 
    (e.g., pronouns like "he", "him", "his").
    """.strip(),

    'female': """
    When addressing the woman, use feminine grammatical forms 
    (e.g., pronouns like "she", "her", "hers").
    """.strip(),
    
    # Optional entry for neutral or unspecified address
    # 'neutral': """
    # Address the person using gender-neutral or universal phrasing 
    # (e.g., "they", "them", "their", or rephrasing to avoid pronouns).
    # """.strip(),
}

Интересно, что такой «небинарный» вариант модель поставила в «комментарии», сделав его опциональным.
Такой вот JFYI от гугла.

Каковы причины такого дополнения от модели? Это заложенное поведение в виде надстройки, или отражение современных тенденций в данных (видимо, преимущественно на английском языке), на которых она обучалась? Готов поверить в оба варианта

P.S. Лица вайб-кодеров представили? Тех, кто не проверяет, что им пишет LLM 🤣

Улучшаем RAG Pipeline: схема, эксперименты и будущие инсайты

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

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

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

Но! Одно дело - знать о возможных улучшениях, другое - проверить их в деле. Значительную часть подходов с этой схемы мы активно пробуем и тестируем вместе со студентами на семинарах в ВШЭ. Мы проверяем гипотезы, измеряем результаты и выясняем, что действительно работает, а что оказывается не столь эффективным на практике.

Считайте этот пост началом серии. Я планирую постепенно делиться нашими находками и результатами экспериментов прямо здесь. Что вы узнаете:

1️⃣Какие конкретные техники улучшения мы применяли.
2️⃣Какие из них дали заметный прирост качества (и какой именно).
3️⃣Какие оказались менее полезными или даже контрпродуктивными.

Кстати, не только мы ищем пути оптимизации RAG. Недавно коллеги из RedMadRobot поделились на Хабре своими успехами и даже привели конкретные цифры прироста от различных методов. Отличный материал для изучения и сравнения.

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

Всем хороших майских праздников! 🙌

Хватит платить за токены внешних моделей эмбедингов... ну серьезно

Знакомая боль, когда каждый вызов API для эмбеддингов откусывает кусочек от бюджета, особенно если ваши тексты по объему приближаются к «Войне и миру»? Я сам регулярно с этим сталкиваюсь. Но я хочу предложить вам вариант лучше - сэкономить и получить значительно лучшее качество, настроив модель идеально под себя. Локальные решения и fine-tuning реально работают очень хорошо, возвращая вам полный контроль над данными и, что немаловажно, кошельком.

Стоимость обработки больших текстов

Для иллюстрации: объем текста, сопоставимый с «Войной и миром» (1 и 2 том: ~753 000 токенов), при обработке через платные сервисы обойдется примерно в 30 рублей при использовании моделей эмбедингов и около 150 рублей при применении моделей генерации (по ценам ру-рынка). А теперь масштабируем наш «бизнес» на тысячи документов, представили? Локальные решения предлагают бесплатную альтернативу, требуя лишь вычислительных ресурсов (кстати, не таких небольших).

Прирост качества через fine-tuning

Я посмотрел на разные результаты работы fine-tune моделей, оценил метрики после дообучения открытых моделей на специфических данных. Специализированные модели демонстрируют более высокую точность и понимание терминологии в конкретных областях.

Примеры среднего значения uplift метрик на различных языках/задачах после fine-tuning (в сравнении с оригинальной моделью, то, что смог найти в открытых источниках):

1️⃣ Модель: BAAI/bge-m3

- Базовая модель: BAAI/bge-m3 (более 260 fine-tune версий на Hugging Face!)
- Fine-tune версия: nlpai-lab/KURE-v1: +1.36%
- Fine-tune версия: dragonkue/BGE-m3-ko: +13.35%
- Fine-tune версия: AITeamVN/Vietnamese_Embedding: +28.02%

2️⃣ Модель: Alibaba-NLP/gte-Qwen2-1.5B-instruct

- Базовая модель: Alibaba-NLP/gte-Qwen2-1.5B-instruct
- Fine-tune версия: NetoAISolutions/T-VEC +3.05%

3️⃣ Модель: Alibaba-NLP/gte-Qwen2-7B-instruct

- Базовая модель: Alibaba-NLP/gte-Qwen2-7B-instruct
- Fine-tune версия: infly/inf-retriever-v1 +12.42%

4️⃣ Мои тесты

- то, что я пробовал сам, и то что видел у коллег, показывало результаты на домене в среднем +10-20% роста метрик

Кстати, модели выбирал, ориентируясь на MTEB Leaderboard, очень удобно.

Отраслевые и доменно-специфичные модели

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

В русскоязычном сегменте эта ниша менее насыщена; чаще обсуждается применение техник вроде LoRA, которые не всегда являются эквивалентом полноценной доменной адаптации (+1 идея для стартапа 👓).

Какие перспективы

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

Подумайте вот о чем: будущее здесь за теми, кто сможет не просто «взять готовую модель», а предложить тонкую настройку под конкретные бизнес-задачи, обеспечивая реальный, ощутимый результат. Это уже не про экономию на API, это про стратегический выбор и создание по-настоящему конкурентного преимущества

#llm@ml_maxim

Вся суть современных релизов LLM в одной картинке 😂

Почему ваш стартап могут «съесть» за завтраком и как этого избежать

Я на выходных планировал отпуск с Perplexity Labs, и, пока он в реальном времени строил мне графики на Python и искал билеты, я поймал себя на тревожной мысли. Год назад за такой функционал стартап мог поднять миллионы. Сегодня — это фича, которую Google или Microsoft могут встроить в свой продукт за пару месяцев. И это — главная угроза для любого AI-стартапа сегодня.

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

Но как у них это получается? Если заглянуть под капот, окажется, что техническая разница между самыми разными AI-решениями стремится к нулю.

Секретное оружие гигантов: универсальный AI-конструктор

Фундаментальное открытие последних лет заключается в том, что большинство современных AI-агентов строятся из одного и того же набора «кубиков». Переиспользуемость кода и архитектуры между разными доменами очень высока!

Вот этот универсальный blueprint:

1️⃣Large Language Model: Ядро, которое понимает запросы. Ей все равно, обрабатывать запрос про Киото или про котировки акций.
2️⃣RAG Pipeline: Механизм поиска по базе знаний. Ищет информацию об отелях или финансовые отчеты с измеримой и улучшаемой эффективностью.
3️⃣Vector Database: Хранилище эмбеддингов. Хранит векторы для описаний достопримечательностей или исторических цен на акции.
4️⃣Tool Calling API: Способность «дергать» внешние сервисы (покупка билетов, получение данных с биржи).
5️⃣Memory Management: Краткосрочная и долгосрочная память для ведения диалога.
6️⃣Prompt Engineering: Искусство составления правильных запросов.
7️⃣Multi-modal Processing: Умение работать с текстом, картинками, видео.
8️⃣Workflow Orchestration: Координатор, который управляет всеми процессами.

Планирование отпуска и анализ акций используют идентичную техническую основу. Вы просто меняете источники данных в RAG и инструменты в Tool Calling API.

Почему это важно и немного тревожно

Эта универсальность — и есть причина, по которой Big Tech так легко захватывает новые рынки. Им не нужно строить с нуля. У них уже есть готовая, отлаженная инфраструктура. Запустить AI для врачей, имея «универсального AI-солдата», — это задача на несколько месяцев. Стартапу же приходится интегрировать и настраивать весь этот стек, не имея доступа к ресурсам и масштабу Big Tech.

Это объясняет агрессивную стратегию гигантов: Google с AI Mode и Veo, Microsoft с Copilot, Meta с Llama AI. Они не просто конкурируют — они развертывают свои готовые, универсальные платформы на новые территории, которые раньше возделывали стартапы.

Новая точка дифференциации: где прячется уникальность?

Если 95% архитектуры — это commodity, то где стартапу искать свое конкурентное преимущество? Оно прячется в оставшихся 5%:

🔵 Уникальные данные: Ваш RAG-пайплайн должен быть запитан эксклюзивными, глубокими и качественными данными, которых нет у Google (только не сливайте их по API!).
🔵 Специализированные инструменты: Ваш агент должен уметь вызывать уникальные API, которые решают специфическую боль в узкой нише.
🔵 Доменная экспертиза: Ваши промпты, fine-tuning модели и логика workflow должны отражать глубокое понимание предметной области, недоступное универсальным системам.

Вывод, к которому я пришел: гонка за создание «самой лучшей» универсальной архитектуры для стартапов проиграна. Будущее за теми, кто сможет взять этот универсальный конструктор и создать на его основе глубоко специализированное, незаменимое решение. Ценность сместилась от технологии к данным и экспертизе

P.S. Картинка из отчета по отпуску в Японию

⬆️⬆️⬆️

Ура, анонс ☺️ Никита показал то, над чем мы небольшой командой горели последнее время. В этот курс вложено невероятное количество сил

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

Пост назад я уже приоткрыл «внутреннюю кухню» подготовки, а скоро покажу еще пару интересных примеров

Главный баг Software 3.0

Представьте: вы пишете идеальный промпт, получаете блестящий код, а на следующий день тот же промпт выдает полную ерунду. Добро пожаловать в Software 3.0 - эру, где Андрей Карпатый (мой любимый вайб кодер) предсказал (вот его крутое выступление), что промпты станут новым «языком программирования». Но у этой революции есть фундаментальная проблема, с которой сталкивается каждый, кто пытался получить от модели два одинаковых ответа подряд

Главный парадокс Software 3.0 в том, что переход к простому языку привел к сложной проблеме - невозможности точно воспроизвести результат. Даже при temperature = 0 (режим, который должен быть максимально детерминированным) модели ведут себя непредсказуемо. Исследования показывают, что вариации в точности ответов от запуска к запуску могут достигать 15%. Откуда берется эта случайность?

➡️ Три уровня недетерминированности LLM
Проблема воспроизводимости - это не просто баг, который можно исправить. Она заложена в саму природу современных вычислений на нескольких уровнях

1. Аппаратный уровень
Когда вы запускаете модель на GPU, вы имеете дело с тысячами параллельных ядер. Из-за особенностей архитектуры и арифметики с плавающей запятой, результат операции (a + b) + c не всегда равен a + (b + c). Порядок выполнения этих микроопераций может меняться от запуска к запуску в зависимости от того, какое ядро закончило вычисления на наносекунду раньше

2. Программный уровень
Библиотеки вроде PyTorch и cuDNN, на которых работают все современные модели, содержат алгоритмы, которые по своей природе недетерминистичны. Например, некоторые операции свертки или пулинга специально сделаны такими для повышения скорости. Разработчики сознательно идут на компромисс, жертвуя воспроизводимостью ради производительности

3. Архитектурный уровень
Современные модели используют архитектуру Mixture-of-Experts (MoE). Представьте, что это команда из нескольких узкопрофильных специалистов (экспертов). Для обработки вашего запроса модель выбирает нескольких наиболее подходящих. Но из-за сложной внутренней маршрутизации, в следующий раз для точно такого же запроса может быть выбран немного другой состав «команды экспертов», что приведет к иному результату

А есть примеры из жизни?
Пример 1️⃣
Недавно показали игровой движок Hunyuan GameCraft от Tencent. Он способен в реальном времени генерировать игровые сцены, но разработчики столкнулись с ключевой дилеммой: либо мир стабилен, но плохо реагирует на действия игрока, либо он отзывчив, но постоянно «плывет» и теряет консистентность. Наглядный пример недетерминированности на практике

Пример 2️⃣
Концепт Gemini Computer от Google. Это операционная система, где каждый элемент интерфейса генерируется LLM на лету. Выглядит футуристично, но в их же демо отлично видно фундаментальную проблему: генерация изначально не подразумевает строгой воспроизводимости. Кнопка «Сохранить», которая была слева, после следующего клика может оказаться справа или вообще изменить название

Пример 3️⃣
Проблему накопления ошибок в LLM отлично иллюстрирует аналогия с квантовыми компьютерами. Представьте, что точность одной квантовой операции - 99%. Звучит неплохо. Но если для вычисления нужно провести 1000 таких операций, общая надежность падает до 0.99^1000, что практически равно нулю. С LLM происходит то же самое: при генерации длинного текста или кода крошечные отклонения накапливаются, и финальный результат «уплывает» далеко от первоначального замысла

➡️ GitLab для эпохи Software 3.0
Так что же делать в этом дивном новом мире?

Лично мне видится решение в виде надстройки для привычных систем вроде GitLab, которая будет версионировать не одну, а сразу три плоскости нашего проекта:

🔵Код - финальный артефакт, как и сейчас
🔵Промпт - инструкция, которая сгенерировала этот код
🔵Модель - конкретная версия LLM (например, Gemini 2.5 Flash Preview 04-17)

Это позволит отслеживать всю цепочку создания продукта и откатываться к стабильной связке «промпт-модель»

Эпоха Software 3.0 требует новых инструментов, и, похоже, нам предстоит их создать 💪

BERTScore vs косинус: лайфхак для подготовки к конференции с помощью алгоритмов RAG-а

Недавно готовился к выступлению на AhaConf, а это, на минуточку, 70+ спикеров и 1000+ слушателей. Сразу возникает классическая проблема: как сделать свой доклад уникальным и не повторить то, что уже рассказали до тебя?

Многие думают, что RAG - это какая-то сложная штука для enterprise-задач. Но на деле это просто очень здравый подход к работе с информацией. И я применил его при подготовке к выступлению: нашел релевантные данные (Retrieval) в программе конференции, чтобы улучшить свое выступление. Получился такой RAG для одного человека

Зачем вообще искать похожие доклады?

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

1️⃣Дифференцироваться от коллег. Найти тех, кто говорит на смежные темы, чтобы скорректировать свой доклад, добавить уникальности и не лить воду, которую слушатели уже слышали

2️⃣Нетворкинг. Заранее вычислить «своих» по духу и темам. С таким списком можно подходить в кулуарах не с банальным «чем занимаешься?», а с конкретным «слушай, видел твой доклад про X, у меня как раз очень похожий кейс»

План эксперимента: старый добрый косинус против BERTScore

Мой план был прост:

1️⃣Собрать данные: выгрузить все названия и описания докладов

2️⃣Измерить близость: прогнать каждый доклад через два фильтра для сравнения с моим - старую добрую косинусную близость и более «вдумчивый» BERTScore

3️⃣Проанализировать топ-5 от каждого метода и посмотреть, какие доклады попали в топ

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

И вот тут-то и проявилась вся разница подходов

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

BERTScore. Этот подход работает на более детальном уровне, сопоставляя контекстные эмбеддинги каждого токена из одного текста с токенами другого. На основе этой матрицы попарных сходств он вычисляет метрику F1, что позволяет улавливать локальные семантические связи, например, между «ML-платформой» и «автоматизацией ресурсов», даже при отсутствии общих ключевых слов. (подробнее в оригинальной статье «BERTScore: Evaluating Text Generation with BERT»). Но из-за циклично расчета эмбедингов время получения метрики растет в разы

Главный вывод: дилемма близости в RAG - скорость или глубина?

Мой эксперимент отлично подсветил классический компромисс в мире RAG: выбор между скоростью и семантической глубиной. Здесь нет однозначного победителя, потому что косинусная близость и BERTScore решают разные задачи

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

Если бы кто-то придумал «быстрый BERTScore», это бы кардинально изменило подходы к поиску релевантных чанков в RAG. Мы бы получили поиск, который по-настоящему понимает запрос. Но пока приходится жить в мире компромиссов

А для тех, кто хочет провести похожий анализ, я, по традиции, выложил весь код в репозиторий. Забирайте и экспериментируйте 💪

Как школьники решают задачи по AI на уровне магистров

В пятницу провел четырехчасовую тренировку для наших школьников, которые едут на Международную олимпиаду по ИИ (IOAI), и до сих пор под впечатлением. Задачи - серьезные, на уровне магистров: CV, NLP, классика на таблицах. Но поразил меня не столько уровень решений, сколько один паттерн, который прослеживался почти везде

Есть один инструмент, который ребята использовали в ~85% случаев. Угадаете какой? Конечно, CatBoost. Его умудрялись прикрутить даже для классификации картинок и анализа текстов. И это не от лени или незнания других архитектур. Это прагматизм в чистом виде: если инструмент достаточно гибкий и мощный, чтобы решать 85% задач «в лоб», зачем усложнять? С определенными трюками такой подход для олимпиады - самое то

Я, честно говоря, не могу вспомнить ни одного знакомого DS-а из IT-компаний, у кого бы в проде не стоял CatBoost в том или ином виде 🧐

Вся эта подготовка - финальный рывок перед главным событием. Олимпиада пройдет со 2 по 9 августа в Пекине. Это огромное достижение для ребят - представлять страну на таком уровне. Буду внимательно следить за успехами нашей команды, а значит и вы тоже ✨

P.S. Хотите узнать, какие вопросы о внутреннем устройстве CatBoost я задаю на собеседованиях, чтобы проверить глубину понимания, а не просто знание .fit() и .predict()? Накидайте реакций 🔥, и я напишу об этом отдельный пост

P.P.S Ребят курирует Саша, он пишет о всех тонкостях процесса довольно часто