Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
MCP: как LLM вообще ходит во внешние сервисы
#Протоколы_в_агентах
Давно для себя хотел разобраться с агентскими протоколами(на уровне того, чтобы я с легкостью мог обьяснить), наконец-то дошли руки, поэтому работаем💳
Зачем в целом нужны протоколы?🔫
Главное, что отличает агентов от вызовов LLM, так это возможности взаимодействия с внешней средой. Вот именно для того, чтобы не писать под каждую интеграцию отдельный код, нужны протокол. MCP решает эту проблему, предоставляя LLM стандартизированный способ подключения к внешним источникам данных и инструментам
Как работает MCP🤨
Когда пользователь взаимодействует с хост-приложением (приложением ИИ), поддерживающим MCP, за кулисами происходит несколько процессов, обеспечивающих быструю и бесперебойную связь между ИИ и внешними системами. Давайте подробнее рассмотрим, что происходит, когда пользователь просит Claude Desktop выполнить задачу, которая вызывает инструменты за пределами окна чата.
Основные компоненты MCP😁
- Приложение с ИИ: Claude Desktop, IDE-плагин, веб-чат — всё это хосты, которые держат LLM и общаются с пользователем.
- Встроенный клиент MCP: устанавливает соединения с MCP-серверами, переводит запросы из мира приложения в формат протокола
- MCP-сервер: он описывает: какие есть resources, tools, подсказки (prompts).
- Транспортный уровень
Как именно клиент и сервер общаются:
STDIO — локально, когда сервер живёт рядом (CLI, локальные тулзы).
HTTP + SSE — удалённо, когда нужен сетевой доступ и стриминг ответов.
Протокол рукопожатия😧
1. Первоначальное подключение: при запуске клиента MCP (например, Claude Desktop) он подключается к настроенным серверам MCP на вашем устройстве.
2. Обнаружение возможностей: клиент спрашивает каждый сервер: «Какие возможности вы предлагаете?» Каждый сервер отвечает доступными ему инструментами, ресурсами и подсказками.
3. Регистрация: Клиент регистрирует эти возможности, делая их доступными для использования ИИ во время разговора.
Путь нашего запроса😮
1. При получении нашего запроса, LLM решает, какие инструменты дернуть и составляет план.
2. Клиент MCP отправляет на сервер: имя инструмента, параметры (например, repo, branch, фильтры), контекст (ID сессии и т.п.)
3. Далее происходит выполнение на стороне сервиса и оборачивает результат в стандартизированный ответ MCP
4. С помощью модели форматируем ответ и получаем нужный нам результат
Фух, примерно так) Надеюсь вам понравится данный пост, жду в комментариях ваш опыт использования MCP
💗 - рассказать про ACP
#Протоколы_в_агентах
Давно для себя хотел разобраться с агентскими протоколами(на уровне того, чтобы я с легкостью мог обьяснить), наконец-то дошли руки, поэтому работаем
Зачем в целом нужны протоколы?
Главное, что отличает агентов от вызовов LLM, так это возможности взаимодействия с внешней средой. Вот именно для того, чтобы не писать под каждую интеграцию отдельный код, нужны протокол. MCP решает эту проблему, предоставляя LLM стандартизированный способ подключения к внешним источникам данных и инструментам
Как работает MCP
Когда пользователь взаимодействует с хост-приложением (приложением ИИ), поддерживающим MCP, за кулисами происходит несколько процессов, обеспечивающих быструю и бесперебойную связь между ИИ и внешними системами. Давайте подробнее рассмотрим, что происходит, когда пользователь просит Claude Desktop выполнить задачу, которая вызывает инструменты за пределами окна чата.
Основные компоненты MCP
- Приложение с ИИ: Claude Desktop, IDE-плагин, веб-чат — всё это хосты, которые держат LLM и общаются с пользователем.
- Встроенный клиент MCP: устанавливает соединения с MCP-серверами, переводит запросы из мира приложения в формат протокола
- MCP-сервер: он описывает: какие есть resources, tools, подсказки (prompts).
- Транспортный уровень
Как именно клиент и сервер общаются:
STDIO — локально, когда сервер живёт рядом (CLI, локальные тулзы).
HTTP + SSE — удалённо, когда нужен сетевой доступ и стриминг ответов.
Протокол рукопожатия
1. Первоначальное подключение: при запуске клиента MCP (например, Claude Desktop) он подключается к настроенным серверам MCP на вашем устройстве.
2. Обнаружение возможностей: клиент спрашивает каждый сервер: «Какие возможности вы предлагаете?» Каждый сервер отвечает доступными ему инструментами, ресурсами и подсказками.
3. Регистрация: Клиент регистрирует эти возможности, делая их доступными для использования ИИ во время разговора.
Путь нашего запроса
1. При получении нашего запроса, LLM решает, какие инструменты дернуть и составляет план.
2. Клиент MCP отправляет на сервер: имя инструмента, параметры (например, repo, branch, фильтры), контекст (ID сессии и т.п.)
3. Далее происходит выполнение на стороне сервиса и оборачивает результат в стандартизированный ответ MCP
4. С помощью модели форматируем ответ и получаем нужный нам результат
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
Новая хайповая вещь: SGR
Что такое SGR и какую проблему он решает💃
До сих пор проблема галлюцинирования LLM является самой большой пробемой всех инженеров, которые с ними работают. К тому же модель периодически может отвечать по разному и желание зафиксировать ответ, особенно для локальных моделей, является очень большим вызовом. Для решения этой задачи появился подход Schema-Guided Reasoning (SGR). Идея проста и эффективна: заставить модель мыслить не хаотично, а внутри заданной схемы.
Как он работает🍑
В SGR схема — это структурированное описание того, как модель должна рассуждать. Обычно её задают через Pydantic-модели или JSON-схемы, где для каждого элемента указаны тип данных и описание.
SGR использует структурированный вывод и ограниченное декодирование. Проще говоря, с помощью такого вывода модель может выдать ответ только в том виде, который заранее определили. Например, если в схеме указано, что final_answer должно быть числом, модель не напишет там «около сорока» или «сложно сказать». Она будет вынуждена предоставить конкретное число в нужном формате.
Схема не «зажимает» модель, а даёт ей понятный алгоритм. Это похоже на чек-лист доктора: сначала собрать симптомы и проверить показатели, потом выдвинуть гипотезы и назначить анализы и лишь затем ставит диагноз. Модель может думать как хочет, но в итоге обязана заполнить все поля.
Что мы получаем:
1. Предсказуемость ответа
2. Большую интерпретируемость
3. Возможность добавлять экспертные данные внутри схемы, не теряя контекст
Паттерны работы👍
1️⃣ Каскад
Каскад подходит, когда задачу можно разбить на последовательные этапы, где каждый следующий шаг зависит от предыдущего. Например, при анализе текста: сначала краткое содержание, затем оценка качества и только потом итоговая рекомендация.
2️⃣ Маршрутизация
Маршрутизация нужна, когда заранее неизвестен тип входящей задачи. Например, нужно проанализировать юридические, финансовые или технические документы. Каждому типу нужен свой алгоритм разбора.
3️⃣ Цикл
Цикл полезен, когда результат нужно постепенно уточнять. Модель выдвигает гипотезу, затем сама её проверяет — ищет противоречия — и при необходимости пересматривает ответ. Это похоже на процесс редактирования: черновик, правки, готовый вариант.
Что почитать🤑
1️⃣ Schema-Guided Reasoning: как научить языковые модели последовательно рассуждать
2️⃣ Schema-Guided Reasoning (SGR) от создателя этой технологии
3️⃣ SGR Agent Core — the first SGR open-source agentic framework for Schema-Guided Reasoning
Что такое SGR и какую проблему он решает
До сих пор проблема галлюцинирования LLM является самой большой пробемой всех инженеров, которые с ними работают. К тому же модель периодически может отвечать по разному и желание зафиксировать ответ, особенно для локальных моделей, является очень большим вызовом. Для решения этой задачи появился подход Schema-Guided Reasoning (SGR). Идея проста и эффективна: заставить модель мыслить не хаотично, а внутри заданной схемы.
Как он работает
В SGR схема — это структурированное описание того, как модель должна рассуждать. Обычно её задают через Pydantic-модели или JSON-схемы, где для каждого элемента указаны тип данных и описание.
from pydantic import BaseModel
from typing import List
class MathReasoning(BaseModel):
problem: str
steps: List[str]
final_answer: float
SGR использует структурированный вывод и ограниченное декодирование. Проще говоря, с помощью такого вывода модель может выдать ответ только в том виде, который заранее определили. Например, если в схеме указано, что final_answer должно быть числом, модель не напишет там «около сорока» или «сложно сказать». Она будет вынуждена предоставить конкретное число в нужном формате.
Схема не «зажимает» модель, а даёт ей понятный алгоритм. Это похоже на чек-лист доктора: сначала собрать симптомы и проверить показатели, потом выдвинуть гипотезы и назначить анализы и лишь затем ставит диагноз. Модель может думать как хочет, но в итоге обязана заполнить все поля.
Что мы получаем:
1. Предсказуемость ответа
2. Большую интерпретируемость
3. Возможность добавлять экспертные данные внутри схемы, не теряя контекст
Паттерны работы
Каскад подходит, когда задачу можно разбить на последовательные этапы, где каждый следующий шаг зависит от предыдущего. Например, при анализе текста: сначала краткое содержание, затем оценка качества и только потом итоговая рекомендация.
class TextAnalysis(BaseModel):
summary: str
quality_rating: int
final_recommendation: str
Маршрутизация нужна, когда заранее неизвестен тип входящей задачи. Например, нужно проанализировать юридические, финансовые или технические документы. Каждому типу нужен свой алгоритм разбора.
class DocumentAnalysis(BaseModel):
document_type: str # "legal", "financial", "technical"
analysis_result: dict
Цикл полезен, когда результат нужно постепенно уточнять. Модель выдвигает гипотезу, затем сама её проверяет — ищет противоречия — и при необходимости пересматривает ответ. Это похоже на процесс редактирования: черновик, правки, готовый вариант.
class ComplianceAnalysis(BaseModel):
hypothesis: str
verification_questions: List[str]
final_verdict: str
Что почитать
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DeepSchool
Attention и трансформеры в NLP: что спрашивают на собеседованиях
Механизм внимания — важный компонент современных DL-архитектур и популярная тема на собеседованиях на позицию DL-инженера.
В новой статье разобрали частые вопросы про attention и трансформеры с NLP-собеседований. Вопросы разбиты на тематические модули, а ответы на них спрятаны под спойлерам, прежде чем раскрыть их, попробуйте ответить сами.😉
Читайте статью по ссылке!
Механизм внимания — важный компонент современных DL-архитектур и популярная тема на собеседованиях на позицию DL-инженера.
В новой статье разобрали частые вопросы про attention и трансформеры с NLP-собеседований. Вопросы разбиты на тематические модули, а ответы на них спрятаны под спойлерам, прежде чем раскрыть их, попробуйте ответить сами.😉
Читайте статью по ссылке!
А чтобы уметь применять Attention и трансформеры в реальных продуктах под нагрузкой — приходите на наш курс LLM Pro.
Старт — 13 ноября.
Читайте подробнее на сайте и оставляйте заявку до 2 ноября, чтобы присоединиться к обучению со скидкой до 20% ⚡
DeepSchool
Attention и трансформеры в NLP: что спрашивают на собеседованиях - DeepSchool
Разобрали частые вопросы про attention и трансформеры с NLP собеседований
Forwarded from DeepSchool
LoRA: краткий гайд перед собеседованием
Full fine‑tuning LLM — дорого и медленно. Если хочется дообучать LLM быстрее и дешевле, один из вариантов — Low‑Rank Adaptation (LoRA).
Идея подхода состоит в обучении компактных добавок к весам модели и оставлении базовых весов замороженными. Этот подход позволяет дообучить модель, сэкономив ресурсы на обучение, а скорость инференса останется как у оригинальной модели.
📌 Принцип работы LoRA
Линейный слой — матрица весов W размером d×d (для простоты рассматриваем квадратную). При full fine‑tuning для неё обновляется d² элементов. В LoRA веса остаются замороженными, а обучается только добавка ΔWᵈˣᵈ, которая является произведением матриц Bᵈˣʳ и Aʳˣᵈ. Выход h для линейного слоя с новой добавкой вычисляется по формуле:
h = Wx + (α / r) ∆Wx
где:
Часто LoRA-адаптеры добавляют к линейным проекциям attention — query_proj и value_proj. Для большего качества можно добавить и к другим элементам блока трансформера, например, к MLP или output_proj.
Применение:
• При дообучении LLM для сервисов поиска с RAG, корпоративных ассистентов, мультиязычных моделей и др.
• Также популярен сценарий использования одной базовой LLM с несколькими адаптерами (multi-LoRA) под разные домены и клиентов.
📝Частые вопросы с собеседований
🔗 Полезные ссылки
• Оригинальная статья LoRA
• QLoRA
• Документация huggingface по LoRA
Автор: Алексей Яндутов
Full fine‑tuning LLM — дорого и медленно. Если хочется дообучать LLM быстрее и дешевле, один из вариантов — Low‑Rank Adaptation (LoRA).
Идея подхода состоит в обучении компактных добавок к весам модели и оставлении базовых весов замороженными. Этот подход позволяет дообучить модель, сэкономив ресурсы на обучение, а скорость инференса останется как у оригинальной модели.
📌 Принцип работы LoRA
Линейный слой — матрица весов W размером d×d (для простоты рассматриваем квадратную). При full fine‑tuning для неё обновляется d² элементов. В LoRA веса остаются замороженными, а обучается только добавка ΔWᵈˣᵈ, которая является произведением матриц Bᵈˣʳ и Aʳˣᵈ. Выход h для линейного слоя с новой добавкой вычисляется по формуле:
h = Wx + (α / r) ∆Wx
где:
• x — входной вектор размерностью d;
• ∆W = BA, Aʳˣᵈ и Bᵈˣʳ — обучаемые матрицы весов, где r значительно меньше d. Таким образом, в LoRA обучаются 2*d*r параметров, то есть намного меньше, чем при full finetuning.
• α/r регулирует вклад адаптера:
- r — ёмкость адаптера. Чем она больше, тем сильнее обновления, но тем выше риск переобучения и стоимость шага обучения (время и VRAM). На практике начинают со значений в диапазоне от 4 до 32, при сложных задачах можно увеличить до 64.
- α — масштабирует вклад обновлений LoRA-адаптера. Здесь часто начинают с α = r. Если модель переобучается или градиенты нестабильны, можно уменьшать α (или добавить dropout). Главное — при изменении r держать α/r постоянным: если растет r, то α должен вырасти пропорционально.
Часто LoRA-адаптеры добавляют к линейным проекциям attention — query_proj и value_proj. Для большего качества можно добавить и к другим элементам блока трансформера, например, к MLP или output_proj.
Применение:
• При дообучении LLM для сервисов поиска с RAG, корпоративных ассистентов, мультиязычных моделей и др.
• Также популярен сценарий использования одной базовой LLM с несколькими адаптерами (multi-LoRA) под разные домены и клиентов.
📝Частые вопросы с собеседований
• Зачем матрица обновления ΔW раскладывается на произведение A и B ? Почему бы не использовать одну матрицу?
Если в качестве добавки использовать одну матрицу размером d × d — экономии не будет. Факторизация на Aʳˣᵈ и Bᵈˣʳ, где r значительно меньше d, сокращает количество обучаемых параметров и ускоряет обучение.
• Преимущества LoRA vs классические адаптеры?
LoRA не добавляет новых слоёв на инференсе, как в классических адаптерах, где из-за этого растёт latency и потребление памяти. Здесь их можно смержить в базовые веса, сложив по формуле и убрав накладные расходы на инференсе.
• Когда выбирать LoRA?
◦ Нужно дообучение при ограниченных ресурсах
Даже при 1-2 GPU по 24 GB можно дообучать модели размером 8b c LoRA и 30b с QLoRA, где базовая модель квантуется до 4-бит (NF4).
◦ Нужны лёгкие артефакты или быстрое переключение между доменами
LoRA-адаптеры — небольшие добавочные веса, которые легко подмешиваются / меняются на инференсе. Можно держать адаптеры для разных доменов (например, «техподдержка», «юридический стиль», «код») и по запросу активировать нужный (multi-LoRA).
◦ Важно не удлинять ввод на инференсе
В отличие от prompt / prefix-методов, которые добавляют позиции / KV-префиксы, увеличивают вычисления и KV-кэш, LoRA не меняет длину последовательности. А это критично для latency.
◦ Промптинг не даёт нужного качества или стабильного поведения
Если улучшение промпта не решает задачу, LoRA даёт более стабильное поведение и прирост качества при минимуме обучаемых параметров.
🔗 Полезные ссылки
• Оригинальная статья LoRA
• QLoRA
• Документация huggingface по LoRA
А чтобы знать, как применять finetuning для адаптации LLM под домен в реальном проекте — приходите на наш курс LLM Pro.
Старт — 13 ноября.
Читайте подробнее на сайте и оставляйте заявку до 12 ноября, чтобы присоединиться к обучению со скидкой 5% ⚡️
Автор: Алексей Яндутов
Forwarded from DeepSchool
Персонализированная генерация: Textual Inversion и DreamBooth
Персонализированная генерация добавляет новые концепции в такие генеративные модели, как Stable Diffusion. С ней можно создавать изображения с определённым объектом или художественным стилем, которые модель не видела раньше.
В новой статье расскажем, как работают базовые алгоритмы персонализированной генерации — Textual Inversion и DreamBooth 🧙♂️
А также рассмотрим:
- какие существуют проблемы наивных подходов
- как алгоритмы добавляют концепт в модель по пяти примерам
- визуализацию работы алгоритмов
Читайте новую статью по ссылке! 👈
🪔 DeepSchool
Персонализированная генерация добавляет новые концепции в такие генеративные модели, как Stable Diffusion. С ней можно создавать изображения с определённым объектом или художественным стилем, которые модель не видела раньше.
В новой статье расскажем, как работают базовые алгоритмы персонализированной генерации — Textual Inversion и DreamBooth 🧙♂️
А также рассмотрим:
- какие существуют проблемы наивных подходов
- как алгоритмы добавляют концепт в модель по пяти примерам
- визуализацию работы алгоритмов
Читайте новую статью по ссылке! 👈
Please open Telegram to view this post
VIEW IN TELEGRAM
DeepSchool
Персонализированная генерация: Textual Inversion и DreamBooth - DeepSchool
Рассказываем, как работают базовые алгоритмы генерации — Textual Inversion и DreamBooth
Forwarded from Data Funk
Традиционно эмбеддинги получаем нейросетями. Если хотите "экологически чистые" эмбединги🌳, то ребята из Королёвского колледжа Лондона сделали "деревянный" автоэнкодер. В отличие от классического варианта, тут кодер и декодер учатся независимо.
Кодер работает как GAN: лес учится отличать реальные данные от синтетических, а из его листьев-ошибок семплируются всё более правдоподобные точки. После нескольких итераций лес перестает их различать. Так модель учит внутреннюю структуру данных. Затем для n точек строится матрица близости K (насколько часто пары точек попадают в один лист). В простом варианте первые d собственных векторов (V) и значений (Λ) этой матрицы формируют d-мерные эмбеддинги: Z = √n*V*Λ.
Декодер это просто k-nn в пространстве эмбеддингов: чтобы восстановить объект по эмбеддингу, берём k ближайших точек из обучающей выборки и усредняем их фичи (берём моду для категорий).
Что бы получить эмбеддинг новый точки из test набора ищем ее близость к тем же n точкам - K' и умножаем на собственные вектора: Z' = √n*K'*V.
Всё без градиентов, только 🌲🌳🪵!
Кодер работает как GAN: лес учится отличать реальные данные от синтетических, а из его листьев-ошибок семплируются всё более правдоподобные точки. После нескольких итераций лес перестает их различать. Так модель учит внутреннюю структуру данных. Затем для n точек строится матрица близости K (насколько часто пары точек попадают в один лист). В простом варианте первые d собственных векторов (V) и значений (Λ) этой матрицы формируют d-мерные эмбеддинги: Z = √n*V*Λ.
Декодер это просто k-nn в пространстве эмбеддингов: чтобы восстановить объект по эмбеддингу, берём k ближайших точек из обучающей выборки и усредняем их фичи (берём моду для категорий).
Что бы получить эмбеддинг новый точки из test набора ищем ее близость к тем же n точкам - K' и умножаем на собственные вектора: Z' = √n*K'*V.
Всё без градиентов, только 🌲🌳🪵!
Forwarded from Applied AI by David
Перечитал полностью docs+api refs openai,anthropic,gemini,grok,cerebras,groq,deepseek,litellm,openrouter вместо вас
Последний раз читал год назад. Тогда рассказывали про кэширование, ризонинг - решил изучить, что сейчас есть "перспективного" в апихах
- в конце текста вам подарок
из прикольного:
- грок берет 5 центов штрафа если запрос "улетел в этику"
- openai responses api boost accuracy in 3% by mean (comparing to completions api)
- (старая фича) открыл для себя predicted outputs = можно вывести в ответ текст в 10к токенов, при этом генерироваться будет лишь малая часть (стоит чуть дороже, но работает сильно быстрее)
- prefill output позволяет начинать ответ с правильного персонажа/текста etc., сразу пропуская "преамбулу"
- грок апи самый бедный по фичам, ниче нет, даже батч апи без скидки
- у image-edit моделей есть МАСКИ на вход (нативно и параметром!)
- у опенаи есть прикольный flex tier, понижающий стоимость в 2 раза (по-другому поданный batching)
- батч+кэш = скидка до 95% = платим меньше или юзаем модели больше
- работать с видео не так уж и дорого, если использовать самые крошечные модели + батчинг + кэширование
- o3 (и выше) умеют ДУМАТЬ картинками (в процессе размышлений рассматриваются участки изображения, например модель может приблизить картинку в каком-то месте и рассмотреть подробнее (н. прочитать мелкий текст)
- у gpt-image есть параметр input_fidelity=high, который превращает ее в ультимативный фотошоп - есть ощущение, что на аренах он отключен
- у gpt-image есть параметр для прозрачности фона: auto/transparent/opaque
- анторпик дает несколько чекпоинтов для кэширования промптов
- на оперрутере есть моделька cognitivecomputations/dolphin-mistral-24b-venice-edition:free (uncensored)
- в опенаи ответ можно получать на вебхук (не батчевый!)
- VLM очень точно возвращают box_2d (границы предметов на изображении, относительными координатами) [проверил гугл, тропик, оаи]
- image-edit модели очень точно создают маску для объекта
- (на всякий случай решил напомнить) у tool_call_mode есть режим required
- у дипсика есть fill in the middle completion (блин это очень круто, представляю сколько всего надо было сделать ради этой фичи)
- антропик упоминает у себя XML промптинг среди самых мощных техник
- в api gigachat&yandexgpt всё еще нет кучи параметров начиная с банальных stop, что даже хз что говорит о продактах (или их ресурсах) - под капотом в моделях больше 100 параметров по управлению "пулом токенов для генерации" (в я. в конце 2025 года так вообще кроме температуры ничего нет)
- proprietary vlm's находятся в больгинстве на уровне понимания изображений, сопоставимом с уровнем пониманием текста gpt-3.5. Все еще хорошо работают техники с ролями "You have perfect vision and pay great attention to detail" (прочитал 20+ статей по vlm за неделю, напишите в комменты если нужен пост на эту тему)
- про текущие VLM: поворот изображения = смерть. изменение экспозиции = смерть. изменение освещения = смерть. spatial understanding & counting везде слабый. ждем обучение на videogen моделях
- фичами в апи обычно занимаются целые команды, поэтому у маленьких провайдеров типа groq/cerebras/etc нет почти никаких фич - паттерн
- гемини 2.5 поддерживает сегментацию из коробки (шок) (возвращает label + box_2d + base64 маску для каждого объекта)
- gemini несовместим с reasoning_effort в litellm и кажется не будет
- подарок: все дают 0.1-1тб бесплатного диска для files api, который можно использовать для каких угодно задач = можно на все аккаунты наспамить себе хранилищ
А еще сильно разочаровался в litellm. Про это будет следующий пост
Последний раз читал год назад. Тогда рассказывали про кэширование, ризонинг - решил изучить, что сейчас есть "перспективного" в апихах
- в конце текста вам подарок
из прикольного:
- грок берет 5 центов штрафа если запрос "улетел в этику"
- openai responses api boost accuracy in 3% by mean (comparing to completions api)
- (старая фича) открыл для себя predicted outputs = можно вывести в ответ текст в 10к токенов, при этом генерироваться будет лишь малая часть (стоит чуть дороже, но работает сильно быстрее)
- prefill output позволяет начинать ответ с правильного персонажа/текста etc., сразу пропуская "преамбулу"
- грок апи самый бедный по фичам, ниче нет, даже батч апи без скидки
- у image-edit моделей есть МАСКИ на вход (нативно и параметром!)
- у опенаи есть прикольный flex tier, понижающий стоимость в 2 раза (по-другому поданный batching)
- батч+кэш = скидка до 95% = платим меньше или юзаем модели больше
- работать с видео не так уж и дорого, если использовать самые крошечные модели + батчинг + кэширование
- o3 (и выше) умеют ДУМАТЬ картинками (в процессе размышлений рассматриваются участки изображения, например модель может приблизить картинку в каком-то месте и рассмотреть подробнее (н. прочитать мелкий текст)
- у gpt-image есть параметр input_fidelity=high, который превращает ее в ультимативный фотошоп - есть ощущение, что на аренах он отключен
- у gpt-image есть параметр для прозрачности фона: auto/transparent/opaque
- анторпик дает несколько чекпоинтов для кэширования промптов
- на оперрутере есть моделька cognitivecomputations/dolphin-mistral-24b-venice-edition:free (uncensored)
- в опенаи ответ можно получать на вебхук (не батчевый!)
- VLM очень точно возвращают box_2d (границы предметов на изображении, относительными координатами) [проверил гугл, тропик, оаи]
- image-edit модели очень точно создают маску для объекта
- (на всякий случай решил напомнить) у tool_call_mode есть режим required
- у дипсика есть fill in the middle completion (блин это очень круто, представляю сколько всего надо было сделать ради этой фичи)
- антропик упоминает у себя XML промптинг среди самых мощных техник
- в api gigachat&yandexgpt всё еще нет кучи параметров начиная с банальных stop, что даже хз что говорит о продактах (или их ресурсах) - под капотом в моделях больше 100 параметров по управлению "пулом токенов для генерации" (в я. в конце 2025 года так вообще кроме температуры ничего нет)
- proprietary vlm's находятся в больгинстве на уровне понимания изображений, сопоставимом с уровнем пониманием текста gpt-3.5. Все еще хорошо работают техники с ролями "You have perfect vision and pay great attention to detail" (прочитал 20+ статей по vlm за неделю, напишите в комменты если нужен пост на эту тему)
- про текущие VLM: поворот изображения = смерть. изменение экспозиции = смерть. изменение освещения = смерть. spatial understanding & counting везде слабый. ждем обучение на videogen моделях
- фичами в апи обычно занимаются целые команды, поэтому у маленьких провайдеров типа groq/cerebras/etc нет почти никаких фич - паттерн
- гемини 2.5 поддерживает сегментацию из коробки (шок) (возвращает label + box_2d + base64 маску для каждого объекта)
- gemini несовместим с reasoning_effort в litellm и кажется не будет
- подарок: все дают 0.1-1тб бесплатного диска для files api, который можно использовать для каких угодно задач = можно на все аккаунты наспамить себе хранилищ
А еще сильно разочаровался в litellm. Про это будет следующий пост
Forwarded from Душный NLP
Kimi K2 — огромная модель с интересными решениями «под капотом»
Сегодня разберём статью о MoE-модели Kimi K2 на триллион параметров. У Kimi в полтора раза больше экспертов, чем у DeepSeek-V3 — 384 против 256. А ещё — в два раза меньше голов аттеншена — 64 против 128.
Создатели вводят понятие sparsity — это разница между общим количеством экспертов и активными экспертами. Так, у Kimi K2 sparsity 48, а у DeepSeek-V3 — 36. Авторы утверждают, что при увеличении sparsity улучшается validation loss модели, но и растёт её инфраструктурная сложность. Что касается небольшого, по сравнению с DeepSeek, числа голов аттеншена, то это решение связано с тем, что удвоение голов даёт прибавку к validation loss всего в 1,2% и кажется нецелесообразным.
На претрейне Kimi K2 использовался собственный алгоритм Muon, включающий в себя быстрое преобразование к ортогональной матрице. Однако при применении этого метода происходит «взрыв» логитов аттеншена. Чтобы справиться с этой проблемой, авторы устанавливают максимальные логиты для каждой головы. Дальше, всё, что больше заданного T, клипают. Следом идёт рескейлинг матриц W_k и W_q с gamma_h = min(1 или T/на максимальный логит). В случае с обычным MHA все это домножается на гамму, а в случае с MLA скейлятся только не пошаренные веса голов аттеншена.
Также на претрейне авторы перефразировали данные с помощью промптов — то есть буквально переписывали их, сохраняя семантическое родство. Большие тексты разбивались на отдельные фрагменты, которые затем переписывались и подавались в качестве контекста для следующего фрагмента. После десяти перефразирований и одной эпохи прибавка на SimpleQA получается более чем в пять пунктов по сравнению с использованием «оригинального» текста в течение 10 эпох.
На пострейне использовали 3000 MCP тулов с GitHub и ещё 10 тысяч — синтетических инструментов. По тулам сгенерировали тысячи агентов. Они получили сгенерированные задачи, оценкой которых происходила в режиме LLM-as-a-Judge. Успешные траектории становились базой для обучения.
На этапе RL для случая, когда нет верифицируемой награды, модель использовали одновременно и как актора, и как критика. Актор генерировал набор ответов, которые критик попарно сравнивал относительно набора аспектов. Сам критик обновлялся за счёт verifiable-сигналов.
Разбор подготовил❣ Владимир Платонов
Душный NLP
Сегодня разберём статью о MoE-модели Kimi K2 на триллион параметров. У Kimi в полтора раза больше экспертов, чем у DeepSeek-V3 — 384 против 256. А ещё — в два раза меньше голов аттеншена — 64 против 128.
Создатели вводят понятие sparsity — это разница между общим количеством экспертов и активными экспертами. Так, у Kimi K2 sparsity 48, а у DeepSeek-V3 — 36. Авторы утверждают, что при увеличении sparsity улучшается validation loss модели, но и растёт её инфраструктурная сложность. Что касается небольшого, по сравнению с DeepSeek, числа голов аттеншена, то это решение связано с тем, что удвоение голов даёт прибавку к validation loss всего в 1,2% и кажется нецелесообразным.
На претрейне Kimi K2 использовался собственный алгоритм Muon, включающий в себя быстрое преобразование к ортогональной матрице. Однако при применении этого метода происходит «взрыв» логитов аттеншена. Чтобы справиться с этой проблемой, авторы устанавливают максимальные логиты для каждой головы. Дальше, всё, что больше заданного T, клипают. Следом идёт рескейлинг матриц W_k и W_q с gamma_h = min(1 или T/на максимальный логит). В случае с обычным MHA все это домножается на гамму, а в случае с MLA скейлятся только не пошаренные веса голов аттеншена.
Также на претрейне авторы перефразировали данные с помощью промптов — то есть буквально переписывали их, сохраняя семантическое родство. Большие тексты разбивались на отдельные фрагменты, которые затем переписывались и подавались в качестве контекста для следующего фрагмента. После десяти перефразирований и одной эпохи прибавка на SimpleQA получается более чем в пять пунктов по сравнению с использованием «оригинального» текста в течение 10 эпох.
На пострейне использовали 3000 MCP тулов с GitHub и ещё 10 тысяч — синтетических инструментов. По тулам сгенерировали тысячи агентов. Они получили сгенерированные задачи, оценкой которых происходила в режиме LLM-as-a-Judge. Успешные траектории становились базой для обучения.
На этапе RL для случая, когда нет верифицируемой награды, модель использовали одновременно и как актора, и как критика. Актор генерировал набор ответов, которые критик попарно сравнивал относительно набора аспектов. Сам критик обновлялся за счёт verifiable-сигналов.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevFM
You Should Write An Agent
Недавно проводил опрос: по поводу использования агентов и оказалось, что многие используют.
Нашёл отличную статью – в ней автор предлагает самостоятельно разобраться, как базово устроены агенты под капотом, и попробовать реализовать своего.
В первой части – пошагово и с кодом объясняется, как работает агентский цикл: мы храним историю контекста, передаём её языковой модели и получаем ответы.
Дальше – интереснее: как подключать tools к агенту. Автор даёт агенту возможность выполнять команду ping. LLM сама инициирует вызов нужного инструмента. Получается очень прикольно: ты не описывал логики, не писал условий – модель сама решила, какие адреса пинговать, как интерпретировать результаты и как сформировать ответ.
В конце автор затрагивает важный вопрос контекста. Он показывает, что вся магия мультиагентности – это просто несколько массивов контекста и чуть-чуть управляющего кода.
В общем, рекомендую посмотреть и поэкспериментировать самостоятельно.
#ai
Недавно проводил опрос: по поводу использования агентов и оказалось, что многие используют.
Нашёл отличную статью – в ней автор предлагает самостоятельно разобраться, как базово устроены агенты под капотом, и попробовать реализовать своего.
В первой части – пошагово и с кодом объясняется, как работает агентский цикл: мы храним историю контекста, передаём её языковой модели и получаем ответы.
Дальше – интереснее: как подключать tools к агенту. Автор даёт агенту возможность выполнять команду ping. LLM сама инициирует вызов нужного инструмента. Получается очень прикольно: ты не описывал логики, не писал условий – модель сама решила, какие адреса пинговать, как интерпретировать результаты и как сформировать ответ.
В конце автор затрагивает важный вопрос контекста. Он показывает, что вся магия мультиагентности – это просто несколько массивов контекста и чуть-чуть управляющего кода.
В общем, рекомендую посмотреть и поэкспериментировать самостоятельно.
#ai
Telegram
DevFM
Друзья, хотел спросить: какие агенты вы используете в работе? Если не используете, то расскажите в комментах почему.
Cursor / Claude Code / Roo Code / Другой инструмент – напишу в коммантах / Не использую
Cursor / Claude Code / Roo Code / Другой инструмент – напишу в коммантах / Не использую
Forwarded from Agentic World
На днях у одного из моих любимых авторов вышла новая крутая статья, посвященная альтернативам классическому трансформеру в LLM. Она очень интересная, поэтому сделал ее перевод. Будет про гибриды с линейным вниманием, диффузионные LLM, модели мира и малые рекурсивные трансформеры.
https://habr.com/ru/articles/964658/
https://habr.com/ru/articles/964658/
Хабр
Не только трансформеры: за пределами стандартных архитектур LLM
Привет! Это перевод очень крутой и захватывающей статьи, в которой автор рассматривает альтернативные архитектуры LLM: гибриды с линейным вниманием, диффузионные LLM, модели мира и малые рекурсивные...