Как пишет промпты инженер Антропик, создавший Fable Недавно мы перевели выступление инженера Anthropic - Тарика Шихипара. Оттуда мне запомнился довольно простой слайд «Матрица неизвестных». Он показывает, что при работе над любой сложной задачей с ИИ-агентом есть четыре типа знания: • Known knowns - что я знаю. • Known unknowns - что я знаю, что не знаю. • Unknown knowns - что я знаю, но даже не думаю об этом как о знании. • Unknown unknowns - то, о существовании чего я вообще не подозреваю. Тарик использует эту матрицу, когда работает с моделями: его задача - максимально сблизить «карту у себя в голове» с реальной территорией, по которой потом пойдёт агент. Мне кажется, это очень хорошая модель и я интуитивно применяю ее же. Как это работает: 1. Что я точно знаю Это самая очевидная часть промпта. Например, мы делаем проект для университета. Я могу написать модели: Есть вуз на 40 000 студентов и 10 000 преподавателей. Мы хотим развернуть внутри него ИИ-инфраструктуру. Есть такой-то бюджет. Есть такие-то серверы. Вот наш продукт. Вот какой результат должен получить заказчик. Это факты. Чем больше действительно важного контекста модель получает здесь, тем меньше ей приходится додумывать картину самостоятельно. Но интересное начинается дальше. 2. Что я понимаю, что пока не знаю Например: • я ещё не понимаю, какая архитектура будет оптимальной; • не знаю реальную пиковую одновременную нагрузку; • не знаю, лучше купить больше GPU сейчас или оставить возможность масштабирования; • не знаю, что окажется важнее для заказчика: стоимость, безопасность или скорость запуска. Это тоже очень полезно прямо писать в промпте. Не обязательно сначала самому принимать решение. Я вполне могу сказать: Здесь я пока не понимаю, какой вариант правильный. Рассмотри несколько архитектур и покажи, от каких предположений зависит выбор. То есть хороший промпт - это не обязательно демонстрация абсолютной уверенности. Иногда фраза «вот здесь я не знаю» даёт модели больше, чем пять абзацев плохо обоснованных предположений. 3. То, что я знаю, но могу забыть объяснить модели Вот эта категория мне особенно нравится. Потому что в реальных бизнес-задачах большая часть контекста именно такая. Например, мы готовим техническое задание. Формально задача может выглядеть совершенно нормально. Но я знаю, что у функционального заказчика есть конфликт с IT-подразделением. Для меня это часть картины мира. Я несколько месяцев общаюсь с этими людьми и автоматически это учитываю. А для модели этого знания не существует, пока я его не написал. А ведь оно может полностью изменить результат. Я могу сказать: Учти, что функциональный заказчик заинтересован в проекте, но IT-подразделение относится к нему настороженно. Поэтому архитектура и ТЗ не должны выглядеть как попытка обойти IT. Наоборот, нужно заложить им понятную роль, контроль и ответственность. Технически это вообще не характеристика системы. Но практически это может оказаться одной из самых важных частей ТЗ. Это и есть unknown knowns: знания, которые настолько находятся у тебя в голове, что ты даже не замечаешь, что модель их не знает. 4. То, о чём я вообще не подумал А вот здесь начинается, пожалуй, самое ценное. Допустим, я считаю экономику строительства AI-кластера. Я могу очень хорошо посчитать: GPU → токены → количество агентов → экономика. Но я могу вообще не подумать, например: — о резервировании энергоснабжения; — о сроках поставки оборудования; — о таможенных рисках; — о сетевой инфраструктуре; И проблема в том, что я не могу спросить о том, о существовании чего не знаю. Поэтому здесь мне очень нравится приём Тарика - blind spot pass, проход по слепым зонам. Он прямо просит модель: Изучи задачу и найди те важные обстоятельства, которые я, скорее всего, вообще не учёл. —— Думаю, что в описанном подходе кроется одна из главных причин, почему два человека могут использовать одну и ту же модель и получать совершенно разный результат.