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

На практике это может выглядеть следующим образом. Мы просим LLM оценить, например, релеватность ответа, не одним баллом, а веростностью всех возможных баллов, которые LLM может поставить конкретному ответу, например, 0.8 с вероятностью 60% и 0.5 с вероятностью 40%.

Далее для количественной оценки неопределенности в таких вероятностных распределениях можно использовать энтропию Шеннона: H = -Σ p_i * log₂(p_i). И для примера выше, где LLM выставляет скор 0.8 с вероятностью 60% и скор 0.5 с вероятностью 40%, энтропия составит: H = -(0.6 × log₂(0.6) + 0.4 × log₂(0.4)) ≈ 0.97. Высокое значение энтропии (близкое к 1 для двух опций) указывает на значительную неопределенность в оценке, то есть LLM не может однозначно выбрать один скор. Низкая энтропия (близкая к 0) означает, что LLM уверена в своей оценке. Это позволяет фильтровать случаи с высокой неопределенностью для дополнительной проверки или взвешивать финальные оценки по степени уверенности модели.

По сути, на практике это означает переход от запроса "Какой финальный балл выбрала LLM?” к вопросу "Какой набор разумных интерпретаций определила LLM для оценки метрики?”.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Всем привет!

Рад сообщить, что 15 декабря завершила обучение моя первая группа на курсе по оценке и тестировани ИИ. Это была большая группа, 16 человек, и я рад, что за время курса ребята показали себя классными специалистами по оценки ИИ, успешно справляясь со всеми практическими заданиями!

А практики у нас было много:
- изучали python
- делали оценку моделей машинного и глубокого обучения
- тестировали RAG систему с помощью DeepEval, Opik Comet, RAGAS, Promptfoo, Eval-lib
- работали с оценкой ИИ агентов и анализом трейсов в Langfuse и Langsmith, создавали свои метрики с нуля
- делали оценку изображений через базовые метрики DeepEval и стандарты оценки изображений
- оценивали ИИ чат-бот и многоходовые диалоги
- изучали оценку bias и пробовали взломать ИИ систему
- оценивали модели OpenAI и Google через метрики качества и бенчмарки.

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

А пока напоминаю, что по-прежнему идет набор нового потока на мой курс по тестированию и оценке ИИ.

Если вы еще не приняли решение, то сейчас самое время его сделать, потому что до 31 декабря действует скидка 15% на всю стоимость курса.

Почему важно уже сейчас начать изучать ИИ?

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

Все подробности курса есть на сайте eval-ai.com, где вы уже сейчас можете оставить заявку и с нового года начать изучать действительно перспективное направление тестирования, знания в котором обязательно вам пригодятся в будущем.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

При оценке AI систем в я часто сталкивался с проблемой, что существующие фреймворки оценки ИИ систем, такие как deepeval, opik Comet, promptfoo недостаточно гибки с точки зрения оценки. Зачастую используемая внутри система промптов для lim as a judge не способна адаптировать оценку с точки зрения ее стогости и поэтому происходило так, что в либо оценка была завышенна либо занижена. Кроме того, часто возникал вопрос,а почему оценка получилась именно такой, но в во многих фреймворках это черный ящик, если метрики не рассчитываются математически или на базе ембеддингов.

Все это сподвигло меня на пересмотр подхода lim as a judge и разработки собственного алгоритма оценки, который я назвал Temperature-Controlled Verdict Aggregation via Generalized Power Mean

Чтобы было мною изменено:
- Вместо бинарной или тенарной оценки метрики я использовал 5 балльную шкалу Лакерта
- Финальный скор может адаптироваться под требования оценщика за счет изменения параметра температуры в формуле расчета общего степенного среднего.
- Если температура ближе к 1, то оценка будет больше отдавать внимание вердиктам, которые полностью удовлетворяют критериям оценки, если ближе к 0, то вердикты, не соответствующие критериям оценки больше влияют на расчет финального скора и оценка будет ниже.

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

Ну и последнее - весь процесс оценки полностью прозрачен. В verbose logs вы вы видите все вердикты, их оценку, причину это оценки, а также как был рассчитан математически финальный скор через Generalized Power Mean.

Фреймворк доступен в открытом доступе через python pip install eval-ai-library или в открытом репозитории FLS на гит хаб https://github.com/firstlinesoftware/eval-ai-library.

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

С какой самой большой проблемой вы столкнулись при использовании ИИ в 2025 году?

Давайте поделимся своим опытом! 👇

Для меня самой большой проблемой в этом году остается проблема контекста и аналитических способностей ИИ в плане генерации ручных тестов на основе требований.

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

Надеюсь, в следующем году мы сможем решить эту проблему!


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Осталось всего 8 дней до завершения акции скидка 15% на всю стоимость курса Оценка и тестирование ИИ в рамках набора новой группы, которая стартует 15 января!

