У Алексея Толстого в «Золотом ключике, или Приключениях Буратино» есть сцена, которая неожиданно хорошо описывает значительную часть того, что сегодня происходит вокруг больших языковых моделей.
В каморке папы Карло висит старый холст с нарисованным очагом. Огонь выглядит убедительно, котёл на месте, сама картинка создаёт ощущение домашнего тепла и порядка. На такой очаг можно смотреть и почти верить, что перед тобой настоящая печь.
Потом появляется Буратино, протыкает холст своим длинным носом — и обнаруживается, что очаг существует только на поверхности. За ним находится совсем другая реальность, а где-то дальше скрыта маленькая дверь, которую ещё предстоит открыть золотым ключиком.
Мне кажется, мы сейчас примерно в такой точке отношений с LLM.
Большая языковая модель за несколько минут способна сделать то, на что раньше уходили дни работы аналитиков, архитекторов и дизайнеров. Она нарисует архитектуру предприятия, бизнес-процесс, карту функций, модель управления, структуру исследования, концепцию продукта, требования к ERP, презентацию руководству. Всё получится аккуратно, современно и настолько убедительно, что заказчик совершенно естественно может посмотреть на результат и сказать: «Вот оно. Наконец-то всё стало понятно».
Но в серьёзной аналитике после первого впечатления должен прозвучать другой вопрос: что находится за этим холстом?
На этой неделе я снова увидел такой холст
Повод написать эту статью оказался очень практическим. На этой неделе мне снова попалась очень красивая проектная схема. Сделана она была действительно хорошо: аккуратная композиция, понятные блоки, логичные стрелки, современные формулировки. Заказчик был потрясён и, образно говоря, хлопал в ладоши, потому что человеку, который не занимается подобными моделями каждый день, такая картинка почти неизбежно создаёт ощущение большой законченной интеллектуальной работы.
Я смотрел на неё иначе. Не потому, что схема была плохо нарисована, и не потому, что я имею что-то против красивых представлений. Наоборот, сложная модель должна иметь хорошее человекочитаемое представление. Проблема состояла в том, что я довольно быстро увидел: за этой схемой нет предметной конструкции, которая объясняла бы, почему именно эти объекты существуют, что они означают и почему между ними проведены именно такие связи.
И вот здесь начинается настоящая проблема заказчика. Он покупает нечто, внешне похожее на проектную модель, но пока не умеет различать две совершенно разные вещи: перед ним настоящая печь или только великолепно нарисованный очаг на старом холсте.
С распространением LLM таких холстов станет очень много. Стоимость производства впечатляющего текста, схемы или презентации упала в десятки раз, а возможность заказчика проверить, что находится под красивой поверхностью, сама собой не выросла.
Именно поэтому эта статья — не критика искусственного интеллекта. Это предупреждение аналитику и заказчику: учитесь смотреть за холст.
Я не про картинки с котиками
Сразу обозначу границу. Если человек использует генеративную модель, чтобы нарисовать открытку, придумать рекламный образ, стилизовать фотографию или сделать ролик, никакой большой предметной онтологии ему, скорее всего, не требуется. В таких задачах способность модели фантазировать является частью результата.
Я говорю об аналитике, исследованиях, ERP, архитектуре предприятия, инженерии, праве, проектировании сложных систем и управлении. Там результат должен быть не только убедительным, но ещё объяснимым, непротиворечивым и проверяемым.
Большая языковая модель чрезвычайно хорошо строит вероятностно правдоподобные конструкции. Но вероятностное правдоподобие и предметная корректность — не одно и то же. Если модель не знает, какие предметы действительно существуют внутри рассматриваемой области, какими признаками они определяются, в каких состояниях могут находиться, какие события эти состояния изменяют и какие отношения между предметами разрешены, она вынуждена достраивать недостающую структуру.
Иногда она делает это удачно. Иногда — очень красиво и совершенно неправильно.
Самая опасная кнопка сегодня — «нарисуй мне»
Возьмём склад. Попросим LLM: «Нарисуй архитектуру управления складом промышленного предприятия». Через минуту появятся ERP, WMS, ТСД, приёмка, размещение, отбор, упаковка, отгрузка, контроль качества, зоны хранения и несколько аккуратных потоков между ними.
На таком уровне всё выглядит прекрасно, пока мы не начинаем задавать предметные вопросы. Начинаем со слова «остаток», которое кажется совершенно очевидным, а затем постепенно появляется цепочка различений:
остаток → доступный остаток → зарезервированный остаток → заблокированный остаток → партия → грузовая единица → место хранения → качество → потребность → обеспеченность.
Это не процесс и не последовательность хозяйственных операций. Это последовательность различений, которые вынужден сделать аналитик. Вначале ему казалось, что одного слова «остаток» достаточно, а затем выяснилось, что под ним прячутся разные предметы, состояния и отношения, которые нельзя безнаказанно сложить в один прямоугольник на диаграмме.
Теперь можно задавать содержательные вопросы. Может ли одна партия находиться одновременно в нескольких грузовых единицах? Может ли одна грузовая единица содержать несколько партий? Что означает утверждение «остаток есть»: он физически присутствует, зарегистрирован в ERP, доступен для использования или прошёл контроль качества? Если материал существует физически, но заблокирован, относится ли он к тому же управленческому состоянию, что доступный запас?
Именно отсюда начинается аналитика.
Нарисовать склад значительно проще, чем определить, что именно в нём существует.
И пока это не сделано, стрелки на картинке остаются только стрелками.
Картинку можно нарисовать. Печь нужно построить
Метафору с очагом здесь можно продолжить буквально. Нарисованный очаг не становится настоящей печью потому, что художник лучше прорисовал огонь. Настоящая печь появляется тогда, когда кто-то взял кирпичи, определённым образом связал их, сделал топку, дымоход, установил ограничения конструкции — и в результате получил вещь, которая действительно способна работать.
В предметном моделировании такими кирпичами становятся:
предмет → таксон → признак → состояние → событие → связь → ограничение → источник → доказательство.
После этого уже можно рисовать какую угодно красивую проекцию. Более того, я считаю, что её обязательно надо рисовать: человеку незачем читать машинный граф из тысяч связей. Но картинка должна быть представлением построенной конструкции, а не заменять её.
Сначала предмет, потом схема
В своей работе я придерживаюсь довольно простого порядка. Сначала определяется предметная область, затем внутри неё выделяются предметы, после этого их признаки, состояния и события, а затем устанавливаются связи между предметами и правила, которые делают эти связи допустимыми или недопустимыми. Только после этого имеет смысл строить процессы, документы, объекты ERP и человекочитаемые представления.
В лекции, которую я проводил накануне для своих коллег, я разбирал эту логику на совершенно бытовом примере с бусиной. Есть предмет, есть его признаки и возможные классификации; совокупность устойчивых признаков позволяет формировать таксон, после чего появляются состояния, отношения и уже затем машинное описание предметной области.
Я называю возникающую при этом конструкцию доказательной опорой. Модель должна не просто предполагать, что между двумя предметами «обычно существует какая-то связь», а иметь основание считать эту связь допустимой именно внутри исследуемой области.
В этот момент LLM начинает работать совсем иначе. Она перестаёт каждый раз заново угадывать мир и получает определённое пространство, внутри которого можно рассуждать.
А теперь неприятная часть — философия
На этом месте часть технических специалистов обычно начинает скучать, потому что слово «философия» до сих пор многими воспринимается как воспоминание о дисциплине, которую когда-то нужно было сдать в институте и больше никогда не открывать.
Однако как только человек начинает серьёзно заниматься предметными моделями, онтологиями, knowledge graph и использованием LLM для сложной аналитики, выясняется неприятная вещь: большая часть фундаментальных вопросов, с которыми мы столкнулись сегодня, была поставлена человечеством задолго до появления компьютеров.
Что является предметом? Что нам действительно дано, а что мы сами построили как понятие? Чем предмет отличается от его признака? Где сущность, а где её проявление? Какая связь существенна, а какая случайна? Что произойдёт с нашим определением, если обнаружится новое отношение?
Это не вопросы prompt engineering. Это вопросы мышления.
Кант: не путать то, что дано, с тем, как мы это мыслим
Иммануил Кант здесь неожиданно оказывается очень прикладным автором. Для целей аналитика особенно важно различение между чувственностью, через которую предмет нам даётся, и рассудком, посредством понятий позволяющим этот предмет мыслить. У Канта знание требует совместной работы чувственности и рассудка: одних понятий без соответствующего содержания недостаточно точно так же, как восприятия без понятий недостаточно для осмысленного знания.
Для ERP-аналитика это совершенно практическая проблема. Пользователь говорит: «У нас есть заказ». Но что именно нам сейчас дано? Хозяйственное обязательство, запись в информационной системе, документ с названием «Заказ клиента», устное представление пользователя или наше аналитическое понятие заказа как самостоятельного бизнес-предмета?
Если аналитик сам этого не различает, LLM легко склеит разные уровни в одну гладкую конструкцию, после чего нарисует ещё более гладкую схему.
Первый золотой ключик — не путать предмет с его представлением.
В своей книге, в третьем томе серии «Моя ERP для аналитика» — «ERP-проект. Как делать.», я формулирую ту же проблему уже проектным языком. Технический объект системы не является источником бизнес-смысла: сначала необходимо понять, какой факт существует в деятельности, что он означает и почему нужен предприятию, и только затем решать, каким объектом ERP этот смысл представлять.
Гегель: определение не существует в одиночестве
С Гегелем ситуация ещё интереснее. Для аналитика здесь полезна не популярная школьная формула про «тезис — антитезис — синтез», а сама необходимость рассматривать определения в системе отношений и переходов. В «Науке логики» движение от бытия к сущности и понятию включает, в частности, различение сущности и явления: видимая поверхность получает смысл через более глубокую систему отношений, которая её объясняет.
И это очень похоже на реальную работу аналитика. Начинаем со знакомого слова «остаток», а дальше возникают доступный остаток → резерв → блокировка → партия → грузовая единица → место хранения → качество → потребность. Первоначальное определение перестаёт удерживать всё, что мы обнаружили, и модель приходится перестраивать.
Вот это и есть настоящая аналитическая работа. Не добавить ещё один прямоугольник, а понять, почему старого определения уже недостаточно.
Философия здесь нужна не для украшения статьи именами великих мыслителей. Она тренирует способность различать.
Аристотель тоже никуда не делся
Есть ещё более старый фундамент: если мы хотим определить предмет, полезно сначала понять, к какому более общему классу он относится и каким существенным различием отделяется от соседних предметов.
Если написать: «Среда тестирования — это место, где проводится тестирование», мы практически ничего не определили. Горная долина тоже место, сервер существует совсем в другом смысле, а тестовый стенд и тестовая информационная база могут вообще принадлежать разным классам объектов.
Сначала нужно понять, что за сущность перед нами, каковы её существенные признаки и где проходит граница с соседними понятиями.
Если аналитик не умеет определить предмет, он ещё не готов рисовать его связи.
Почему одного RAG недостаточно
На этом этапе часто возникает возражение: хорошо, положим нормативы, документы и интервью в RAG, и тогда модель будет отвечать только на основании наших материалов.
Это полезно, но проблему полностью не решает. RAG хорошо помогает обнаружить релевантный фрагмент корпуса, но сам по себе ещё не устанавливает, какое место найденный материал занимает в предметной модели.
Регламент говорит одно. Интервью показывает другое. Действующая ERP реализует третье. Все три материала могут быть найдены совершенно корректно.
Но что является нормой? Что фактической практикой? Что исторической реализацией? Что исключением? Что ошибкой? Что целевым решением? Это уже не retrieval. Это модель предметов, отношений и доказательств.
В книге «ERP-проект. Как делать.» я отдельно провожу эту границу: транскрипция не заменяет исходную запись, извлечённый текст не заменяет исходный документ, а аналитическая выжимка не превращается в новое первичное свидетельство только потому, что написана удобнее. Производное представление должно сохранять путь к исходному основанию.
Что такое граф знаний на практике
Knowledge graph тоже успел стать модным словосочетанием, поэтому вокруг него уже создано огромное количество собственных красивых холстов.
Граф знаний вовсе не обязан быть гигантской разноцветной сетью из десяти тысяч кружочков. Он может храниться в графовой базе, таблицах, JSON или даже Excel. Формат вторичен.
Главное состоит в том, что знания перестают существовать исключительно в форме абзацев. Мы можем машинно выразить достаточно длинную причинную конструкцию:
предмет A → класс B → признаки C → состояние D → событие E → состояние F → допустимое условие X → роль R → источник S → версия V.
Теперь LLM работает не просто с вероятностно похожими словами, а с пространством предметно допустимого. Без него модель отвечает: «Обычно это устроено примерно так».
С ним она способна сказать: «В принятой модели этот предмет определён так, находится в таком состоянии, переход допускается при таких условиях, а утверждение подтверждается таким основанием». Это разные уровни инженерного доверия.
Сначала граф, потом человекочитаемое представление
Мы исторически привыкли строить проекты документами. Сначала появляется отчёт обследования, потом BPMN, затем Excel требований, техническое задание, архитектурная презентация и пользовательская инструкция. Каждый следующий специалист читает предыдущий документ и пытается восстановить из него смысл.
В результате человекочитаемое представление постепенно становится источником истины. Это перевёрнутый порядок.
В книге «ERP-проект. Как делать.» я формулирую эту проблему прямо: рабочая модель проекта и документ, который видит заказчик, не обязаны быть одним объектом. В рабочей модели существуют связи, версии, источники, состояния и зависимости. Человекочитаемый документ нужен для обсуждения и принятия решения, но существенное изменение должно сначала возвращаться в тот слой модели, которому оно принадлежит, и только после этого порождать новую проекцию.
Сначала модель → потом схема. Сначала граф → потом отчёт. Сначала предмет → потом картинка.
Но есть ещё более важное различие: модель можно проверить
Здесь мы подходим к тому, что, на мой взгляд, окончательно отделяет настоящий инженерный результат от красивого холста.
Настоящая модель проверяема.
Если я утверждаю, что определённый предмет существует, я должен показать его определение и основание. Если утверждаю, что он может находиться в определённом состоянии, должна существовать модель состояния. Если показываю переход, я обязан объяснить событие, условия, полномочия и ожидаемый результат. Если утверждаю, что определённый процесс поддерживается ERP, должен существовать воспроизводимый сценарий, в котором можно проверить это утверждение.
Красивую картинку проверить значительно сложнее, потому что зачастую в ней не определено, что именно должно считаться истинным или ложным. Стрелка нарисована — хорошо. Но каким наблюдаемым фактом можно доказать, что она правильная? Прямоугольники связаны — замечательно. А какое состояние должно существовать до перехода и какое после него? Где критерий, при котором мы признаем модель неверной?
Вот это принципиальная граница. Холст предлагает нам поверить. Модель предлагает нам проверить. И чем серьёзнее проект, тем меньше меня интересует убедительность картинки сама по себе и тем больше — технология её опровержения или подтверждения.
Проверяемость превращает модель в инженерный объект
Представим, что на схеме написано: «Заказ клиента → обеспечение → отгрузка → расчёты». Можно посмотреть на эту цепочку и сказать: логично.
Но инженерная модель потребует другого. Возьмём конкретный заказ. Зафиксируем исходное состояние. Проведём его через определённый механизм обеспечения. Создадим именно по этому заказу фактическую отгрузку. Продолжим расчёты именно по созданной реализации. После каждого шага зафиксируем идентичность объекта, состояние и ожидаемый результат.
Если система действительно провела тот же самый фактический предмет через всю цепочку, у нас появляется доказательство.
Если на каждом шаге было создано что-то красивое и зелёное, но реализация относится к другому заказу, а платёж — вообще к третьему примеру, то никакой сквозной модели мы не подтвердили. И вот здесь становится особенно хорошо видно, насколько опасна привычка судить по внешней форме. Зелёная картинка тоже может оказаться холстом.
Именно об этом я пишу в «ERP-проект. Как делать.»
Здесь мне придётся ещё раз сослаться на собственную книгу — просто потому, что в рамках статьи невозможно нормально развернуть всю технологию проверки.
В третьем томе серии «Моя ERP для аналитика» — «ERP-проект. Как делать.» отдельные главы посвящены как раз переходу от модели к проверяемому сценарию и затем к фактическому доказательству. В книге проводится очень важная граница: проверяемый сценарий ещё не является доказательством фактической работы системы. Он только говорит, как результат можно проверить. Право сказать «проверено» появляется после реального исполнения в определённой среде, на определённых данных и с сохранением доказательств результата.
Там же разобрана цифровая непрерывность: следующий объект должен фактически продолжать предыдущий, а не просто выглядеть похожим. Разобраны среда исполнения, тестовые данные, ручная и автоматизированная проверка, доказательства, локализация дефекта и повторная проверка затронутого объёма. В текущей редакции эта книга занимает около пятидесяти страниц, поэтому я специально старался не растекаться мыслью по древу и ценить время коллег.
Поэтому, коллеги, если вам показывают очень красивый холст, не верьте на слово и не спорьте на уровне вкуса. Просто попробуйте его проверить. Очень быстро станет понятно, существует ли под картинкой модель.
Где здесь сама LLM
Такой подход вовсе не означает, что я предлагаю сначала несколько лет вручную строить онтологию, а потом наконец разрешить аналитикам открыть ChatGPT. Совсем наоборот.
LLM великолепно работает именно на предметном исследовании. Ей можно поручать поиск кандидатов в предметы, сопоставление определений, извлечение признаков, обнаружение состояний, сбор отношений, сравнение источников, выявление противоречий, подготовку гипотез и поиск пробелов в текущем знании.
Она способна выполнить объём предварительной интеллектуальной работы, который человек вручную не сможет сделать за разумное время. Но остаётся принципиальная граница: LLM помогает строить дверь, но не должна сама объявлять, что дверь уже построена.
В лекции, которую я проводил накануне для коллег, я называю такую конструкцию доказательной опорой. Предметы и связи не должны существовать исключительно потому, что языковой модели такое продолжение показалось наиболее вероятным. Существенное положение должно иметь предметное и доказательное основание.
Что делать аналитику на практике
Подробно этот маршрут я сейчас последовательно раскладываю в трёх книгах серии «Моя ERP для аналитика», которые находятся у издателя:
-
«Мы теряем контроль над сложной 1С:ERP. Что делать?» — о том, почему работающая система постепенно становится всё менее объяснимой и как предприятие теряет происхождение собственных решений.
-
«ERP-лабиринты» — о предметных областях, бизнес-предметах, состояниях, отношениях и процессах, которые находятся за привычными документами и экранами ERP.
-
«ERP-проект. Как делать.» — о том, как провести эту конструкцию через реальный проект: источники → обследование → предметная и операционная модель → экономический смысл → данные → прикладная реализация → сценарий → проверка → доказательство. Общая логика и место третьего тома относительно первых двух прямо зафиксированы в его введении.
Если кому-то эти книги нужны именно для работы, напишите мне лично — я отправлю их бесплатно. Здесь нет никакой рекламной механики. Просто в статье невозможно изложить весь маршрут так, чтобы она не превратилась в небольшую монографию.
«Нейросетка написала»
Есть ещё один очень показательный симптом нынешнего периода. Всё чаще под текстом, схемой или исследованием появляется фраза:
«Нейросетка написала».
Мне её тоже писали.
Причём у умных, грамотных, думающих людей эта фраза уже вызывает какое-то почти подсознательное раздражение. Не потому, что они ненавидят искусственный интеллект. Многие прекрасно понимают возможности LLM и сами активно ими пользуются.
Раздражает другое.
За фразой «нейросетка написала» слишком часто чувствуется пустота: непонятно, какое исследование было проведено, какие предметы определены, откуда появились связи, на каких источниках основаны утверждения и каким образом всё это вообще можно проверить.
Человек видит красивый текст, но не видит под ним интеллектуальной конструкции.
Он ещё может не употреблять выражения «предметное ядро», «онтология» или «граф знаний», однако ощущение отсутствующего основания уже появляется.
Поэтому думаю, что эффект новизны вокруг генеративного AI у думающей профессиональной аудитории уже начинает проходить. Восхищение формой постепенно сменяется вопросом о происхождении смысла.
Нос Буратино уже упёрся в холст.
Эффект новизны закончится окончательно
Сегодня общество закономерно восхищено скоростью генерации. Мы впервые получили инструмент, который почти моментально превращает идею в текст, программу, изображение, диаграмму или презентацию. Это огромный технологический скачок, и было бы странно его недооценивать.
Но дальше начнётся взросление.
Вместо вопроса «как красиво это сделано?» будут всё чаще спрашивать: почему этот предмет существует, почему проведена именно эта связь, каким источником подтверждается утверждение, где норма, где гипотеза, какая версия действующая и каким способом можно доказать, что модель вообще соответствует реальности.
Эти вопросы очень быстро протыкают холст.
Проблема LLM не в том, что она плохо рисует картину мира. Она рисует её великолепно.
Проблема начинается тогда, когда мы забываем сначала определить, какой мир она вообще должна рисовать, а затем — как доказать, что нарисованная конструкция этому миру соответствует.
Что на самом деле покупает заказчик
Вот здесь мы возвращаемся к ситуации, с которой началась статья.
Заказчик видит две картинки. Обе выглядят профессионально. На обеих красивые блоки, стрелки, правильные современные слова и аккуратная архитектура. По внешнему виду практически невозможно определить, какая из них является проекцией большой исследованной модели, а какая возникла после трёх хороших промптов.
Разница находится снизу. Под одной картинкой — пустота. Под другой — предметы, определения, связи, источники, доказательства и возможность проверки. И именно вторую разницу невозможно оценить по качеству PowerPoint.
Поэтому заказчику теперь придётся становиться немного более требовательным. Если вам принесли впечатляющую модель, спросите не только, что на ней изображено. Попросите показать происхождение одного произвольно выбранного элемента. Почему он существует? Что означает? Каким источником подтверждён? Почему связан именно с этим объектом? Какое состояние меняется? Что произойдёт, если связь убрать? Каким сценарием это можно проверить?
Не надо проверять сразу всю систему.
Возьмите один кирпич и попробуйте вытащить его из печи.
Если за картинкой есть настоящая конструкция, вам достаточно быстро покажут соседние кирпичи и объяснят, почему без этого элемента модель изменится. Если перед вами холст, разговор обычно очень быстро возвращается к внешней убедительности самой картинки.
«Налетай, торопись, покупай живопись»
Здесь трудно не вспомнить сцену из «Операции “Ы” и других приключений Шурика»: «Налетай, торопись, покупай живопись!»
В каком-то смысле рынок сейчас подходит именно к этой стадии. Только продают уже не русалок и пейзажи. Продают стратегии, процессные архитектуры, цифровые двойники, модели предприятий, AI-концепции и дорожные карты.
И я совершенно не утверждаю, что всё это плохо. Наоборот, часть этих вещей будет великолепна. Проблема состоит только в том, что ненамётанному взгляду заказчика всё труднее отличить настоящую печь от изображения печи.
Поэтому изменится сам критерий профессионального качества. Недостаточно красиво показать. Нужно уметь объяснить. Недостаточно объяснить. Нужно показать основание. Недостаточно показать основание. Нужно дать возможность проверить.
Золотой ключик
В итоге я бы сформулировал всё очень просто.
Не запрещайте LLM рисовать. Наоборот, используйте её на полную мощность: ищите источники, извлекайте предметы, проверяйте определения, находите отношения, стройте графы, генерируйте документы и делайте красивые человекочитаемые представления.
Но соблюдайте порядок.
Сначала постройте печь. Потом нарисуйте её. Сначала определите предметный мир. Потом разрешите LLM его изображать. Сначала создайте модель. Потом потребуйте от неё доказательства. И обязательно оставьте возможность проверки.
Потому что нарисованный очаг не становится печью оттого, что пламя нарисовали ещё красивее. Печь становится печью тогда, когда она сложена из реальных кирпичей и вы можете проверить простейшую вещь — греет она или нет.
С моделями всё точно так же.
Холст просит поверить.
Инженерная модель позволяет проверить.
И если после красивой презентации остаётся сомнение, не надо спорить об эстетике и не надо верить автору на слово.
Просто проткните холст. И посмотрите, что за ним.
ссылка на оригинал статьи https://habr.com/ru/articles/1072730/