Почему генерация идей - плохая отправная точка для ИИ-исследования
Запрос «предложи 20 идей для ERP-компонента планирования» выдаёт список за минуту и почти не двигает работу. «Самая простая ошибка при работе с искусственным интеллектом - начать с генерации идей», так формулирует проблему автор разбора метода «Глаз стрекозы» (Глаз стрекозы: практическая технология исследования с ИИ).
Причина в асимметрии ответов. Модель одинаково уверенно выдаёт рабочую аналогию и пустую: она охотно предложит десятки связей между биологией, экономикой, производством, логистикой, теорией устойчивости и любой другой областью. Часть связей окажется интересной, часть банальной, часть - просто красивой языковой конструкцией. На этапе списка отличить одно от другого нечем: критерия нет, потому что предмет ещё не описан.
Дальше сценарий предсказуем. Вы берёте понравившийся пункт, приносите в проект и видите, что термины совпали, а поведение сущностей нет. «Обязательство» в праве и «обязательство» в производственном плане звучат одинаково и означают разное. Переделывать приходится не идею, а всю постановку задачи.
«Глаз стрекозы» переворачивает порядок работы: сначала дисциплина предметного различения, потом гипотезы. Главный вопрос смещается с «что придумать» на «какими сущностями я оперирую и какие предметные миры имею право сравнивать». Модель подключается как инструмент нормализации и поиска структурно похожих сущностей, а не как генератор списка идей. Критерий проверки появляется раньше ответа ИИ, поэтому ответ можно принять, отклонить или отложить по известному правилу.
Шаг 1: фиксация направления - что именно вы исследуете и зачем
Стартовая операция метода: зафиксировать, что именно исследуется, какой результат нужен, где проходит граница задачи, что пока неизвестно и какой результат будет считаться достаточным для текущего решения.
На сквозном примере рамка собирается в пять строк. Объект - производственный план. Результат - поле жизнеспособных продолжений, то есть набор допустимых следующих шагов при нарушениях. Ограничение - реальные обязательства предприятия. Практический критерий - компонент помогает принять решение; красивое описание рисков за результат не считается (разбор метода на Habr).
Без такой рамки исследование незаметно расширяется вместе с каждой новой интересной ссылкой: сегодня вы читаете про теорию ограничений, завтра про клеточные автоматы, послезавтра про биржевые стратегии, а компонент планирования стоит на месте. Фиксация направления работает как отсекающий фильтр, а не как бюрократическая формальность.
Чек-лист фиксации направления: 5 вопросов перед стартом
| Вопрос | Пример ответа для ERP-компонента |
|---|---|
| Что именно исследуем | Способы удерживать производственный план жизнеспособным при нарушениях |
| Какой результат нужен | Поле жизнеспособных продолжений: набор допустимых следующих шагов с оценкой обязательств |
| Где граница задачи | Планирование и перепланирование внутри предприятия; внешние контракты учитываются как фиксированные ограничения |
| Что пока неизвестно | Как формально описать жизнеспособность и какие нарушения считать допустимыми |
| Что сочтём достаточным | Руководитель получает непустой набор вариантов и видит цену каждого, вместо отчёта о рисках |
Если хотя бы на один вопрос ответа нет, рамка не собрана, и дальше вы будете собирать не исследование, а коллекцию ссылок. Смежный опыт из архитектурных кейсов: постановка задачи и явный список того, чего в системе не будет, влияют на итоговое решение сильнее любых технических деталей (кейс системы управления корпоративной архитектурой).
Таксоны: нормализованные единицы предмета вместо слов
Таксон - нормализованная единица предмета с паспортом, границами, измерениями, состояниями и источниками. Смысл конструкции простой: таксоны позволяют сравнивать сущности, а не слова. Пока сравнение идёт на уровне терминов, любая метафора выглядит убедительно. Как только сравнение идёт на уровне свойств и поведения, половина аналогий отваливается сама.
В производственном планировании таксонами становятся «операция», «ресурс», «обязательство», «нарушение», «партия», «смена». Каждый описывает не строку в таблице, а класс объектов с известными границами. Если у двух сущностей не совпадают границы, переносить между ними нечего, и это видно до того, как вы потратили неделю на красивую идею.
Структура таксона: паспорт, границы, измерения, состояния, источники
| Элемент | Что содержит | Пример для таксона «производственная операция» |
|---|---|---|
| Паспорт | Идентификатор, краткое определение, владелец описания | OP-01, обработка детали на станке, владелец - технолог |
| Границы | Что входит в таксон и что в него не входит | Входит: машинное время, смена, партия. Не входит: перемещение между цехами |
| Измерения | Единицы и шкалы, в которых описывается сущность | Длительность в минутах, количество в штуках, загрузка станка в процентах |
| Состояния | Допустимые режимы существования | Запланирована, выполняется, выполнена, отменена, сдвинута |
| Источники | Откуда взяты данные и насколько им можно доверять | Выгрузка из MES - высокое доверие, ручная правка мастера - низкое |
Без источников таксон превращается в мнение. Через полгода никто не вспомнит, откуда взялась граница «не входит перемещение между цехами», и проверить её будет нечем.
Как выделить таксоны в своей предметной области
- Выписать ключевые сущности, с которыми работает исследование, обычным списком терминов.
- Для каждой сущности определить границы, измерения и состояния. Здесь обычно обнаруживается, что два «разных» термина описывают одно, а один термин скрывает три разных класса объектов.
- Проверить, можно ли эту сущность сопоставить с сущностью из другой области по границам и измерениям.
- Если сопоставление не проходит, уточнить границы или разбить таксон на два.
Типичная ошибка - слишком общие таксоны вроде «процесс» или «риск». Они не различают сущности, и в итоге вы получаете нормализованное описание, которое ничего не нормализует. Таксон «риск» полезен, когда разбит на «срыв поставки», «поломка оборудования», «нехватка персонала»: у каждого свои измерения и свои состояния.
Сквозной пример: ERP-компонент для производственного планирования
Задача: сделать компонент для ERP-системы, который помогает руководителю видеть жизнеспособные продолжения производственного плана при нарушениях. Дальше вся цепочка от фиксации направления до таксонов разворачивается на этой задаче. Без такой декомпозиции ИИ выдаст общие советы про мониторинг и дашборды, а не рабочую конструкцию.
Выделение предметных фасетов: план, ресурсы, обязательства, нарушения
Фасет - угол рассмотрения предмета. Для планирования достаточно четырёх, пятый (время) идёт как сквозная шкала.
- План: что запланировано и в каком порядке.
- Ресурсы: чем располагаем - станки, люди, смены, материалы.
- Обязательства: что предприятие уже должно - сроки отгрузки, контракты, штрафы.
- Нарушения: что пошло не так - срыв поставки, поломка, нехватка персонала.
Каждый фасет превращается в набор таксонов. Фасет «нарушения» даёт таксоны «срыв поставки», «поломка оборудования», «нехватка персонала» с разными измерениями: у срыва поставки это дни задержки, у поломки - часы простоя. Фасеты не должны пересекаться, иначе таксоны начнут дублироваться, и одно и то же нарушение будет учтено дважды.
Поиск областей возможного межпредметного переноса
После нормализации можно искать структурно похожие сущности в других предметных мирах. Поле жизнеспособных продолжений имеет потенциальные аналоги в теории игр (множество допустимых стратегий), в логистике (перепланирование маршрутов), в теории устойчивости (сохранение функции системы при возмущениях).
Перенос проходит только тогда, когда таксоны сопоставимы по границам и измерениям. Критерии проверки до начала работы: совпадение измерений, совпадение допустимых состояний, совпадение ограничений. Таксон «обязательство» в производстве и «обязательство» в праве выглядят родственными, но границы разные: в производстве это срок и объём, в праве - юридическая сила и ответственность. Перенос без уточнения границ даёт ложную аналогию.
Проверка переноса: как не поверить красивой аналогии
Ответ ИИ сам по себе не доказательство. Модель выдаёт формулировку, но не берёт на себя ответственность за то, что перенос сохранит смысл в вашей предметной области. Проверка распадается на три части: абстракцию конструкции, фиксацию инварианта и независимые линии проверки.
Абстракция конструкции и фиксация инварианта
Абстракция - это выделение того, что именно переносится, без привязки к исходной области. Если переносим идею поля жизнеспособных продолжений из теории игр в ERP, конструкция абстрагируется до «множества допустимых следующих шагов при заданных ограничениях». Инвариант: при любом нарушении множество продолжений остаётся непустым и учитывает обязательства предприятия. Если инвариант не выполняется, перенос не работает, каким бы красивым он ни выглядел.
Рабочий шаблон проверки:
- Сформулировать конструкцию в исходной области.
- Убрать специфичные термины исходной области.
- Проверить, сохранился ли смысл после чистки терминов.
- Записать инвариант: что обязано сохраняться при переносе.
- Проверить инвариант в целевой области на конкретных случаях.
Отдельный вопрос - что из проверенного инварианта уходит в код, а что остаётся на стороне модели. Проверяемое правило лучше держать в детерминированной части, иначе поведение системы начинает зависеть от формулировки промпта (про границу код/модель в LLM-агентах).
Защита от ложной аналогии: критерии проверки
Ложная аналогия - совпадение на уровне слов, принятое за совпадение на уровне сущностей. Отсекать её помогают пять критериев:
- Совпадение границ таксонов: одни и те же объекты входят и не входят в оба понятия.
- Совпадение измерений: обе стороны описываются сопоставимыми шкалами.
- Совпадение допустимых состояний: режимы существования переводятся один в один.
- Проверка на независимых данных, а не на примерах, из которых аналогия родилась.
- Возможность опровержения: вы можете заранее назвать наблюдение, которое убьёт гипотезу.
Пример фальшивой аналогии: «производственный план похож на экосистему». Метафора звучит хорошо, но границы не совпадают (у экосистемы нет внешних обязательств), измерения размыты, а опровергающего наблюдения не придумать. Такие формулировки отбрасываются на первом же критерии.
Независимые линии проверки: почему ответ ИИ - не доказательство
Независимые линии проверки означают, что вывод подтверждается не повторным вопросом к модели, а другими каналами:
- Внешние источники: документация, отраслевые стандарты, публикации по исходной области.
- Логические выводы: проверка того, что инвариант следует из определений, а не из формулировки.
- Эксперимент или симуляция: прогон конструкции на исторических данных предприятия.
- Предметная экспертиза: оценка технолога или плановика, который знает реальные ограничения.
Пример. ИИ предложил связь между теорией устойчивости и производственным планированием. Проверка выглядит так: изучить первоисточники по устойчивости, выяснить, применимы ли их инварианты к производственным обязательствам, прогнать симуляцию на исторических данных о нарушениях. Только после этого перенос считается обоснованным. Пять ответов модели не заменяют пять независимых проверок.
Похожий принцип разделения ролей описан в методологии Agent-Ops: ИИ предлагает, человек утверждает, а исполняет детерминированный контур, который применяет только допущенные действия (Agent-Ops 0.4.0: ИИ предлагает, человек решает, программа исполняет).
Управление исследованием: долг проверки, память об отвергнутых ветвях и остановка
Исследование с ИИ быстро порождает гипотезы и медленно их закрывает. Разница между этими скоростями и есть главный риск: чем больше непроверенных ветвей, тем меньше смысла в новых.
Долг проверки: как не утонуть в непроверенных гипотезах
Долг проверки - накопленные гипотезы, которые ещё не проверены. Его стоит вести реестром, а не в голове.
| Гипотеза | Источник | Статус | Приоритет |
|---|---|---|---|
| Поле продолжений сводимо к графу состояний | Ответ модели, аналогия с планированием в робототехнике | В процессе | Высокий |
| Инвариант устойчивости переносится на обязательства | Ответ модели, литература по теории устойчивости | Не проверена | Высокий |
| Биологическая аналогия с адаптивными системами | Ответ модели | Опровергнута | Закрыта |
После одного запроса к модели в реестре легко оказывается полтора десятка строк. Проверять все подряд бессмысленно: проверка результата обычно дороже генерации вариантов, и эта асимметрия только растёт (почему разработка с ИИ-агентами стала тяжелее). Если долг проверки растёт быстрее, чем закрывается, пришло время резать список, а не добавлять гипотезы.
Память об отвергнутых ветвях: зачем фиксировать тупики
Отвергнутые ветви записываются с причиной отказа. Без этого через месяц вы вернётесь к той же идее, потому что не помните, почему её закрыли.
Формат записи минимальный: ветка, причина отказа, дата, чем проверено. Например: «Перенос из биологии, инвариант не сохраняется на исторических данных, 12 сентября, симуляция на выборке нарушений за квартал». Запись занимает строку и экономит неделю.
Выбор следующей проверки: критерий способности изменить решение
Главный критерий приоритета: проверка должна иметь потенциал изменить решение. Если результат ничего не поменяет, проверку можно отложить или выбросить.
| Влияние на решение | Дешёвая проверка | Дорогая проверка |
|---|---|---|
| Меняет решение | Делать первой | Планировать, искать косвенный способ проверки |
| Не меняет решение | Делать по остаточному принципу | Отбросить независимо от интереса к теме |
Пример: гипотеза о том, что поле жизнеспособных продолжений сводимо к графу состояний, меняет архитектуру компонента - приоритет высокий. Спор о цвете интерфейса на решение не влияет - приоритет нулевой, даже если тема приятная.
Когда останавливаться и как передавать результат во внешний контур
Условий остановки три:
- Достигнут критерий достаточности, зафиксированный на старте.
- Оставшиеся проверки уже не меняют решение.
- Ресурсы времени и людей исчерпаны.
Передача во внешний контур - это переход результата в разработку, в рабочий процесс или к другому исследователю. Передаётся не только вывод, но и его границы: что проверено, что нет, какие инварианты должны сохраняться, какие ветви закрыты и почему. Без этого списка следующая команда начнёт с нуля и повторит уже пройденные тупики.
Ограничения подхода и типичные ошибки
Метод требует дисциплины на входе и предметной экспертизы внутри. Это его главная стоимость. Нормализацию таксонов нельзя делегировать модели целиком: границы и источники задаёт человек, который отвечает за предмет. Выделение таксонов остаётся субъективным, два специалиста дадут разные наборы для одной задачи.
Ограничения по контексту применения:
- Высокая трудоёмкость на старте. Для простой задачи на один день такая подготовка обойдётся дороже самого результата.
- Проверку нельзя автоматизировать полностью. Симуляция и внешние источники помогают, финальное суждение о применимости переноса принимает человек.
- Подход хорошо работает там, где есть повторяемые измерения. Для разовых творческих задач с неясными критериями он даёт мало.
Типичные ошибки: пропуск фиксации направления, слишком общие таксоны, доверие к ответу ИИ как к доказательству, отсутствие памяти об отвергнутых ветвях, отсутствие критериев остановки. Одна честная оговорка про источники: публично раскрыт в первую очередь стартовый этап метода, а детали таксономии, проверки переноса и управления исследованием ниже собраны как рабочая реконструкция практики, а не как пересказ опубликованного текста.
Итог: как встроить «Глаз стрекозы» в свой процесс
Цепочка целиком выглядит так:
- Зафиксировать направление: объект, результат, ограничение, критерий достаточности.
- Разбить предмет на фасеты без пересечений.
- Построить таксоны с паспортом, границами, измерениями, состояниями и источниками.
- Найти области возможного межпредметного переноса по совпадению границ и измерений.
- Проверить перенос через абстракцию, инвариант, защиту от ложной аналогии и независимые линии проверки.
- Вести долг проверки и память об отвергнутых ветвях.
- Остановиться по критерию достаточности и передать результат с описанием границ.
Ответ ИИ остаётся гипотезой на всех шагах. Практическая ценность метода в том, что он заменяет бесконечный поиск идей на управляемую последовательность решений, где каждое можно проверить или отклонить. Если ваша работа связана с проектированием систем и вы уже чувствуете, что узкое место сместилось с написания кода на проектирование и проверку, эта дисциплина окажется полезнее очередного набора промптов (проектирование вместо кода в эпоху AI).