Поэтому, если думали, забыли и не оставили заявку, то можно сделать это прямо сейчас на сайте eval-ai.com!

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

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

А в новом 2026 году я хочу поставить себе более амбициозную цель - создать полноценное международное AI evaluation Community, где можно будет обмениваться опытом, знаниями, получать свежую информацию о новых трендах и изменениях в оценке ИИ систем, так что думаю уже скоро смогу порадовать вам новой платформой, которая будет объединять большое количество специалистов по оценке AI не только из РФ, Беларуси или Украины, но и по всему миру!


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Привет всем, продолжаем разбираться в оценке AI.

Сегодня я хочу немного рассказать про фреймворк оценки ИИ систем, которые ранее я еще не упоминал на моем канале - это Opik Comet.

Начну с того, что по сравнению с тем же DeepEval, который имеет большие ограничение на бесплатной версии с точки зрения оценки ИИ систем через UI интерфейс, в этом плане возможности, которые доступны у Opik, в разы выше.

Opik фактически полностью опенсорсный фрейморк, включая использование SaaS Cloud UI версии для своего проекта, где доступны доступны бесплатно практически все ключевые функции, которые нужны для оценки ИИ системы:
⁃ подключение трейсов к вашему ИИ приложению (в бесплатной версии доступно до 25 тысяч спанов в месяц, что в целом хватил для 3-5 средних ИИ проектов)
⁃ управление проектами, датасетами и запусками оценки
⁃ эврестические (20 метрик) и LLM-as-a-Judge (23 метрики)
⁃ оценка на production в режиме реального времени
⁃ промпт менеджмент и playground для тестирования промптов


Проект доступен по ссылке https://www.comet.com/site/products/opik/ и также у него есть достаточно подробная документация по интеграции и работы с ним.

Поэтому, если искали альтернативы существующим фреймворкам оценки ИИ систем, то советую присмотреться к Opik Comet.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня будет последний пост в этом году!

И я решил, что если у вас будет много свободного времени и нечем заняться в ближайшие пару недель, то советую посмотреть открытый базовый курс от университета Stanford по трансформерам и большим языковым моделям. 8 лекция кстати посвящена оценки LLM систем.

Ссылка на записи курса https://youtube.com/playlist?list=PLoROMvodv4rOCXd21gf0CF4xr35yINeOy&si=sNh9N0ZR9f79iLcy

Также напоминаю, что через 5 дней заканчивается скидка на новый поток на курсе по оценке и тестированию ИИ, поэтому если еще не записались, самое время это сделать сейчас тут eval-ai.com


Ну и в целом всем желаю праздничного настроения и с наступающим Новым годом!🎄


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Новогодние праздники у большинства закончились (хотя там где я живу их нет в таком количестве), и я возвращаюсь к вам.

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

Ну и конечно прикладываю ссылку на мою работу, кому интересно почитать

https://zenodo.org/records/18120416


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Тема AI evaluation сейчас на слуху, но я замечаю, что многие команды наступают на одни и те же грабли, когда начинают внедрять оценку качества своих LLM-решений.

Итак, первая ошибка - это оценивать только на “хороших” примерах. Команда собирает датасет из типичных запросов, ИИ система справляется отлично, все довольны. А потом на проде пользователь пишет что-то неожиданное, и всё разваливается. Edge cases в AI - это не исключение, а правило.

Вторая - полагаться только на автоматические метрики. Answer Relevancy, Task Completness, Level of Hallucinations - это все классно для отчетов, но они часто не ловят то, что видит человек. Ответ может быть формально похож на эталон, но по смыслу нести полную чушь, поэтому ручная валидация результатов по прежнему важна.

Третья ошибка - не версионировать датасеты для оценки. Модель обновили, промпт поменяли, а тестовые данные остались те же полугодовой давности. И непонятно уже, стало лучше или хуже, потому что сравнивать не с чем.

Четвертая - игнорировать контекст использования. Одна и та же модель может отлично работать для саммаризации и полностью провалиться в диалоговом сценарии. А команда оценивает всё одним набором метрик и удивляется, почему пользователи жалуются.

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

AI evaluation - это не финальный этап, а непрерывный процесс. И чем раньше команда это понимает, тем меньше сюрпризов на проде.

А вы как подходите к оценке качества AI-решений?
Используете автоматику, ручную оценку или комбинируете? 👇


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Anthropic недавно выпустил отчет по экономическим метрикам использования Claude. И там есть интересные данные, которые заставляют задуматься о том, как мы вообще подходим к оценке.

