OpenClaw + RL

Агенты OpenClaw адаптируются с помощью файлов памяти и навыков (skills), но веса базовой модели на самом деле не меняются.

Как OpenClaw-RL решает эту проблему?

Он оборачивает самостоятельно размещённую модель в API, совместимый с OpenAI, перехватывает живые диалоги из OpenClaw и обучает политику в фоновом режиме с помощью RL (обучения с подкреплением).

Архитектура полностью асинхронная. Это означает, что:

обработка запросов,

оценка награды (reward scoring),

и обучение

выполняются параллельно.

После завершения обучения веса модели "hot" подменяются (hot-swap) после каждого батча, при этом агент продолжает отвечать без остановки.

В настоящее время поддерживаются два режима обучения:

Binary RL (GRPO): модель награды оценивает каждый ход диалога как хороший, плохой или нейтральный. Эта скалярная награда используется для обновления политики через PPO-подобную функцию цели с клиппингом.

On-Policy Distillation: когда появляются конкретные исправления, например
"тебе нужно было сначала проверить тот файл",
эта обратная связь используется как более богатый направленный сигнал обучения на уровне токенов.

Когда стоит использовать OpenClaw-RL?

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

Существующая экосистема навыков OpenClaw и созданные сообществом навыки самоулучшения покрывают широкий спектр задач без изменения весов модели.

Если агент постоянно забывает предпочтения пользователя - это проблема памяти.
Если он не знает, как обработать конкретный рабочий процесс - это проблема навыков.

Обе задачи решаются на уровне промптов и контекста.

RL становится действительно интересным, когда источник ошибки лежит глубже - в самом механизме рассуждения модели.

Например:

систематически плохой порядок выбора инструментов,

слабое многошаговое планирование,

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

Исследования в области agentic RL (например, ARTIST и Agent-R1) показывают, что такие поведенческие паттерны достигают потолка, если использовать только промпт-подходы. Особенно это заметно в сложных многошаговых задачах, где модели нужно:

восстанавливаться после ошибок инструментов,

или менять стратегию прямо во время выполнения.
Именно этот уровень и является целью OpenClaw-RL - и это ключевое отличие от того, что предлагает обычный OpenClaw.

Как бороться с переобучением в нейросетях

Переобучение — это момент, когда модель:
👉 отлично знает train
👉 и вообще не понимает реальный мир

Она запоминает, а не обобщает.
Разберём, как с этим бороться 👇

1. Больше данных (самый честный способ)

Чем больше данных — тем сложнее модели заучить шум.

Что можно сделать:
👉 собрать новые данные
👉 использовать data augmentation
👉 синтетически расширить выборку

В CV и NLP это часто даёт лучший эффект, чем любые трюки с архитектурой.

2. Regularization (штраф за “слишком умную” модель)

👉 L1 / L2 регуляризация
→ штрафуют большие веса

Интуитивно:
модель становится проще и меньше переобучается

3. Dropout — случайное “забывание” нейронов

Во время обучения случайные нейроны отключаются.

Что это даёт:
👉 модель не может опираться на конкретные нейроны
👉 учится быть более устойчивой

Обычно:
👉 0.2 – 0.5 dropout rate

4. Early Stopping — остановись вовремя

Следим за валидацией:

👉 train loss ↓
👉 val loss сначала ↓, потом ↑

Как только val начинает расти — останавливаем обучение

Это один из самых эффективных и недооценённых методов.

5. Упростить модель

Иногда решение самое простое:

👉 меньше слоёв
👉 меньше параметров
👉 проще архитектура

Большая модель = больше шанс переобучения.

6. Batch Normalization

Помогает:
👉 стабилизировать обучение
👉 немного снижает переобучение

Но это не silver bullet — скорее бонус.

7. Data Augmentation

Особенно важно для:

👉 CV (повороты, шум, кропы)
👉 NLP (перефразирование, замены)

Модель видит больше вариантов одного и того же объекта.

8. Правильная валидация

Если у тебя плохой split —
ты даже не поймёшь, что модель переобучилась.

Используй:
👉 train / val / test
👉 k-fold (если мало данных)

Главный инсайт

Переобучение — это не ошибка модели.

Это сигнал, что:
👉 либо мало данных
👉 либо модель слишком сложная
👉 либо процесс обучения настроен плохо

В одном предложении

Чтобы победить переобучение —
либо добавь информации (данные), либо убери сложность (модель).

