Разбираю статью про обучение с подкрплением для самых маленьких и генерацию ответов
Все мы знаем, что большие модели любят учиться на готовых ответах. Но, угадай что? Готовых ответов у нас нет. Они либо дорогие, либо спорные, либо вообще непонятно какие. Представь, что у тебя есть только ты сам, твои черновики и пара свободных вечеров. Ну что, будем учиться на своих же косяках?
Вот для этого придумали Compute as Teacher (CaT). Работает оно так:
- Пользователь кидает запрос. Ну там: «объясни квантовую физику бабушке».
- Модель честно пишет сразу несколько версий ответа. Каждая по-своему кривая, но иногда попадаются удачные куски.
- Другая копия этой же модели собирает из них «лучший хит» — вроде плейлиста «самое ок» из твоих старых песен.
- Потом мы сравниваем все черновики с этим «финальным шедевром» и решаем: «ага, вот это было ближе, а это лучше забыть как страшный сон».
- Модель сама делает выводы и в следующий раз уже тупит чуть меньше.
В итоге получается странная штука: модель учится без учителя, проверяя сама себя. Как если бы школьник писал 5 вариантов решения задачи, потом сам делал «сборку Франкенштейна» из них, и именно её принимал за эталон. А дальше наказывает себя за плохие черновики и хвалит за удачные.
И что самое весёлое — это реально работает. Без людей, без правильных ответов, без пафоса. Просто куча вычислений, которые модель тратит на то, чтобы спорить сама с собой и становиться чуть умнее.
Если коротко: CaT — это как спорить с самим собой в душе, только полезно
Ссылка на статью в следующем посте будет
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Все мы знаем, что большие модели любят учиться на готовых ответах. Но, угадай что? Готовых ответов у нас нет. Они либо дорогие, либо спорные, либо вообще непонятно какие. Представь, что у тебя есть только ты сам, твои черновики и пара свободных вечеров. Ну что, будем учиться на своих же косяках?
Вот для этого придумали Compute as Teacher (CaT). Работает оно так:
- Пользователь кидает запрос. Ну там: «объясни квантовую физику бабушке».
- Модель честно пишет сразу несколько версий ответа. Каждая по-своему кривая, но иногда попадаются удачные куски.
- Другая копия этой же модели собирает из них «лучший хит» — вроде плейлиста «самое ок» из твоих старых песен.
- Потом мы сравниваем все черновики с этим «финальным шедевром» и решаем: «ага, вот это было ближе, а это лучше забыть как страшный сон».
- Модель сама делает выводы и в следующий раз уже тупит чуть меньше.
В итоге получается странная штука: модель учится без учителя, проверяя сама себя. Как если бы школьник писал 5 вариантов решения задачи, потом сам делал «сборку Франкенштейна» из них, и именно её принимал за эталон. А дальше наказывает себя за плохие черновики и хвалит за удачные.
И что самое весёлое — это реально работает. Без людей, без правильных ответов, без пафоса. Просто куча вычислений, которые модель тратит на то, чтобы спорить сама с собой и становиться чуть умнее.
Если коротко: CaT — это как спорить с самим собой в душе, только полезно
Ссылка на статью в следующем посте будет
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
👍3
Ну а теперь давай прикрутим сюда ещё и обучение с подкреплением. Помнишь, как RL работает в игрушках? Агент бегает по лабиринту, жрёт монетки, получает reward и учится не врезаться в стены. Так вот, CaT — это то же самое, только вместо монеток у нас кривые тексты, а вместо стен — собственный стыд за плохие ответы.
Смотри на схему: в первой коробочке у нас prompt — это RL-состояние. Агент видит мир: не «зелёный пиксель в Atari», а «объясни квантовую физику бабушке». Всё, состояние зафиксировано.
Дальше вторая коробка — policy π_t генерирует пачку ответов. В RL-терминах это действия (a₁, a₂, …, a_G). Представь, что агент не делает шаг влево или вправо, а сразу выплёвывает пять разных черновиков. Каждый по сути действие.
Третья коробка — anchor π₀. Это такая «замороженная версия», которая не учится, а просто играет роль суррогатного учителя. Она берёт все черновики и лепит из них что-то, похожее на эталон. В RL это surrogate action, или, если проще: «представим, что правильный ход был вот такой».
Четвёртая коробка — reward calculation. Здесь всё как в казино: каждый черновик получает свою награду. В математике всё просто — сравнил финальные строки, совпало или нет. В медицине или чатах сложнее: включаем Judge (отдельную модель), которая ставит галочки «адекватный совет» или «фейл». Это и есть функция награды r(aᵢ, s).
Пятая коробка — policy update. Вот тут вся магия RL: модель смотрит на оценки, понимает, какие ответы ближе к эталону, и обновляет себя через GRPO. Это примерно как сказать: «ага, вот так писать выгоднее, буду повторять чаще».
Шестая коробка — следующее состояние. Новый prompt, новый эпизод, новые ошибки, новая возможность не выглядеть идиотом. Цикл закрутился.
А теперь смотри на пунктирные связи: они показывают, кто за что отвечает. Policy генерирует и учится, Anchor собирает эталон, Judge проверяет рубриками. И всё это без внешнего учителя. Нет золотого ответа, нет внешней среды — модель сама себе лабиринт, сама себе монетка и сама себе судья.
Фокус в том, что никакого учителя, никакой внешней среды, никакого золотого эталона. Просто модель спорит сама с собой, назначает себе «правильный ответ» и радуется, когда хоть иногда угадывает.
Поэтому CaT в стиле RL — это как играть в шахматы с самим собой, записывать партии, а потом ещё и выписывать штрафы за дебильные ходы. Нудно? Да. Работает? Тоже да. И именно поэтому у ребят в статье получились прибавки к качеству в десятки процентов.
Source
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Смотри на схему: в первой коробочке у нас prompt — это RL-состояние. Агент видит мир: не «зелёный пиксель в Atari», а «объясни квантовую физику бабушке». Всё, состояние зафиксировано.
Дальше вторая коробка — policy π_t генерирует пачку ответов. В RL-терминах это действия (a₁, a₂, …, a_G). Представь, что агент не делает шаг влево или вправо, а сразу выплёвывает пять разных черновиков. Каждый по сути действие.
Третья коробка — anchor π₀. Это такая «замороженная версия», которая не учится, а просто играет роль суррогатного учителя. Она берёт все черновики и лепит из них что-то, похожее на эталон. В RL это surrogate action, или, если проще: «представим, что правильный ход был вот такой».
Четвёртая коробка — reward calculation. Здесь всё как в казино: каждый черновик получает свою награду. В математике всё просто — сравнил финальные строки, совпало или нет. В медицине или чатах сложнее: включаем Judge (отдельную модель), которая ставит галочки «адекватный совет» или «фейл». Это и есть функция награды r(aᵢ, s).
Пятая коробка — policy update. Вот тут вся магия RL: модель смотрит на оценки, понимает, какие ответы ближе к эталону, и обновляет себя через GRPO. Это примерно как сказать: «ага, вот так писать выгоднее, буду повторять чаще».
Шестая коробка — следующее состояние. Новый prompt, новый эпизод, новые ошибки, новая возможность не выглядеть идиотом. Цикл закрутился.
А теперь смотри на пунктирные связи: они показывают, кто за что отвечает. Policy генерирует и учится, Anchor собирает эталон, Judge проверяет рубриками. И всё это без внешнего учителя. Нет золотого ответа, нет внешней среды — модель сама себе лабиринт, сама себе монетка и сама себе судья.
Фокус в том, что никакого учителя, никакой внешней среды, никакого золотого эталона. Просто модель спорит сама с собой, назначает себе «правильный ответ» и радуется, когда хоть иногда угадывает.
Поэтому CaT в стиле RL — это как играть в шахматы с самим собой, записывать партии, а потом ещё и выписывать штрафы за дебильные ходы. Нудно? Да. Работает? Тоже да. И именно поэтому у ребят в статье получились прибавки к качеству в десятки процентов.
Source
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
👍2🔥1
Формальное определение RL
В классическом обучении с подкреплением у нас есть пятёрка:
- S — множество состояний (states)
- A — множество действий (actions)
- R — функция награды (reward function)
- π — политика (policy), то есть стратегия выбора действия в состоянии
- P — переходы (transition dynamics), то есть как мы попадаем из состояния в следующее
В каждом эпизоде агент:
- Видит состояние s ∈ S
- Делает действие a ∈ A согласно политике π(a|s)
- Получает награду r = R(s, a)
- Переходит в новое состояние s′
Задача: максимизировать сумму наград.
Как это ложится на CaT
Теперь то же самое, но через призму Compute as Teacher:
- S (состояние) = текстовый запрос (prompt)
- A (действие) = сгенерированный ответ (rollout). В CaT их сразу несколько: a₁, …, a_G
- π (policy) = текущая модель, которая учится (π_t)
- R (reward) = функция награды: сравнение каждого ответа с синтезированным эталоном (s).
- если задача проверяемая → бинарная проверка совпадения
- если нет → оценка по рубрикам через Judge
- P (переход) = просто следующий запрос от пользователя (новый prompt), среда детерминирована
Итоговое определение для CaT-RL
Эпизод в CaT-RL выглядит так:
- Агент (policy π_t) в состоянии q (prompt) генерирует набор действий o₁:G (rollouts).
- Отдельная модель (anchor π₀) строит surrogate-эталон s на основе этих действий.
Для каждого действия вычисляется награда:
- R(oᵢ) = 1, если совпадает с эталоном (верифицируемые задачи)
- R(oᵢ) = доля выполненных критериев (неверифицируемые задачи).
- Агент обновляет стратегию π_t с помощью RL-алгоритма (GRPO, вариант PPO).
- Следующий запрос = новое состояние.
Формально в одной строчке
CaT-RL = (S, A, R, π, P), где
- S = тексты-запросы,
- A = тексты-ответы,
- R = согласие с синтезированным эталоном,
- π = обучаемая модель,
- P = последовательность запросов (новые эпизоды).
Source
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
В классическом обучении с подкреплением у нас есть пятёрка:
- S — множество состояний (states)
- A — множество действий (actions)
- R — функция награды (reward function)
- π — политика (policy), то есть стратегия выбора действия в состоянии
- P — переходы (transition dynamics), то есть как мы попадаем из состояния в следующее
В каждом эпизоде агент:
- Видит состояние s ∈ S
- Делает действие a ∈ A согласно политике π(a|s)
- Получает награду r = R(s, a)
- Переходит в новое состояние s′
Задача: максимизировать сумму наград.
Как это ложится на CaT
Теперь то же самое, но через призму Compute as Teacher:
- S (состояние) = текстовый запрос (prompt)
- A (действие) = сгенерированный ответ (rollout). В CaT их сразу несколько: a₁, …, a_G
- π (policy) = текущая модель, которая учится (π_t)
- R (reward) = функция награды: сравнение каждого ответа с синтезированным эталоном (s).
- если задача проверяемая → бинарная проверка совпадения
- если нет → оценка по рубрикам через Judge
- P (переход) = просто следующий запрос от пользователя (новый prompt), среда детерминирована
Итоговое определение для CaT-RL
Эпизод в CaT-RL выглядит так:
- Агент (policy π_t) в состоянии q (prompt) генерирует набор действий o₁:G (rollouts).
- Отдельная модель (anchor π₀) строит surrogate-эталон s на основе этих действий.
Для каждого действия вычисляется награда:
- R(oᵢ) = 1, если совпадает с эталоном (верифицируемые задачи)
- R(oᵢ) = доля выполненных критериев (неверифицируемые задачи).
- Агент обновляет стратегию π_t с помощью RL-алгоритма (GRPO, вариант PPO).
- Следующий запрос = новое состояние.
Формально в одной строчке
CaT-RL = (S, A, R, π, P), где
- S = тексты-запросы,
- A = тексты-ответы,
- R = согласие с синтезированным эталоном,
- π = обучаемая модель,
- P = последовательность запросов (новые эпизоды).
Source
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
🔥2
В этом посте я собрал эволюцию генеративных моделей изображений — от первых наивных попыток до современных диффузионных гигантов, чтобы показать, как каждое новое поколение решало слабости предыдущего
1960-е — Наивный байесовский классификатор
Проблема: хотелось, чтобы машина могла «генерировать» текст или данные, но доступных методов почти не было. Байесовский подход сводился к перебору слов из «мешка» без логики и структуры.
Решение: использовать вероятности появления слов для построения нового текста.
Трюк: модель предполагала, что слова независимы друг от друга (мешок слов), и по заданной теме выбирала их случайно.
Прогресс: первые шаги в сторону генеративного ИИ, понимание, что можно не только классифицировать, но и «придумывать» данные.
Минус: тексты бессмысленные, для картинок подход оказался бесполезным — пиксели по отдельности ничего не значат.
2016 — PixelCNN / PixelRNN
Проблема: нужно было научиться собирать картинку как пазл, где каждый кусочек зависит от соседнего. Но приходилось ставить каждый пиксель по одному, как будто вручную выкладываешь мозаику из миллиона камушков.
Решение: сделали модель, которая генерирует пиксели по очереди, учитывая то, что уже нарисовано.
Трюк: сверточные и рекуррентные сети, которые помнят порядок и контекст.
Прогресс: впервые появились изображения, которые выглядят цельно, а не просто как шум.
Минус: невероятно медленно — картинка высокого качества рисуется дольше, чем художник на заказ.
2017–2018 — ProGAN (NVIDIA)
Проблема: рисовать пиксель за пикселем — всё равно что печатать роман по одной букве в день.
Решение: придумали «соревнование» — генератор создаёт картинки целиком, а критик (дискриминатор) пытается разоблачить их как фальшивку.
Трюк: постепенно увеличивали разрешение — сначала модель училась рисовать маленькие квадратики 4×4, потом 8×8, и так до огромных портретов.
Прогресс: впервые можно было получить лица 1024×1024, реалистичные и детализированные.
Минус: генератор талантлив, но неконтролируем: нельзя сказать «нарисуй человека с бородой», он сам решает.
2019 — StyleGAN
Проблема: ProGAN — как дикий художник: он рисует красиво, но делает это только на свой вкус.
Решение: ввели «палитру стилей» — управление тем, что задаёт общую форму, а что отвечает за детали.
Трюк: отдельная сеть переводит случайный вектор в набор стилей для разных уровней: низкие слои отвечают за «архитектуру» (форма лица), верхние за «декор» (морщины, волосы).
Прогресс: можно смешивать образы: взять нос одного человека, а цвет кожи — у другого.
Минус: по-прежнему текстовые описания непонятны, управлять можно только ручками.
В основу лёг обзор Сергея Николенко из его блога sergeynikolenko.ru
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
1960-е — Наивный байесовский классификатор
Проблема: хотелось, чтобы машина могла «генерировать» текст или данные, но доступных методов почти не было. Байесовский подход сводился к перебору слов из «мешка» без логики и структуры.
Решение: использовать вероятности появления слов для построения нового текста.
Трюк: модель предполагала, что слова независимы друг от друга (мешок слов), и по заданной теме выбирала их случайно.
Прогресс: первые шаги в сторону генеративного ИИ, понимание, что можно не только классифицировать, но и «придумывать» данные.
Минус: тексты бессмысленные, для картинок подход оказался бесполезным — пиксели по отдельности ничего не значат.
2016 — PixelCNN / PixelRNN
Проблема: нужно было научиться собирать картинку как пазл, где каждый кусочек зависит от соседнего. Но приходилось ставить каждый пиксель по одному, как будто вручную выкладываешь мозаику из миллиона камушков.
Решение: сделали модель, которая генерирует пиксели по очереди, учитывая то, что уже нарисовано.
Трюк: сверточные и рекуррентные сети, которые помнят порядок и контекст.
Прогресс: впервые появились изображения, которые выглядят цельно, а не просто как шум.
Минус: невероятно медленно — картинка высокого качества рисуется дольше, чем художник на заказ.
2017–2018 — ProGAN (NVIDIA)
Проблема: рисовать пиксель за пикселем — всё равно что печатать роман по одной букве в день.
Решение: придумали «соревнование» — генератор создаёт картинки целиком, а критик (дискриминатор) пытается разоблачить их как фальшивку.
Трюк: постепенно увеличивали разрешение — сначала модель училась рисовать маленькие квадратики 4×4, потом 8×8, и так до огромных портретов.
Прогресс: впервые можно было получить лица 1024×1024, реалистичные и детализированные.
Минус: генератор талантлив, но неконтролируем: нельзя сказать «нарисуй человека с бородой», он сам решает.
2019 — StyleGAN
Проблема: ProGAN — как дикий художник: он рисует красиво, но делает это только на свой вкус.
Решение: ввели «палитру стилей» — управление тем, что задаёт общую форму, а что отвечает за детали.
Трюк: отдельная сеть переводит случайный вектор в набор стилей для разных уровней: низкие слои отвечают за «архитектуру» (форма лица), верхние за «декор» (морщины, волосы).
Прогресс: можно смешивать образы: взять нос одного человека, а цвет кожи — у другого.
Минус: по-прежнему текстовые описания непонятны, управлять можно только ручками.
В основу лёг обзор Сергея Николенко из его блога sergeynikolenko.ru
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
🔥1
2021 — CLIP
Проблема: DALL-E понимает текст только условно, часто путает.
Решение: сделали «универсальный словарь»: модель учится понимать и текст, и картинку в одной системе координат.
Трюк: миллионы пар «описание–картинка»; сеть находит такое представление, где «собака в очках» и фото собаки в очках оказываются близко друг к другу.
Прогресс: текст стал реально управлять картинками, а не быть просто подсказкой.
Минус: сама генерация у CLIP не встроена, он только «понимает», но не «рисует».
2022 — DALL-E 2
Проблема: картинки от DALL-E первого поколения — слишком средненькие.
Решение: подключили новый двигатель — диффузию, процесс обратного «очищения шума».
Трюк: берём случайный шум, и шаг за шагом убираем его, добавляя детали, пока не выйдет картинка. CLIP при этом направляет: какой образ должен получиться.
Прогресс: изображения стали резкими, разнообразными, а подсказки — точнее отражаться.
Минус: слишком тяжёлая модель, без мощных серверов не запустить.
2022 — Midjourney
Проблема: DALL-E 2 рисует реализм, но хочется искусства и выразительности.
Решение: сфокусировались на художественных стилях.
Трюк: та же диффузия, но с приоритетом на стилизацию — результат ближе к иллюстрациям и концепт-арту.
Прогресс: стал любимым инструментом дизайнеров и креативщиков.
Минус: закрытая коробка: нет ни кода, ни прозрачности.
2022 — Stable Diffusion (Ромбах и др.)
Проблема: DALL-E 2 и Midjourney крутые, но тяжёлые и закрытые. Нужны фермы видеокарт.
Решение: перенесли диффузию в «латентное пространство» — не с пикселями, а с компактным представлением изображения.
Трюк: автоэнкодер сначала сжимает картинку в «каркас», и диффузия работает именно там. Это дешевле и быстрее.
Прогресс: генерация доступна на обычном компьютере, код и веса открыты → массовое использование.
Минус: за простоту приходится платить: иногда теряются мелкие детали и качество хуже, чем у DALL-E 2.
В основу лёг обзор Сергея Николенко из его блога sergeynikolenko.ru
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Проблема: DALL-E понимает текст только условно, часто путает.
Решение: сделали «универсальный словарь»: модель учится понимать и текст, и картинку в одной системе координат.
Трюк: миллионы пар «описание–картинка»; сеть находит такое представление, где «собака в очках» и фото собаки в очках оказываются близко друг к другу.
Прогресс: текст стал реально управлять картинками, а не быть просто подсказкой.
Минус: сама генерация у CLIP не встроена, он только «понимает», но не «рисует».
2022 — DALL-E 2
Проблема: картинки от DALL-E первого поколения — слишком средненькие.
Решение: подключили новый двигатель — диффузию, процесс обратного «очищения шума».
Трюк: берём случайный шум, и шаг за шагом убираем его, добавляя детали, пока не выйдет картинка. CLIP при этом направляет: какой образ должен получиться.
Прогресс: изображения стали резкими, разнообразными, а подсказки — точнее отражаться.
Минус: слишком тяжёлая модель, без мощных серверов не запустить.
2022 — Midjourney
Проблема: DALL-E 2 рисует реализм, но хочется искусства и выразительности.
Решение: сфокусировались на художественных стилях.
Трюк: та же диффузия, но с приоритетом на стилизацию — результат ближе к иллюстрациям и концепт-арту.
Прогресс: стал любимым инструментом дизайнеров и креативщиков.
Минус: закрытая коробка: нет ни кода, ни прозрачности.
2022 — Stable Diffusion (Ромбах и др.)
Проблема: DALL-E 2 и Midjourney крутые, но тяжёлые и закрытые. Нужны фермы видеокарт.
Решение: перенесли диффузию в «латентное пространство» — не с пикселями, а с компактным представлением изображения.
Трюк: автоэнкодер сначала сжимает картинку в «каркас», и диффузия работает именно там. Это дешевле и быстрее.
Прогресс: генерация доступна на обычном компьютере, код и веса открыты → массовое использование.
Минус: за простоту приходится платить: иногда теряются мелкие детали и качество хуже, чем у DALL-E 2.
В основу лёг обзор Сергея Николенко из его блога sergeynikolenko.ru
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
🔥2👍1
Что такое Context7 и зачем он нужен
Context7 — это MCP-сервер от Upstash, который подсовывает LLM актуальные версии документации и рабочие примеры прямо в контекст генерации.
Зачем? Потому что обычные LLM (ChatGPT, Claude и пр.) страдают от знаний среза — библиотека обновилась, API изменился, а модель всё ещё предлагает то, что "знает". Context7 решает это: подтягивает официальную доку + пример кода, фильтрует по версии, ранжирует релевантное, и подмешивает в prompt.
Типичный сценарий: ты в Cursor или другом MCP-клиенте пишешь “use context7”, дальше модель сама дергает resolve-library-id, get-library-docs и подсовывает нужные куски документации в контекст генерации.
Плюсы: меньше бредовых API, меньше правок, удобнее работать с быстро меняющимися библиотеками (Next.js, Tailwind, Zod и др.)
Минусы: может выбрать не то, надо контролировать prompt.
Объяснение
— Разработчик работает в IDE (например, Cursor или VSCode с поддержкой MCP). Он пишет запрос вроде «как использовать FastAPI middleware», IDE шлёт его в Context7 MCP Server.
— Context7 — мозг, который знает, где искать правду. Сначала он маппит запрос к нужной библиотеке и версии, потом идёт в Docs & Repos — официальные источники документации.
— Если документ уже есть в кэше, Context7 отдаёт его сразу. Если нет — скачивает свежие данные, фильтрует, очищает, добавляет примеры.
— Ранжировщик отбирает самое релевантное и подсовывает результат LLM (например, ChatGPT или Claude).
— LLM получает контекст — не абстрактный, а актуальный — и пишет код, который реально работает в твоей версии библиотеки.
— Результат возвращается обратно в IDE: разработчик видит сгенерированный код, а Context7 молча ускоряет следующий запрос из кэша.
Пример на Python: попросим LLM с Context7
Представим, ты работаешь с библиотекой starlette (версии 0.27). Ты хочешь, чтобы модель написала middleware, проверяющее заголовок X-Auth.
Context7 внутри подтянет секцию из официальной документации
Если библиотека обновится и в версии 0.28
Source
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Context7 — это MCP-сервер от Upstash, который подсовывает LLM актуальные версии документации и рабочие примеры прямо в контекст генерации.
Зачем? Потому что обычные LLM (ChatGPT, Claude и пр.) страдают от знаний среза — библиотека обновилась, API изменился, а модель всё ещё предлагает то, что "знает". Context7 решает это: подтягивает официальную доку + пример кода, фильтрует по версии, ранжирует релевантное, и подмешивает в prompt.
Типичный сценарий: ты в Cursor или другом MCP-клиенте пишешь “use context7”, дальше модель сама дергает resolve-library-id, get-library-docs и подсовывает нужные куски документации в контекст генерации.
Плюсы: меньше бредовых API, меньше правок, удобнее работать с быстро меняющимися библиотеками (Next.js, Tailwind, Zod и др.)
Минусы: может выбрать не то, надо контролировать prompt.
Объяснение
— Разработчик работает в IDE (например, Cursor или VSCode с поддержкой MCP). Он пишет запрос вроде «как использовать FastAPI middleware», IDE шлёт его в Context7 MCP Server.
— Context7 — мозг, который знает, где искать правду. Сначала он маппит запрос к нужной библиотеке и версии, потом идёт в Docs & Repos — официальные источники документации.
— Если документ уже есть в кэше, Context7 отдаёт его сразу. Если нет — скачивает свежие данные, фильтрует, очищает, добавляет примеры.
— Ранжировщик отбирает самое релевантное и подсовывает результат LLM (например, ChatGPT или Claude).
— LLM получает контекст — не абстрактный, а актуальный — и пишет код, который реально работает в твоей версии библиотеки.
— Результат возвращается обратно в IDE: разработчик видит сгенерированный код, а Context7 молча ускоряет следующий запрос из кэша.
Пример на Python: попросим LLM с Context7
Представим, ты работаешь с библиотекой starlette (версии 0.27). Ты хочешь, чтобы модель написала middleware, проверяющее заголовок X-Auth.
Напиши middleware для starlette 0.27, который проверяет заголовок X-Auth и возвращает 401, если его нет. use context7
Context7 внутри подтянет секцию из официальной документации
starlette.middleware, выберет релевантный пример к версии 0.27, и передаст LLM. Получишь примерно такой код:from starlette.middleware.base import BaseHTTPMiddleware
from starlette.requests import Request
from starlette.responses import JSONResponse
class AuthHeaderMiddleware(BaseHTTPMiddleware):
async def dispatch(self, request: Request, call_next):
auth = request.headers.get("X-Auth")
if not auth:
return JSONResponse({"detail": "Unauthorized"}, status_code=401)
# можно проверить значение auth тут
response = await call_next(request)
return response
Если библиотека обновится и в версии 0.28
BaseHTTPMiddleware будет помечен как deprecated, Context7 подставит именно нужный кусок и LLM не будет юзать старый API.Source
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
👍3
Как научить модель техподдержки не говорить «Добрый день». И причём тут статья про UXPID
Все обещают «умную поддержку на ИИ». На деле получаем:
- модель здоровается, благодарит за обращение и радостно генерирует галлюцинации
- cкорость ответа — 3 секунды, стиль — «робот на корпоративе»
В статье про UXPID ребята показали, как можно сначала выжать из сырых форумных комментов структуру, а уже потом обучать лёгковесные модели типа DistilBERT. Вдохновились. Перенесли подход в нашу реальность, где регламент запрещает дружелюбие и нужна формальность, а SLA секундный. BERT может очень быстро работать
Что делаем
Стекинг вместо монолита. Не один умный ИИ, а цепочка специализированных моделей:
Слой 1 — целеполагание
DistilBERT быстро определяет: что за запрос, насколько он срочный и что клиент реально хочет, а не что написал в CAPS LOCK.
Слой 2 — генерация сырого ответа
Без изысков. Просто по делу. Можно на GPT-малолетке, можно по шаблону. Главное — быстро.
Слой 3 — регламентный вышибала
Вторая DistilBERT-юнит проверяет текст по правилам:
- никаких «добрых дней», никакого дружелюбия, только голые факты.
- если надо — вырезает, переписывает, сушит до стандарта.
Проблема холодного старта
У клиента тикетов ещё нет, а ИИ уже должен «знать жанр». Значит, делаем, как в UXPID:
- Берёмпубличные форумы по индустрии (диалоги/тикеты)
- Прогоняем через GPT, извлекаем структуру: тон, intent, тип проблемы
- Дообучаем наши DistilBERT’ы на этом
- На входе у клиента уже не просто LLM, а модель, знающая, как НЕ говорить
Source
Github
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Все обещают «умную поддержку на ИИ». На деле получаем:
- модель здоровается, благодарит за обращение и радостно генерирует галлюцинации
- cкорость ответа — 3 секунды, стиль — «робот на корпоративе»
В статье про UXPID ребята показали, как можно сначала выжать из сырых форумных комментов структуру, а уже потом обучать лёгковесные модели типа DistilBERT. Вдохновились. Перенесли подход в нашу реальность, где регламент запрещает дружелюбие и нужна формальность, а SLA секундный. BERT может очень быстро работать
Что делаем
Стекинг вместо монолита. Не один умный ИИ, а цепочка специализированных моделей:
Слой 1 — целеполагание
DistilBERT быстро определяет: что за запрос, насколько он срочный и что клиент реально хочет, а не что написал в CAPS LOCK.
Слой 2 — генерация сырого ответа
Без изысков. Просто по делу. Можно на GPT-малолетке, можно по шаблону. Главное — быстро.
Слой 3 — регламентный вышибала
Вторая DistilBERT-юнит проверяет текст по правилам:
- никаких «добрых дней», никакого дружелюбия, только голые факты.
- если надо — вырезает, переписывает, сушит до стандарта.
Проблема холодного старта
У клиента тикетов ещё нет, а ИИ уже должен «знать жанр». Значит, делаем, как в UXPID:
- Берём
- Прогоняем через GPT, извлекаем структуру: тон, intent, тип проблемы
- Дообучаем наши DistilBERT’ы на этом
- На входе у клиента уже не просто LLM, а модель, знающая, как НЕ говорить
Source
Github
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
🔥1
Пруф или блеф: как ИИ завалил олимпиаду по математике
Я ошибался, прочитал полный разбор исходной статьи. LLM-ки не умеют пока что в математику достаточно хорошо
2025-й, США. На арене — восемь новейших моделей искусственного интеллекта. Задача — решить шесть задач с доказательствами из американской математической олимпиады (USAMO). Без шансов на списывание, без намёков на ответы. Только чистая логика, шаг за шагом.
Результат?
Если бы это был школьный тест, семь из восьми моделей отправились бы на пересдачу. Лишь Gemini-2.5-Pro кое-как вытянуло на 24%. Остальные — меньше пяти. Не баллов из ста, а процентов.
Когда искусственный интеллект думает, что "trivial" — это аргумент
Исследователи из ETH Zurich и INSAIT дали моделям задачу: не просто угадать ответ, а доказать его. Но ничего не получилось. Авторы выделили 4 типа основных проблем:
- Logic — модели делают вид, что доказали, хотя просто пропустили кусок.
- Assumption — уверенно строят рассуждения на придуманных предпосылках.
- Creativity — упорно повторяют одну и ту же ошибку, будто от неё станет вернее.
- Algebra/Arithmetic — путаются в формулах, когда теряют контекст (уравнение длиннее — память короче).
В целом, алгоритмы умеют считать, но не умеют понимать, зачем они это делают. Как школьник, который выучил формулу, но не понял, почему она работает.
Когда модель проверяет саму себя
Авторы решили пойти дальше и дали ИИ проверить свои же решения. Результат — апофеоз самоуверенности.
LLM-судьи (Claude 3.7 и O3-Mini) ставили себе и коллегам завышенные оценки — иногда в 20 раз выше человеческих.
Возможные направления решения
Формальный контроль. Проверять каждый шаг через системы типа Lean, Coq, Isabelle. Потому что красивые формулы ≠ логика.
Обучение на объяснениях. Давать награду не за ответ, а за путь к нему — как в хороших олимпиадах.
Парное оценивание. Пусть модели проверяют друг друга — вдруг одна заметит бред другой.
Эталонные доказательства. Сделать базу “правильных рассуждений” и учить ИИ искать ошибки в чужих текстах.
Калибровка уверенности. Если модель не может объяснить, почему поставила себе 7 из 7 — автоматически минус балл.
А с арифметикой — вообще просто: подключите SymPy или Mathematica, пусть хоть кто-то считает правильно.
Главный вывод
Современные LLM научились имитировать математика — писать красиво, с LaTeX, уверенно и абсолютно неправильно. И если раньше они “угадывали ответы”, теперь научились “уверенно доказывать чушь”.
Математика, как выяснилось, не про язык, а про мышление. И пока модели этого не поймут, они будут оставаться тем, чем и выглядят: машинами, которые верят в свои доказательства сильнее, чем люди в гороскопы.
Source
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Я ошибался, прочитал полный разбор исходной статьи. LLM-ки не умеют пока что в математику достаточно хорошо
2025-й, США. На арене — восемь новейших моделей искусственного интеллекта. Задача — решить шесть задач с доказательствами из американской математической олимпиады (USAMO). Без шансов на списывание, без намёков на ответы. Только чистая логика, шаг за шагом.
Результат?
Если бы это был школьный тест, семь из восьми моделей отправились бы на пересдачу. Лишь Gemini-2.5-Pro кое-как вытянуло на 24%. Остальные — меньше пяти. Не баллов из ста, а процентов.
Когда искусственный интеллект думает, что "trivial" — это аргумент
Исследователи из ETH Zurich и INSAIT дали моделям задачу: не просто угадать ответ, а доказать его. Но ничего не получилось. Авторы выделили 4 типа основных проблем:
- Logic — модели делают вид, что доказали, хотя просто пропустили кусок.
- Assumption — уверенно строят рассуждения на придуманных предпосылках.
- Creativity — упорно повторяют одну и ту же ошибку, будто от неё станет вернее.
- Algebra/Arithmetic — путаются в формулах, когда теряют контекст (уравнение длиннее — память короче).
В целом, алгоритмы умеют считать, но не умеют понимать, зачем они это делают. Как школьник, который выучил формулу, но не понял, почему она работает.
Когда модель проверяет саму себя
Авторы решили пойти дальше и дали ИИ проверить свои же решения. Результат — апофеоз самоуверенности.
LLM-судьи (Claude 3.7 и O3-Mini) ставили себе и коллегам завышенные оценки — иногда в 20 раз выше человеческих.
“Neither model accurately graded the solutions, consistently overestimating their quality.”
Возможные направления решения
Формальный контроль. Проверять каждый шаг через системы типа Lean, Coq, Isabelle. Потому что красивые формулы ≠ логика.
Обучение на объяснениях. Давать награду не за ответ, а за путь к нему — как в хороших олимпиадах.
Парное оценивание. Пусть модели проверяют друг друга — вдруг одна заметит бред другой.
Эталонные доказательства. Сделать базу “правильных рассуждений” и учить ИИ искать ошибки в чужих текстах.
Калибровка уверенности. Если модель не может объяснить, почему поставила себе 7 из 7 — автоматически минус балл.
А с арифметикой — вообще просто: подключите SymPy или Mathematica, пусть хоть кто-то считает правильно.
Главный вывод
Современные LLM научились имитировать математика — писать красиво, с LaTeX, уверенно и абсолютно неправильно. И если раньше они “угадывали ответы”, теперь научились “уверенно доказывать чушь”.
Математика, как выяснилось, не про язык, а про мышление. И пока модели этого не поймут, они будут оставаться тем, чем и выглядят: машинами, которые верят в свои доказательства сильнее, чем люди в гороскопы.
Source
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
👍3🔥1
Привет всем! Ищу себе рекрутера в команду
Position: English-speaking Technical Recruiter (AI & Product focus)
Location: Limassol, Cyprus (on-site)
We’re looking for an experienced technical recruiter who can help us grow a world-class AI and product development team. Your focus will be on identifying, engaging, and closing top-tier talent in the areas of product management, machine learning, and AI engineering, primarily targeting candidates from the US and international markets.
What you’ll do
- Build and manage a strong talent pipeline in AI, ML, and product development.
Attend and network at tech and AI conferences to meet potential hires and strengthen the company’s visibility in the field.
- Find and attract “hidden gems” — high-impact professionals who may not be actively looking.
- Communicate fluently with developers and ML specialists — you can “speak their language” and assess technical depth.
- Manage the full recruitment cycle from sourcing to closing offers.
- Collaborate closely with the leadership team to shape hiring strategy and company culture.
Requirements
- Fluent English (written and spoken).
- Located in or willing to relocate to Limassol, Cyprus.
- Proven track record in technical recruitment, ideally with exposure to AI / ML / product talent.
- Strong understanding of the AI ecosystem, latest tools, and talent landscape.
Excellent networking skills and ability to represent the company at tech events.
- Ability to identify and attract top 1% talent.
Nice to have
- Previous experience hiring for US-based or global remote teams.
- Background in technology or AI research.
- Passion for cutting-edge technologies and the people who build them.
📩 Send CV to @eurvanov
Вакансия от меня
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Position: English-speaking Technical Recruiter (AI & Product focus)
Location: Limassol, Cyprus (on-site)
We’re looking for an experienced technical recruiter who can help us grow a world-class AI and product development team. Your focus will be on identifying, engaging, and closing top-tier talent in the areas of product management, machine learning, and AI engineering, primarily targeting candidates from the US and international markets.
What you’ll do
- Build and manage a strong talent pipeline in AI, ML, and product development.
Attend and network at tech and AI conferences to meet potential hires and strengthen the company’s visibility in the field.
- Find and attract “hidden gems” — high-impact professionals who may not be actively looking.
- Communicate fluently with developers and ML specialists — you can “speak their language” and assess technical depth.
- Manage the full recruitment cycle from sourcing to closing offers.
- Collaborate closely with the leadership team to shape hiring strategy and company culture.
Requirements
- Fluent English (written and spoken).
- Located in or willing to relocate to Limassol, Cyprus.
- Proven track record in technical recruitment, ideally with exposure to AI / ML / product talent.
- Strong understanding of the AI ecosystem, latest tools, and talent landscape.
Excellent networking skills and ability to represent the company at tech events.
- Ability to identify and attract top 1% talent.
Nice to have
- Previous experience hiring for US-based or global remote teams.
- Background in technology or AI research.
- Passion for cutting-edge technologies and the people who build them.
📩 Send CV to @eurvanov
Вакансия от меня
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Telegram
Человек и бизнес — Егор Урванов
Истории людей в разработке продуктов, их эмоциях, решениях с точки зрения менеджера и разработчика
Пишет менеджер и инженер
Разбираю разные кейс из жизни и их решения: технические и не очень
Чат: https://t.me/+N-FBSXaBevwzYzk6
Cвязь: @eurvanov
Пишет менеджер и инженер
Разбираю разные кейс из жизни и их решения: технические и не очень
Чат: https://t.me/+N-FBSXaBevwzYzk6
Cвязь: @eurvanov
Разыскивается сильный Python-разработчика в крипто-финтех / алготрейдинг
Что делаем
- строим штуку для алготрейдинга в крипте
Задачи
- допиливать отдельные модули (не "переписать всё на Rust");
- оптимизация, интеграции, повышение стабильности;
- иногда — разбираться в нетривиальной логике и чинить то, что ноет под нагрузкой
Стек: Python, Celery, gRPC, Redis, PostgreSQL, CCXT, Jira
Требования
- не боится сложной логики и умеет её держать в голове
- реально сильный в Python (не "я проходил курс")
- понимает микросервисы, очереди, асинхронность, протоколы;
- работал с Celery / Redis / gRPC / CCXT (или очень быстро догоняет)
Условия
- part-time сейчас если зайдём друг другу, переход в full-time
- ремоут, часовые пояса пофиг: МСК/Грузия/Таиланд уже в команде, важен результат
- fully remote, гибкий график;
- бюджет обсуждаем от твоих ожиданий;
- команда адекватная, без микроменеджмента;
- если вливаешься — опцион
Если тебе интересно, пиши в личку @eurvanov
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Что делаем
- строим штуку для алготрейдинга в крипте
Задачи
- допиливать отдельные модули (не "переписать всё на Rust");
- оптимизация, интеграции, повышение стабильности;
- иногда — разбираться в нетривиальной логике и чинить то, что ноет под нагрузкой
Стек: Python, Celery, gRPC, Redis, PostgreSQL, CCXT, Jira
Требования
- не боится сложной логики и умеет её держать в голове
- реально сильный в Python (не "я проходил курс")
- понимает микросервисы, очереди, асинхронность, протоколы;
- работал с Celery / Redis / gRPC / CCXT (или очень быстро догоняет)
Условия
- part-time сейчас если зайдём друг другу, переход в full-time
- ремоут, часовые пояса пофиг: МСК/Грузия/Таиланд уже в команде, важен результат
- fully remote, гибкий график;
- бюджет обсуждаем от твоих ожиданий;
- команда адекватная, без микроменеджмента;
- если вливаешься — опцион
Если тебе интересно, пиши в личку @eurvanov
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Telegram
Человек и бизнес — Егор Урванов
Истории людей в разработке продуктов, их эмоциях, решениях с точки зрения менеджера и разработчика
Пишет менеджер и инженер
Разбираю разные кейс из жизни и их решения: технические и не очень
Чат: https://t.me/+N-FBSXaBevwzYzk6
Cвязь: @eurvanov
Пишет менеджер и инженер
Разбираю разные кейс из жизни и их решения: технические и не очень
Чат: https://t.me/+N-FBSXaBevwzYzk6
Cвязь: @eurvanov
👍3
Меня позвали на подкаст. Я тут рассказывал про мой взгляд на разработку и жизнь https://ysnit.mave.digital/ep-40
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
7 выпуск 3 сезона
CTO Егор - человек ИТ-оркестр про страх кода, event storming и будущее с ИИ — Подкаст «Знай и Умей ИТ»
Егор: https://www.linkedin.com/in/eurvanov/Говорили про:- Менторство и страхи: Почему разработчики боятся чистого листа и как с этим работать.- Архитектура как Event Storming: Зачем рисовать схемы в Miro и как это помогает «синхронизировать» мозги за
🔥4👍2
Друзья, с Новым годом! 🎄 ✨
Кто-то встречает под снегом, кто-то — с дождём, а я вообще в горах, в Тае 🌴
Но несмотря на это, у нас есть главное: мы держимся вместе, все вы тут очень классные ❤️
В новом году желаю каждому:
— спокойных дней (да, это роскошь)
— сил и ясной головы
— чтобы дома было тепло, понимания в бизнесе и на работе
Спасибо, что вы есть. Обнял🤝
С Новым годом! Ура! 🥂
Вот вам ёлочка
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Кто-то встречает под снегом, кто-то — с дождём, а я вообще в горах, в Тае 🌴
Но несмотря на это, у нас есть главное: мы держимся вместе, все вы тут очень классные ❤️
В новом году желаю каждому:
— спокойных дней (да, это роскошь)
— сил и ясной головы
— чтобы дома было тепло, понимания в бизнесе и на работе
Спасибо, что вы есть. Обнял
С Новым годом! Ура! 🥂
Вот вам ёлочка
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
🎄4❤3