Первое, что бросается в глаза, success rate в реальных задачах сильно зависит от их сложности. Claude успешно справляется примерно с 67% задач на Claude.ai и только с 49% через API. Казалось бы, одна и та же модель, но разница колоссальная и дело не в модели, а в контексте использования. Многошаговые разговоры с возможностью уточнить и скорректировать курс дают принципиально другой результат, чем одиночные запросы.

Второй момент - это task horizons. Есть известный тренд, что чем дольше решается задача (или открыт чат), тем ниже вероятность успеха. METR (бенчмарк) показывает, что Sonnet 4.5 достигает 50% успеха (снижается) на задачах примерно за 2 часа, но в реальном использовании эта граница сдвигается до 19 часов, потому что пользователи разбивают сложные задачи на шаги, получают обратную связь, корректируют направление. Это совершенно другой процесс, которуй бенчмарки просто не захватывают.

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

Что это значит для eval? Мне кажется, мы слишком увлеклись синтетическими бенчмарками и забыли, что реальная эффективность AI больше не про модель в вакууме, а про систему человек-AI в конкретном контексте использования. В целом отчет показывает, что evaluation AI-систем должен учитывать не только, что модель может делать в идеальных условиях, а как она работает в реальных сценариях с реальными пользователями. И это, кажется, пока слепая зона индустрии.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

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

Если в случае с обычными LLM мы оцениваем качество ответа, например, релевантность, точность, отсутствие галлюцинаций, то с агентами появляются новые метрики. ИИ Агент не просто генерирует текст, он принимает решения, выбирает инструменты, выстраивает цепочку действий для достижения цели и каждый из этих шагов может пойти не так.

Что конкретно нужно оценивать у агентов помимо качества финального ответа:
Reasoning relevancy - насколько логика рассуждений агента соответствует запросу пользователя
Task decomposition efficiency - способность разбивать сложные задачи на подзадачи
Tool selection accuracy - выбирает ли агент правильный инструмент для конкретной задачи
Tool call precision - корректность параметров при вызове инструментов
Agent consistency - стабильность результатов при похожих входных данных

Интересно, что публичные лидерборды типа Hugging Face Open LLM Leaderboard здесь практически бесполезны. Они тестируют базовые LLM на generic NLP-задачах, например, Q&A, reasoning, sentence completion. Но enterprise-агент работает в контексте конкретных бизнес-процессов, данных и интеграций. Результаты бенчмарков просто нельзя перенести на оценку агента в продакшене.

Еще один момент, который часто упускают, что оценка должна происходить на двух этапах. Первый - это pre-production evaluation во время разработки, когда анализируются логи и траектории выполнения. Второй - это real-time evaluation в продакшене, когда метрики собираются непрерывно. И второй этап критически важен, потому что без него вы не узнаете, когда агент начнет "сходить с рельс".

Отдельная история - это guardrails и риски. OWASP недавно выпустил whitepaper (ссылка тут) про угрозы agentic AI, и там 16 категорий рисков. От tool misuse и memory poisoning до cascading hallucination attacks. И ключевая мысль в том, что нельзя просто повесить один центральный слой guardrails на все случаи жизни. Защитные механизмы должны быть специфичны для конкретного кейса и встроены в соответствующие компоненты архитектуры.

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

Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Хочу поделиться с вами простым подходом к использованию подхода LLM-as-a-Judge.

Шаг первый. Забудьте про общие инструкции вроде "оцени релевантность”, вместо этого напишите список из 5-7 конкретных критериев для проверки, например, есть ли в ответе выдуманные факты, соответствует ли длина заданному лимиту, использован ли правильный тон и так далее. Каждая проверка должна давать бинарный результат да или нет.

Шаг второй. Создайте структурированный вывод от модели в JSON или другом формате, где для каждого критерия есть три поля: сам критерий, вердикт LLM по нему, подтверждение вердикта (доказательство).

Шаг третий. Прогоните через LLM-as-a-Judge 20-30 примеров где вы сами знаете правильный ответ и посмотрите, где LLM ошибается. Обычно проблема в формулировке критерия, а не в самой модели.

Этот процесс может занять время, но он превращает LLLM-as-a-Judge из непредсказуемого оценщика в инструмент, которому можно доверять и вы всегда понимаете, почему получили ту или иную оценку, а также можете исправить алгоритм оценки.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

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

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

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

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

Именно поэтому на своем курсе я в первых лекциях даю базу по ML/DL, чтобы у ученика было понимает того, как работают разные модели, какие алгоритмы используются, в чем отличие дискриминативных моделей от генеративных и много другое, что потом позволяет более экспертно подходить к оценке уже больших LLM систем.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Популярное мнение в сообществе AI evaluation сейчас такое, что бинарные метрики (где ответ да или нет) надежнее, но я хочу предложить другой взгляд на это.

