TGViewer
Channel Public Channel
PRO продукты и системы | Иннокентий Бодров

PRO продукты и системы | Иннокентий Бодров

@spherical_analyst

Пишу о продуктах, системах и анализе. Показываю, как с помощью AI строю и развиваю собственные проекты — с решениями, ошибками и выводами.
Subscribers
2.62K
Photos
333
Videos
18
Links
614

Showing posts older than #1246 · Back to latest

Older Posts 20 shown
Post #1245 382
🔥 Про демо, факапы и ещё один пункт в моём pre-demo checklist

Вчера был эфир с Антоном, где я собирался показать «Подмастерье» в довольно интересном режиме: полностью локальные модели, работа с требованиями, поиск противоречий между источниками и всё то, ради чего я последние месяцы его строю.

К демо готовился как положено. Все выходные вылизывал сервис, несколько раз прогонял сценарий, в понедельник проверил ещё раз — всё работало. Не молниеносно, потому что модели локальные, но стабильно и вполне адекватно.

И примерно за час до эфира началось.

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

А потом перестала работать даже пересборка приложения.

После некоторого количества инженерной археологии нашли виновника.

Windows Update.

На ноутбуке есть диск C. Windows скачала туда обновление, забила практически всё свободное место и дальше начала довольно эффективно уничтожать мой demo environment. Само «Подмастерье» лежит на D, но сборка локального exe всё равно использует C. В результате не работали модели, приложение и даже возможность нормально его пересобрать.

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

Зато факап оказался полезным.

Во-первых, в pre-demo checklist появился новый пункт: проверить свободное место на системном диске и состояние обновлений Windows. Никогда не думал, что буду это писать, но вот мы здесь.

Во-вторых, я окончательно решил переделать архитектуру «Подмастерья». Вместо монолитного локального exe будет три отдельных слоя: сервис работы с локальными моделями, backend и отдельно UI. Так проще тестировать, отлаживать и, что стало особенно важно после разговора с Антоном, поддерживать разные платформы.

Потому что выяснилась ещё одна интересная вещь: Windows среди аналитиков уже далеко не настолько безальтернативна, как мне казалось. Кто-то работает на Mac, кто-то на обычном Linux, а у кого-то уже Astra Linux, Сбер Linux и прочая корпоративная экзотика.

Поэтому теперь мне нужна помощь зала.

На какой ОС вы работаете как аналитик?

👌 — macOS
👍 — Linux
😭 — Windows

Если у вас какая-нибудь особенно прекрасная корпоративная сборка — рассказывайте в комментариях. Мне теперь это уже не просто любопытно, а вполне себе продуктовый research 😁
  • 👌 7
  • 😢 3
Post #1244 198

Forwarded from PRO продукты и системы | Иннокентий Бодров (Innokenty Bodrov)

24 августа разбираем требования вместе с Антоном Зиминым

Вечером 24 августа проведём совместный эфир с Антоном Зиминым, автором «Чулана системного аналитика».

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

Покажу весь путь: как найти расхождения, выровнять требования, передать постановку агенту и превратить сценарии и e2e-тесты в критерии приёмки. И да, все по максимумум на локальных моделях!!!

Антона зову не поддакивать. Его задача — проверить подход на прочность: где карта источников создаёт лишнюю бюрократию, что мы упускаем при выравнивании и может ли тест, написанный до кода, подтвердить, что агент сделал именно то, что требовалось.

Планируем час: короткая вводная, разбор источников и постановки, затем спор про сценарии, тесты и вопросы.

24 августа, 8 вечера МСК, регистрация тут
Post #1243 377
Все же помнят, что сегодня мы с Антоном будем ковырять требования и ИИ, причем буду показывать как это работает на маленьких локальных моделях
Post #1242 488
Верный SQL, но неверный ответ

Данные не врут, но и не отвечают на все, что о них спрашивают. Валидный SQL возвращает ровно то, что попросили, а не то, что стояло за просьбой. Отсюда классическая история: цифра правильная, но вывод неверный, потому что задача была понята не так.

Работа продуктового аналитика в этом месте близка к работе с требованиями: разобрать, о чем именно спрашивают, проверить допущения, зафиксировать противоречия — и только после этого собирать ответ.

25 августа karpovꓸcourses проводят бесплатный вебинар про этот путь. На реальных примерах пройдут:
— какие вопросы задать заказчику до запроса, чтобы выгрузка отвечала именно на его задачу;
— как проверять данные после выгрузки;
— типовые ловушки в расчетах, из-за которых верный запрос возвращает неверный ответ;
— как превращать таблицу с цифрами в вывод и рекомендацию на языке бизнеса.