Уверенное владение математическим аппаратом — ключевой фактор для решения сложных задач в Data Science, ML и других it-специальностях.

Преподаватели МФТИ и создатели проекта Popmath приглашают вас на бесплатный вебинар "Как выучить математику во взрослом возрасте?"

На вебинаре вы получите ответы на ключевые вопросы:

🔴 Прикладная математика: Какие разделы наиболее критичны для современных IT-специальностей

🔵 Эффективность обучения: Почему академический подход часто не работает и как выстроить процесс с максимальным КПД

🟠 Актуальные методики: Какие образовательные технологии позволяют в сжатые сроки восстановить и систематизировать знания

Дата: 23 марта
Время: 20:00 по МСК
Длительность: 1 час + ответы на вопросы

➡️ Для регистрации пишите нам!

или ознакомьтесь со страницей вебинара и оставьте заявку там

🔻 Всем участникам вебинара скидка 10% на 4-х месячный онлайн-курс "Математика с нуля для взрослых", который начнётся уже 26 марта🔺

Секунда уверенности → полгода страданий

Внедрить ИИ в бизнес — миссия выполнима?
💯 Узнайте ответ 9 апреля на закрытой встрече для предпринимателей и специалистов по машинному обучению.

Selectel, GlowByte и Data Sapience проведут мероприятие для тех, кто хочет автоматизировать бизнес-процессы с помощью ИИ. В программе — дискуссии о машинном обучении, обсуждение реальных кейсов и рабочих задач с экспертами. А также ужин и полезные знакомства.

Смотреть программу 💡

⏰ 9 апреля (чт), 18:00
📍 Москва, м. Динамо
Приходите, чтобы пообщаться со спикерами и получить экспертный разбор вашего кейса.

✅ Участие бесплатное, Дождитесь подтверждения заявки. Регистрируйтесь по ссылке: https://slc.tl/wt88c

Реклама. АО "Селектел". erid:2W5zFJN4RKe

Yandex B2B Tech объявила о старте грантовой программы для компаний, работающих с искусственным интеллектом.

Инициатива ориентирована на команды, которые создают цифровые продукты для внешнего рынка и планируют внедрить в них ИИ. Участникам предлагают финансирование до 1 млн рублей — эти средства можно направить на разработку ИИ-агентов и приложений на базе Yandex AI Studio в течение шести месяцев.

Помимо грантов, компании получают доступ к экспертной поддержке и помощи в продвижении. После окончания программы участникам предоставляется значительная скидка — до 70% — на использование платформы сроком до полугода.

В числе первых проектов:
— R77.ai, автоматизирующий проверку документов для банков и страховых с помощью машинного обучения
— Noumy.ai, разрабатывающий инструменты для анализа кандидатов и их поведения на интервью
— GO2AI, создающий ИИ-агентов для стратегического планирования и ускоряющий принятие решений с нескольких дней до часа
Дополнительно участники смогут рассчитывать на софинансирование маркетинговых активностей и размещение своих продуктов в маркетплейсе Yandex Cloud.

Fine-tuning vs RAG: что эффективнее

Кажется, что есть два пути прокачать LLM:

👉 Fine-tuning — дообучить модель
👉 RAG (Retrieval-Augmented Generation) — дать доступ к базе знаний

И главный вопрос: что лучше?

Не существует «лучше». Есть «под задачу».
Разберёмся 👇

Что такое Fine-tuning?

Ты берёшь модель и доучиваешь её на своих данных.

Модель:
👉 меняет веса
👉 «запоминает» стиль, паттерны, формат

Это как переучить мозг модели.
Хорошо подходит для:
👉 кастомного тона (support, юрист, врач)
👉 форматирования ответов
👉 специфичных паттернов

Что такое RAG?

Ты не меняешь модель.
Ты даёшь ей доступ к внешним данным:

👉 запрос
👉 поиск по базе (vector DB)
👉 релевантные куски
👉 генерация ответа

Это как открыть шпаргалку перед ответом.
Хорошо подходит для:
👉 актуальной информации
👉 больших баз знаний
👉 документов, инструкций, FAQ

Где начинается реальная разница

1. Обновляемость
Fine-tuning → нужно переобучать
RAG → просто обновил базу

👉 если данные часто меняются — RAG выигрывает

2. Контроль над знаниями
Fine-tuning → знания «размазаны» в весах
RAG → ты точно знаешь источник