Мы тестировали оба подхода на задаче оценки качества ИИ систем, и бинарная оценка говорила нам что 78% ответов хорошие, но полезная ли это информация? Не особо.

Использование шкалы Ликерта от 1 до 5 показало совсем другую картину, мы увидели, что модель стабильно получает 4 за полноту и 2-3 за краткость ответов и это уже конкретный сигнал для улучшения промпта.

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

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

Поэтому выбор алгоритма оценки для создания своего фреймворка и промптов оценки зависит только от задачи, которую вы хотите решать


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Всем привет!!!

Итак, вчера Anthropic выпустила новую модель Claude Opus 4.6 и я конечно не мог пропустить это, так как являюсь активным пользователем Claude Code в своих задачах.

Вот ссылка на релиз

Что нового?

Модель стала заметно лучше в агентных сценариях. Она теперь еще лучше и более осознанно планирует шаги, дольше держит фокус на длинных задачах и умеет ловить собственные ошибки при ревью кода. Контекстное окно выросло до 1M токенов, это впервые для моделей класса Opus.

Теперь почему это важно для автоматизации тестирования. Мы все знаем боль с поддержкой тестов, UI поменялся и у вас сотня упавших автотестов которые нужно руками чинить (это если проект сразу не стали делат по уму, а такое бывает частенько😂). Self-healing инструменты существуют давно, но они работают на уровне “поискать похожий элемент на странице". С агентом на Opus 4.6 можно сделать принципиально иначе, потому что теперь он может посмотреть коммит который сломал тесты, понять что именно изменилось в приложении, обновить и селекторы и логику проверок и даже добавить новые тест-кейсы на появившуюся функциональность.

Для меня это история не про далекое будущее, а про то что можно попробовать уже сейчас. API доступен, Claude Code поддерживает agent teams, осталось собрать пайплайн и проверить на реальном проекте. Чем и займусь в ближайшее время!

Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Многие из вас наверное знают, а если нет, то теперь будете знать, что существует такой ресурс как Hugging Face c огромным выбором ИИ моделей под любые задачи. И число этих моделей растет, компании, просто люди, ученые выкладывают свои наработки в надежде, что они помогут другим в решении различных задач.

Фактически на Hugging Face сейчас больше двух с половиной миллионов ИИ моделей и большинство на самом деле загружены людьми, о которых мы ничего не знаем. И этот повод насторожиться!

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

Как пример могу привести ситуацию с одной из самых популярных моделей распознавания изображений- YOLO. Недавнее исследование (Gala et al., 2025, International Journal of Information Security) показало, что с помощью специально сгенерированных изображений, похожих на обычные объекты можно заставить модели YOLOv5, v8, v9 и v10 полностью игнорировать людей на изображениях. При этом чем меньше модель, тем проще её обмануть. То есть вы берете популярную open-source модель, ставите ее в свой пайплайн, а она уязвима к атакам, о которых вы даже не задумывались.

Поэтому я считаю, что Red teaming для опенсорсных моделей это не паранойя, а базовая необходимость, которую многие очень часто игнорируют. Проверьте откуда пришла модель, кто ее создал, какие данные она видит, потратьте неделю на проверку безопасности вместо месяцев на разбор инцидента.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

100 000 ⭐️ на GitHub за 2 недели после старта, через месяц перевалил за 160 000 ⭐️, дважды сменил название из-за бешеной популярности, в общем сегодня хочу рассказать вам про OpenClaw, который стал главным AI-хитом начала 2026 года, и я решил разобраться почему.

Как написали в одной статье, главное отличие от привычных нам LLM в том, что “Если Claude Code на вашем компьютере - это молоток, который вы берете в руки, когда нужно, то OpenClaw - это молоток с ногами и руками, который сам приходит и спрашивает, не пора ли что-нибудь прибить”.
В отличии от привычных LLM, OpenClaw не просто отвечает на запросы, он действует автономно и выполняет команды, работает с файлами, интегрируется с внешними сервисами, отправляет сообщения в Telegram и много чего еще. По сути это полноценные вторые руки с головой, но которая требует обучения и настройки

И по факту сейчас возникает два вопроса:
1. Как правильно тестировать инструмент который сам выполняет действия? Нужны новые подходы к верификации, четкие границы полномочий, понимание что может пойти не так.
2. Как использовать его, чтобы создать себе клона, который бы делал автотесты и сам их отлаживал.

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

А если вдруг у вас уже есть опыт запуска openClaw, делитесь в комментариях.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Немного пятничных мыслей…

В последнее время меня что-то закидало рекламой приложений, который с помощью ИИ могут делать за вас отклики (не буду называть имена, но думаю вы тоже видели).

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

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

Так вот вопрос, как думаете , когда ИИ уже будут сам договариваться между собой, а мы просто получим уведомление о собеседовании, или о том что нас взяли?

Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)