Разбирает Дмитрий Бакаев — продуктовый аналитик в «Передовых Платежных Решениях» и выпускник курса «Аналитик данных» karpovꓸcourses. Вопросы принимает в эфире.

За регистрацию сразу приходит карьерный гайд по профессиям в аналитике, после эфира — запись вебинара
Регистрируйтесь по ссылке — https://clc.to/erid_2W5zFJreJrD   

Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFJreJrD 
  • 👍 1
Post #1241 568
24 августа разбираем требования вместе с Антоном Зиминым

Вечером 24 августа проведём совместный эфир с Антоном Зиминым, автором «Чулана системного аналитика».

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

Покажу весь путь: как найти расхождения, выровнять требования, передать постановку агенту и превратить сценарии и e2e-тесты в критерии приёмки. И да, все по максимумум на локальных моделях!!!

Антона зову не поддакивать. Его задача — проверить подход на прочность: где карта источников создаёт лишнюю бюрократию, что мы упускаем при выравнивании и может ли тест, написанный до кода, подтвердить, что агент сделал именно то, что требовалось.

Планируем час: короткая вводная, разбор источников и постановки, затем спор про сценарии, тесты и вопросы.

24 августа, 8 вечера МСК, регистрация тут
  • 👍 1
Post #1240 381
Собирая первую версию продукта, легко попытаться положить в неё весь замысел.
Когда я задумывал сквозной кейс Acme Pay с TDPD, хотел показать весь путь: от пяти противоречащих друг другу источников до реализации агентом, e2e-тестов и приёмки.
По ходу сборки выяснилось, что первая половина уже существует как связный кейс. Есть исходные документы, карта источников, противоречия, журнал решений и рабочая постановка.

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

Можно было всё равно собрать красивый сквозной рассказ. Но тогда материал выглядел бы законченнее, чем он есть сейчас.
Поэтому в кейсе Acme Pay я оставил только то, что могу предъявить и проверить: источники, найденные разрывы, решения и переход к постановке. Рядом объяснил, где начинается TDPD, но не стал выдавать незавершённую часть за готовый универсальный процесс.

Мне всё больше нравится такое определение первой версии: она заканчивается не там, где кончились силы, а там, где кончились подтверждённые обещания.
Post #1239 367
🔥 Будни вайб-фаундера, вайб-кодера и немножко продакт-овнера

Договорились мы сегодня с моим AI-помощником по стратегическому планированию, что пора запускать очередной небольшой эксперимент: новый микропродукт, проверка спроса, лид-магнит, оплата — всё по канонам продуктового маркетинга.

Казалось бы, чего сложного? Берём существующий сайт, делаем страницу, запускаемся.

Прихожу на сайт — а он так не умеет.

Ну ладно, я же теперь вайб-кодер. Допиливаем нужную механику, тестируем — работает. Отлично, можно запускать. Но стоп. Это же продукт, за него предполагается брать деньги. Значит, неплохо бы проверить оплату.

Оплата не работает.

Чиним оплату. Починили, идём дальше — после покупки должно приходить письмо.

Письмо не приходит.

Почему? Потому что кто-то очень умный не настроил почту в переменных окружения. Кто этот человек, история умалчивает, но мы с ним хорошо знакомы.

Настроили. Теперь-то всё?

Конечно нет.

Если мы умеем принимать деньги, неплохо бы ещё проверить возврат. Нажимаю refund и...

Возврат тоже не работает.

Ещё немного отладки, немного нервов, немного мата — и внезапно вся цепочка действительно начинает работать: страница → оплата → письмо → возврат.

И вот что мне особенно нравится в современном вайбкодинге. AI действительно позволяет одному человеку очень быстро собрать продукт, на который раньше понадобилась бы маленькая команда. Но он совершенно не отменяет старую добрую инженерную реальность: между «фича написана» и «продукт работает» находится довольно много неприятных мелочей.

И именно поэтому я всё меньше верю в разработку по принципу «агент сказал done — значит done». Done наступает не тогда, когда код написан, а когда пройден пользовательский сценарий целиком.

Зато теперь могу представить ещё один маленький микропродукт, который, надеюсь, нанесёт вам непоправимую пользу 😁
AnalystCraft Сквозной кейс Acme Pay с TDPD — AnalystCraft Цифровой пакет материалов по сквозному кейсу Acme Pay: Source map, рабочий контекст, постановка и проверка требований.
  • 🔥 1
  • 💯 1