👉 RAG более контролируемый

3. Стоимость
Fine-tuning → дорого (обучение + инференс)
RAG → дешевле, но есть стоимость retrieval

4. Галлюцинации
Fine-tuning → может уверенно «врать»
RAG → опирается на документы

👉 RAG обычно надёжнее

5. Задержка (latency)
Fine-tuning → быстрее
RAG → медленнее (поиск + генерация)

Когда Fine-tuning лучше

👉 нужно изменить стиль / тон
👉 есть чёткие шаблоны ответов
👉 данные стабильны
👉 нужна минимальная задержка

Когда RAG лучше

👉 часто обновляемые данные
👉 большая база знаний
👉 требуется объяснимость
👉 важно снизить галлюцинации

Самый важный инсайт

Это не конкуренты. Это связка.
На практике делают так:

👉 Fine-tuning учит модель, как отвечать
👉 RAG даёт модели, что отвечать

В одном предложении

Fine-tuning меняет мозг модели,
RAG даёт ей память.

CSP, CORS и security headers — что фронтендер обязан понимать глубже

Принято считать, что безопасность — это зона бэкенда.
Фронтенд «просто отправляет запросы и рендерит UI».

На практике фронтенд напрямую влияет на то,
будет приложение безопасным или нет.

CORS — это не про «разрешить запрос»

CORS часто воспринимают как настройку:
«чтобы запросы не падали из браузера».

Но по сути это механизм, который говорит:
кто имеет право читать ответ.

Важно понимать:

👉 сервер может обработать запрос
👉 но браузер может не дать прочитать ответ

Именно поэтому:

👉 Access-Control-Allow-Origin: * — не «фикс», а потенциальная дыра
👉 credentials + wildcard — запрещённая комбинация

CORS — это про контроль доступа, а не про обход ошибок.

CSP — ваш последний рубеж

Content Security Policy — это защита от XSS,
даже если у вас уже есть уязвимость.

Пример:

Content-Security-Policy: default-src 'self'; script-src 'self'

Что это даёт:

👉 запрещает выполнение inline-скриптов
👉 блокирует загрузку скриптов с чужих доменов
👉 режет целый класс атак

Но есть нюанс.

Если CSP выглядит так:

script-src * 'unsafe-inline' 'unsafe-eval'

Это не защита. Это иллюзия.

Security headers, которые реально важны

👉 X-Content-Type-Options: nosniff
Браузер не пытается угадать тип файла. Меньше атак через подмену.

👉 X-Frame-Options / frame-ancestors
Защита от clickjacking.

👉 Strict-Transport-Security (HSTS)
Принудительный HTTPS. Без вариантов.

👉 Referrer-Policy
Контроль того, какие данные уходят при переходах.

Где фронтендер влияет напрямую

👉 какие скрипты подключаются
👉 есть ли inline JS
👉 используются ли eval-подобные вещи
👉 как работают сторонние виджеты
👉 как обрабатываются пользовательские данные

Можно иметь идеальный бэкенд и сломать всё на уровне UI.

Частая ошибка

«Мы включили CSP — значит всё ок».

Но:

👉 нет nonce / hash
👉 разрешены любые источники
👉 подключены сторонние скрипты без контроля

В итоге защита есть только на бумаге.

Главная мысль

CSP, CORS и заголовки — это не чекбокс в настройках.
Это часть архитектуры.

Если фронтенд не понимает, как они работают,
безопасность становится случайностью.

LLM в продакшене: реальные проблемы

В демо всё выглядит магией:
модель отвечает, пишет код, общается как человек.

В продакшене начинается реальность.

И она гораздо менее глянцевая 👇

1️⃣ Галлюцинации — уверенно, но неправильно

LLM не “знает”.
Она генерирует наиболее вероятный ответ.

Поэтому:
👉 придумывает факты
👉 ссылается на несуществующие источники
👉 уверенно врёт

Самое опасное — звучит правдоподобно.

2️⃣ Нестабильность ответов

Один и тот же запрос:

👉 сегодня → один ответ
👉 завтра → другой
👉 с чуть изменённой формулировкой → третий

Для бизнеса это боль.

👉 сложно тестировать
👉 сложно гарантировать качество

3️⃣ Prompt engineering — это костыль

В теории:
«просто напиши хороший prompt»

На практике:

👉 десятки версий prompt’ов
👉 постоянный тюнинг
👉 ломается от малейших изменений

Это не инженерия. Это шаманство с контролем версий.

4️⃣ Стоимость растёт незаметно

Каждый запрос = токены = деньги

А дальше:
👉 длинные контексты
👉 RAG
👉 chain’ы
👉 retries

Прототип за $50 превращается в систему за $5000+.

5️⃣ Latency убивает UX

LLM думает долго:

👉 1–3 секунды — норм
👉 5–10 секунд — уже раздражает
👉 10+ секунд — пользователь ушёл

Особенно критично для:
👉 чатов
👉 real-time систем
👉 API

6️⃣ Evaluation — это ад

Как понять, что стало лучше?

👉 accuracy не работает
👉 метрик нет
👉 нужно вручную оценивать ответы

Evaluation = дорого + субъективно + медленно.

7️⃣ Безопасность и контроль

LLM может:
👉 сгенерировать токсичный текст
👉 выдать приватные данные
👉 обойти ограничения

Нужны:
👉 guardrails
👉 фильтры
👉 логирование
👉 мониторинг

8️⃣ Контекст — ограниченный ресурс

Даже у больших моделей:

👉 ограничение на токены
👉 длинные диалоги ломаются
👉 важная информация теряется

Поэтому без RAG никуда.

💥 Главный инсайт

LLM в продакшене — это не про модель.

Это про систему вокруг неё:
👉 retrieval
👉 кеширование
👉 monitoring
👉 fallback’и
👉 eval pipeline

В одном предложении

Сложность LLM-продукта — не в том, чтобы «подключить GPT»,
а в том, чтобы сделать его надёжным.

ROC-AUC vs PR-AUC: когда что использовать

ROC-AUC и PR-AUC — две метрики, которые постоянно путают.
И чаще всего выбирают не ту.

Разберём на пальцах 👇

📈 Что такое ROC-кривая

ROC-кривая показывает:

👉 TPR (Recall) — сколько положительных нашли
👉 FPR — сколько отрицательных ошибочно посчитали положительными

Насколько хорошо модель отделяет классы.

ROC-AUC — площадь под этой кривой.

📊 Что такое PR-кривая

PR-кривая показывает:

👉 Precision — насколько точны предсказания
👉 Recall — сколько положительных нашли

Насколько хорошо модель находит редкий класс без мусора.

PR-AUC — площадь под этой кривой.

⚔️ Главная разница

👉 ROC-AUC → разделимость классов
👉 PR-AUC → качество положительных предсказаний

🚨 Где все ошибаются

Используют ROC-AUC при сильном дисбалансе классов.

Почему это плохо?

👉 FPR считается по огромному количеству негативов
👉 даже плохая модель может выглядеть «хорошо»

ROC-AUC становится слишком оптимистичной.

📉 Когда нужен PR-AUC

Если у тебя:

👉 fraud detection
👉 churn prediction
👉 medical diagnosis
👉 rare event detection

👉 используй PR-AUC

Потому что тебе важно:

👉 находить редкий класс
👉 не засыпать всё false positive

📈 Когда подходит ROC-AUC

Если:

👉 классы более-менее сбалансированы
👉 важна общая separability
👉 задача — в целом отличать классы

👉 тогда ROC-AUC ок

🧠 Интуитивный пример

Представь:

👉 1% — мошенники
👉 99% — нормальные

Модель говорит «всё ок» почти всегда:

👉 ROC-AUC может быть высоким
👉 PR-AUC будет низким

Потому что модель не ловит мошенников.

💥 Главный инсайт

ROC-AUC отвечает на вопрос:

Модель в принципе различает классы?

PR-AUC отвечает на вопрос:

Насколько полезны её положительные предсказания?

В одном предложении

Если класс редкий — PR-AUC важнее ROC-AUC.
Если баланс нормальный — можно использовать ROC-AUC.

ML-модели становятся помощниками в принятии решений на рекламных платформах

Технический директор рекламной платформы Т-Банка Василий Разумных рассказал, как работает система, в которой модели используются не только для предсказания кликабельности. По его словам, ML-модели определяют, что показывать конкретному человеку в определенный момент времени. На смену ручной сегментации приходит ML-таргетинг: система сама находит нужную для цели аудиторию. Скоринговая модель помогает в ранжировании: она учитывает экономическую эффективность, вероятность действия и репутацию рекламодателя.

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