Post #1238 386
Я снова на хабре! Запилил статью про TDPD и то как параллельно со мной это разрабатывают в OpenAI (посмотрим кто кого, хех).

P.S. Статья в песочнице, но если кто то кинет мне инвайт - буду очень благодарен)
  • 🔥 2
Post #1237 461
Наблюдаемость не доказывает, что агент прав

200 OK означает, что запрос завершился. Для AI-агента это почти ничего не говорит о результате.

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

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

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

Поэтому я забираю из статьи в TDPD не новый гейт, а отдельный контракт доказательства запуска. Для каждого значимого прогона должны быть видны:

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

Если обязательной части трассы нет, это не PASS, а INCOMPLETE. Для рискованного действия — остановка. При этом сама трасса не становится судьёй: мы фиксируем критерии приёмки до реализации, а UAT оставляем отдельной человеческой проверкой исходного замысла.

Исходный материал: Designing Observable AI Systems.
Linkedin Designing Observable AI Systems We had an agent complete its workflow successfully and still make the wrong decision. From the application’s perspective, the request completed.
Post #1236 396
👀Что проще - зарабатывать 1 млн руб. в найме или в собственном проекте?

Или все-таки сочетать? Автор этой схемы на своем опыте рассказывает, как сделать миллион в найме, где сейчас стоит учиться, с какой компании начать работу, надо ли «прыгать по компаниям» и как раскачивать личный бренд.

🔥Вот ТОП посты, которые точно пригодятся
- Каких продактов выделяет рынок труда
- Какие продакты сейчас самые востребованные на рынке
- МОК-собес на product manager

Ну и вот что нам особо интересно:
🔴45 офферов по разным ИТ ролям: от аналитика до тим тим лида за 850к
🔴Какой продакт лид получил 12 млн по году
🔴Оффер на Product lead в Яндекс

Много полезненького ))
💬@proProject1
Telegram Про Проекты и карьеру в ИТ | Романова Как зайти в ИТ и выйти с ЗП в 1 млн. 🍋Лимонный Алгоритм🍋 Навеяно вашими запросами у нас в анкетах на карьерное сопровождение- все хотят мильОны зарабатывать - ну ок, давайте разбираться, что нужно для этого сделать в найме. Сразу задам условия. Обсуждаем…
Post #1235 411
Открыл спецификацию, которую сам писал в июне, и не смог объяснить, почему суммы там хранятся в копейках целым числом.

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

В спецификации от всей этой истории осталась одна строчка: «система хранит сумму платежа».

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

Таких микрорешений на нормальном проекте десятки. Пока документ читает человек, часть контекста ещё можно восстановить по переписке, памяти команды и сакральному «мы же это обсуждали». С агентом этот фокус работает гораздо хуже: если причины нет в контексте, он её не восстановит. Он просто достроит наиболее правдоподобную — и в следующий раз вполне может достроить другую.

Поэтому я завёл Decision Log. Девять полей, из них четыре обязательных, на запись обычно уходит около минуты. Файл лежит рядом с остальным контекстом проекта, а из спецификации на конкретные решения можно ссылаться по ID.

Получается довольно простое разделение: спецификация хранит, что система должна делать. Decision Log — почему мы решили делать именно так.

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

Шаблон, YAML-версия и заполненный пример:https://analystcraft.ru/blog/decision-log-analitika?utm_source=tg_spherical&utm_medium=social&utm_campaign=lm03_decision_log&utm_content=20260815-decision-log
AnalystCraft Decision Log для аналитика: журнал решений, которые вы приняли молча Шаблон журнала аналитических решений на одну строку в минуту. Зачем он нужен агенту, чем отличается от ADR и как начать вести на текущем проекте.
  • 👍 6
  • 🔥 2
  • 💯 1
Post #1234 418
Вот мне интересно, если у чувака сеньоры скатились до уровня джунов, то насколько они были сеньорами? И что их мотивировало делать свою работу качественнее?
Может им просто KPI поставили на количество строк кода и покрытие тестами?)
Ну серьезно, как может быть, что нормальный специалист, получив ИИ перестает думать?

А вообще я понял, почему люди так не любят ИИ, потому что он пишет код не так как они. И они ему не доверяют. А еще он пишет код правильнее, дада и не поддерживает их говно код и костыли, которые годами никто не трогал.
  • 👌 1
Post #1233 444
  • 🔥 3
  • 👍 1
  • 💯 1
Post #1232 322
С одной стороны смешно и отовсюду слышится что ИИ делает шляпу, а с другой стороны, я видел столько говнокода, который люди написали еще до ИИ, что вот эта шутка уже перестает быть шуткой
Post #1230 418
Агент по умолчанию не задаёт уточняющих вопросов. И вот здесь начинается самое интересное.

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

Хуже того: в следующем прогоне он может закрыть ту же дыру уже иначе.

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

1. «И так далее». Если список не дописан, агенту приходится решить, что именно скрывается за этими словами. В итоге вы получаете не продолжение своего списка, а вполне логичную интерпретацию модели.

2. Отсутствующие границы. В спецификациях хорошо описывают, что система должна делать, и гораздо реже — чего она делать не должна. Для человека часть этих границ может быть очевидна из контекста. Агент этого контекста не знает и начинает вполне добросовестно достраивать функциональность, которую никто не заказывал.

3. Молчаливые решения. «Тут и так понятно», «мы это обсуждали на встрече», «все знают, почему выбрали именно так». Пока решение живёт в голове команды, для агента его просто не существует. Он примет своё, а через месяц уже никто не вспомнит, откуда вообще взялось текущее поведение системы.

Поэтому перед тем, как отдавать спецификацию агенту, я теперь проверяю не только то, что в ней написано, но и то, что агенту придётся додумать самому.

Собрал 12 таких мест в один чек-лист. Проверка занимает примерно минуту на пункт — и делать её лучше до того, как агент начал писать код, а не после того, как его интерпретация превратилась в работающую систему.

👉 Чек-лист:https://analystcraft.ru/blog/checklist-spec-dlya-agenta?utm_source=tg_spherical&utm_medium=social&utm_campaign=lm02_checklist&utm_content=20260811-checklist-spec
AnalystCraft Спека, которую агент не переврёт: 12 проверок спецификации Двенадцать мест, где спецификация оставляет ИИ-агенту свободу додумывать. Чек-лист для системного аналитика, проверка занимает минуту на пункт.
  • 👍 1
Post #1229 391
Отдайте агенту пять документов, из которых два врут, — и он, скорее всего, не скажет вам, какие именно.

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

Сначала я думал, что это лечится простой инструкцией: «проверяй источники на актуальность». Оказалось, нет.

Самое забавное, что модель действительно проверяет. Она может совершенно честно написать: документ A обновлён месяц назад, документ B — два года назад, между ними есть противоречие. А следующим шагом так же честно собрать информацию из обоих в один гладкий ответ.

Потому что её попросили ответить на вопрос, а не сохранить неопределённость.

У меня сработал другой подход: вообще не задавать основной вопрос, пока источники не разложены на столе. Сначала Source Map: что это за документ, кто его владелец, когда он обновлялся, насколько ему можно доверять и с чем он конфликтует. И только когда эта карта появилась — задавать вопрос по самой задаче.

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

Зато противоречия не растворяются в хорошем тексте, а у каждого вывода остаётся основание.

Пожалуй, это и есть главное: сначала разобраться, на чём может стоять ответ. И только потом просить AI его дать.
  • 🔥 4
Post #1228 406
На этой неделе поймал себя на ошибке, за которую обычно ругаю чужие проекты.
В одном документе у меня написано 59,7%, в другом — 10 из 10. На первый взгляд кажется, что кто-то ошибся. На самом деле обе цифры правильные.
Просто они относятся к разным бенчмаркам, разным метрикам и отвечают на разные вопросы.
Когда работаешь с этим каждый день, нужный контекст живёт в голове. Ты автоматически помнишь, что здесь измеряли качество по ролевым сценариям, а там — семантическое соответствие. Кажется, что это очевидно.
Перестаёт быть очевидно ровно в тот момент, когда цифра оказывается в статье, презентации или посте.
Человек, который открывает только один документ, этой рамки уже не видит. Для него это просто две противоречащие друг другу цифры.
Самое смешное, что решение этой проблемы я сам уже несколько лет показываю на докладах.
В Source Map есть простая колонка:
«С чем спорит этот источник?»

Она заставляет явно фиксировать такие вещи.
Какие документы противоречат друг другу.
Какие метрики нельзя сравнивать напрямую.
Какие выводы верны только в рамках конкретного эксперимента.
На собственных материалах я эту колонку... не завёл.
Похоже, Source Map нужен не только аналитикам.
Иногда он нужен и автору Source Map. 😄
Post #1227 441

Forwarded from Читатель Use Case'ов

Читатель Use Case: дайджест за 3 дня

5 лучших материалов:
1. Fragments: August 4
Коротко: Разбор рисков ИИ: от несанкционированного доступа моделей до признаков пузыря в отрасли. Полезно практикам как напоминание про безопасность, контроль экспериментов и трезвую оценку внедрений.
https://martinfowler.com/fragments/2026-08-04.html

2. Пять вопросов, на которые должны отвечать ваши данные, прежде чем с ними начнёт работать ИИ-агент / Хабр
Коротко: Материал о том, какие требования к качеству и структуре данных нужны перед запуском ИИ-агента поверх BI. Полезно тем, кто хочет избежать ошибок на старте и подготовить данные к автоматизации ответов.
https://habr.com/ru/companies/glowbyte/articles/1066002/?utm_campaign=1066002&utm_source=habrahabr&utm_medium=rss

3. Что реально происходит с ИИ-трансформацией российского бизнеса: семь наблюдений с двух конференций / Хабр
Коротко: Сводка повторяющихся выводов с двух конференций о внедрении ИИ в российский бизнес. Полезно практикам, чтобы увидеть, где трансформация уже даёт эффект, а где ожидания пока опережают реальность.
https://habr.com/ru/companies/alpinadigital/articles/1066708/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1066708

4. From weeks to minutes: How Formula 1® uses agentic AI on AWS to accelerate data operations | Artificial Intelligence
Коротко: Кейс о том, как агентный ИИ ускорил работу с данными и сократил онбординг источников с недель до минут. Полезно тем, кто строит data-платформы и ищет способы автоматизировать рутину и контроль изменений.
https://aws.amazon.com/blogs/machine-learning/from-weeks-to-minutes-how-formula-1-uses-agentic-ai-on-aws-to-accelerate-data-operations/

5. Ассистент или агент: я делал одну контент-машину тремя способами / Хабр
Коротко: Сравнение трёх подходов к сборке контент-пайплайна: вручную, в n8n и на Python. Полезно, чтобы выбрать уровень автоматизации под задачу, бюджет и требования к гибкости.
https://habr.com/ru/companies/alpinadigital/articles/1066684/?utm_campaign=1066684&utm_source=habrahabr&utm_medium=rss
martinfowler.com Fragments: August 4 responsibility for rogue agents, indicators of a bubble bursting, dread of AI, praise for gov.uk, getting data out of closed packages, eyes on Clacton
Post #1226 391
Новости, что я тут делаю. Во первых пересобрал читателя Use Caseов - теперь он раз в день постит дайджест из 5 статей про анализ, разработку, ИИ и все вокруг этого. Плюс более подробный разбор одной статьи! Подписывайтесь, комментьте, закидывайте ссылки на источники которые добавить.

Во-вторых, я активно погрузился в процессы выпуска электронной подписи и делаю собственный прототип для Самсаба на Advnced electronical signature. Использую свой фреймворк Test driven product development на полную катушку с кучей агентов, но тут наткнулся на то, что именно в этом проекте надо жестко упороться в безопасность.

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

Буду супер благодарен, если вы его попробуете и дадите комментарии по улучшению!
Post #1225 438
Одна из самых частых ошибок при работе с LLM выглядит примерно так.

Вы просите модель написать код.
Потом, не меняя контекст, говорите: «А теперь проверь, всё ли здесь правильно.»
Она находит пару мелких замечаний, что-то косметически поправляет и в итоге говорит: «В целом решение корректное.»

Честно говоря, было бы странно ожидать другого.

Модель не перечитывает код «свежим взглядом». Она продолжает тот же разговор, в котором уже построила гипотезу, что это решение хорошее. Проверка превращается не в независимое ревью, а в продолжение собственной цепочки рассуждений.
Я столкнулся с этим, когда гонял локальные модели на собственном харнессе. Я проверял их на десяти сценариях, и долго не мог понять, почему результаты выглядят прилично, а реальной работы почти нет.

Ответ оказался неприятно простым.

Модель сначала генерировала решение, а потом сама же его подтверждала.
После разделения контекстов качество выросло заметно.
Теперь одна роль только строит решение и вообще ничего не знает о том, что его потом будут проверять. Вторая получает только готовый результат и задачу его сломать. Без истории диалога, без объяснений, без «я уже думал над этим». Третья вообще работает отдельно — она смотрит только на источники и пытается найти противоречия между ними и тем, что получилось.

И здесь, как мне кажется, важен один момент.

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

Попробуйте вспомнить свою последнюю задачу.

Сколько раз вы просили модель проверить то, что она сама только что и написала?
  • 💯 5
  • 👍 2
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →