Проверяемость как бизнес-фича
Сложная система превращается в черный ящик с магией.
Черному ящику люди не доверяют.
Людей, способных разобраться в любой хитровыдуманной логике, любой системы, подхода или технологии — обычно мало. Для этого требуется немалое понимание предметной области, следом ряд каких-то инженерных навыков, подходящая модель в голове (или на бумаге) причем актуальная, и значительный запас времени + внимания.
Пользователь такой системы разбираться на экспертном уровне не будет и не намерен. Ему, в общем-то нечем, ему не до того, и задачи у него другие. Ему нужен конкретный результат по какому-то описанному flow взаимодействия. Вошла свинья, вышли сосиски, задача решена. Мозг не задет.
До тех пор, пока пользователь системе доверяет. А доверяет он тогда, результат выглядит подходящим, резонным и «правдоподобным». С точки зрения какой-то бытовой логики или уже накопленного опыта.
Людей, которые пользуются настольной ОС — миллионы. Людей, которые знают, как конкретно устроена Windows под капотом — пара сотен. Это не проблема, пока «всё работает».
Вы легко вспомните примеры, когда это условие не выполняется, и «всё идет не так». Некоторая система предлагает вам какое-то решение. Ответственность за применение предложенного будете нести вы, как пользователь — система процедурная, даже железная, и она вам в общем-то ничего не должна.
Если вам абстрактная система правил говорит, что вашу налоговую декларацию надо заполнять вот так, и вы будете должны государству $NNN денег — именно вам предстоит поверить системе, отдать тех самых денег, и (что более важно) взять на себя все риски в той связи, что вы доверяете выводам системы.
Неважно, «айтишная» это система, или просто внешний Люба-бухгалтер на аутсорсе. Или не дай бог AI.
Верить, или не верить на слово — всегда вопрос сложный.
С бурным ростом информатизации в зарубежном медиа даже (1970+) возник отдельный художественный поджанр, в жанре хоррор (ужасов) — концепция Недружественной Системы.
Есть в кино и литературе. Когда важные решения применительно к человеку принимает какая-то абстрактная, непрозрачная Система, эти бездушные решения ломают человеку жизнь, и ведут ко всяческим проблемам.
HAL не откроет вам двери воздушного шлюза станции, потому что автоматика приняла решение в свою пользу. Не в вашу.
Пугает здесь именно бездушность, непроверяемость, и отсутствие человеческой обратной связи. Потому что человека нет. Ни в лоб дать, ни отпеть. Как следствие, невозможность далее повлиять на ситуацию системными методами, придется брать в руки красную монтировку.
Непредсказуемость пугает человека. Непрозрачность пугает. Система, которая заведомо относится к категории «непознаваемое», воспринимается человеческим актором как враждебная среда. С ворохом рисков и без понятности; без понятности не будет доверия. А без доверия, как мы немного выясняли ранее, вообще мало что работает с positive outcome.
Примеров я по этой части потом еще накидаю: есть интересные (по крайней мере мне), но пока оффтоп.
В этой проблематике есть, где покопаться — в смысле улучшений, и получения рыночных преимуществ.
Если решения именно вашей системы можно наглядно показать, прочитать, проверить, и проанализировать с точки зрения наблюдаемости — это жирный плюс и преимущество; в сравнении с теми аналогами, где такой возможности не представлено.
И это не просто фича — это бизнес-фича. Она продается. Она стоит денег, которых готовы за нее доплатить.
Самый простой хрестоматийный пример — это логи. Подробный отчет об операциях, действиях, принятых решениях и развилках, который доступен для анализа тогда, когда возникли вопросы.
Анализ операций — по отношению к самой системе это мета-задача, в смысле внешняя. Причем разная.
- нам надо понять, что могло пойти не так.
- нам надо понять, почему принято то или иное решение (даже формально верное)
- нам надо понять, какие критерии и факторы имели влияние в данном конкретном случае, и правильно ли они были выбраны, согласно внешней (бизнесовой) модели
- нам надо понять, корректно ли была поставлена входящая задача; инструмент отработал правильно, но по результату есть предположение, что нужен был совсем не он
- нам нужно найти узкие места, или оценить возможности количественно
- нам нужно получить отчет для внешнего аудита, если по решению вот счас триггернут какие-то риски (и нам будет больно)
- и так далее
Что для нас (как проектировщиков) здесь хорошо: что эта задача в принципе технологически решаемая, и достаточно несложная, хотя и развесистая. Надо сделать из черного ящика как минимум «серый»: вытащить логику наружу, повысить verbosity, поднять наблюдаемость, получить проверяемость.
И эта задача «наблюдаемости» тиражируемая, а тиражируемые продукты в информационной среде — это всегда хорошо, правильно и успешно продавабельно.
Если мы можем понять и разрулить отдельный взятый кейс, значит мы можем понять и разрулить любой кейс и поведение системы аналогичного характера, сейчас и далее. Это уже худо-бедно инструмент.
Знаю конкретный пример отраслевой, из мира 1С, когда люди взяли типовой расчет по логистике, закупкам и магистрали — корректный расчет, повсеместно распространенный — и сделали бизнес-продукт тупо на основе того, что дали к нему подробный проверяемый отчет в моменте: как проходил обсчет модели. Чем он руководствовался, какие входные параметры во что превратились, как и чем оценивались, и что в итоге получилось.
Поднялись миллионов на 5 зелени. Само решение и решалку, что важно, не трогали вовсе. Её и нельзя трогать, она типовая и обложена требованиями.
Выигрыш бизнесовый чисто за счет отчетинга, наблюдаемости, и серого ящика, вместо «черного» который идет из коробки.
И это не сложно технически. Всего-то делов: пойти в корректный детерминированный работающий продукт, уже написанный, и вытащить из него зашитую логику обратно, на человеческий уровень. Где ее можно прочитать и проанализировать.
Что еще здесь важно, и почему мы говорим об отдельной фиче.
Проверить «руками» любой кейс — задача всегда решаемая. Просто муторно и долго. Из примера с бухгалтерией выше: окей, ты не доверяешь бухгалтеру, значит ты можешь засесть на 2 дня в документы, сам выполнить все необходимые операции, и сверить ответы, соотнести желаемое с действительным.
Бизнес-фичой становится сама возможность быстро и просто проверить любое решение. Без необходимости перетыкаться в ручной режим и что-то там изучать и переповторять, за свой счет в свободное время.
Заявленная возможность «сомневаешься? ну вот ткни и проверь!» становится отдельной фичой, имбой и киллер фичей — если ее до этого почему-то не было.
Естественно, проверять 100% решений никто не будет; система для того и вводилась, чтобы не делать это руками, и поручить работу автоматике. Но возможность проверить хотя бы 1% кейсов «просто потому что захотелось», и точно проверить еще 1% кейсов, которые нам почему-то не понравились — мощнейший буст, прокачка доступных возможностей и как следствие, бизнес-преимущество. Ну и да, отдельный ценный контур контроля.
Следует всегда помнить, что ваши системы и спроектированные процессы — обычно часть чего-то большего. Других процессов, над-систем, бизнесовых связок. Где тоже есть свои потребности в наблюдаемости, проверяемости, дебаге в смысле отладки происходящего, и потребности в получении аргументированных ответов в тот момент, когда они нужны. Вопросики-то могут возникнуть не к вам и не к вашей системе, а комплексно, «где-то там выше». И для получения ответов надо будет обращаться к вам. Искать концы, решать проблемы. А вы молодец, и предусмотрели инструментикъ.
Пространство вариантов
За процессами и гипотезами почти всегда лежит модель. Модель, детерминированная либо статистическая, имеет варианты своего описанного поведения, и некое пространство вариантов. В нашем, произвольно выбранном кейсе, по модели мы делаем какие-то вот такие, конкретные выводы.
К применяемой модели, допустим, вопросов нет. А к кейсу и к ситуации, в которой мы модельку применяем — вопросы есть.
Далее нам надо не просто получить ответ (от модели и от гипотезы на вопрос) «почему оно всё вот так».
Нам надо получить ответ следом на другой, более важный вопрос:
— «а как теперь сделать так, чтобы было иначе?»
Поскольку вы добавили наблюдаемость к модели, можно на глаз прикинуть граничные точки и критерии балансировки. Из бухгалтерского примера выше: вот модель говорит, что я должен вот столько денег. Ну, окей.
А что мне предстоит делать, если я хочу иначе? Что мне следует поменять? Что влияет на полученный из модели ответ? Какие есть рамки, допущения, коридоры значений?
Поскольку это вопрос все еще к вашей модели, и всё еще вопрос технический — можно и его решить. Это хорошо, это круто, это полезно; и да, это продаётся.
Лично я в свое время поднял себе денег на конфетки, когда вывод модели (несложной, финансовой) кроме ответов обзавелся графиком вариантов, и парой линий тренда. Задача на уровне «пара часов в экселе» превратилась в инструмент вида «вот твои идеальные параметры и доступные возможности на месяц вперед».
Как оказалось, никто такого почему-то не делал, и кто я такой, чтобы отказываться от денег, которыми в меня пришли тыкать.
Это другой уровень ответов и возможностей по, казалось бы, той же математике. Вместо «ответы = 60» на выходе сразу отрастает наглядность, коридор вариантов, а следом еще и небольшое прогнозирование. За аргументированное прогнозирование рынок готов дать денег почти всегда.
Как печенька с предсказаниями, ну. Занимательно и вкусно.
Эту статейку побудило наконец выложить вот какое интересное для меня событие и наблюдение.
Есть предметная сфера, в которой исторически некоторый бардак, хер пойми что происходит. Устроена по модели биддинга: с одной стороны есть предложения, с другой оценка спроса. Принятие решений с обоих сторон непрозрачное, рынок балансируется по спросу-предложению. Есть статистика.
Казалось бы, здесь проверяемость и наблюдаемость решает.
С другой стороны очевидно, что на стыке спроса-предложения проверяемость отверткой не прикрутишь: с обоих сторон рынка у нас черный ящик, есть только балансировка стакана.
Сфера в данном случае не важна, схема весьма распространенная.
И что ребята сделали: на этапе биддинга привернули AI, задача которого по известным критериям оценить матчинг. То есть, LLM берет и сопоставляет предложения (оффера) с обоих сторон, и по ряду своих, описанных для неё концепций и подходов пытается развернуть представленные с обоих сторон ситуации критерии.
Вот здесь совпало. Вот здесь чего-то не хватает. Вот здесь количественно слабый критерий. Вот здесь несовпадение ожиданий. Вот здесь статистическая аномалия относительно соседних вариантов.
Важно: модель не дает гарантированных ответов, потому что их нельзя напрямую посмотреть и просчитать детерминировано. Модель дает статистически вероятные ответы, руководствуясь своей логикой, которая зашита в нее саму — и вот эту логику как раз уже можно посмотреть и оценить.
На одном кейсе есть допущения (и будут допущения, мы можем только предполагать ответ). На статистической выборке модель оценки сходится с моделью матчинга — налицо eventual consistency.
Процент ошибки менее критичен, чем отсутствие ответов вовсе.
Ну и технически удобно, потому что тебе не надо гонять свою модель по всему рынку, и жечь ведро денег. Тебе надо прогнать оценку только на заданном наборе кейсов, которые чем-то показались интересными (или потенциально выгодными, для одной из сторон). Например, найти недооцененные предложения. Или оптимизировать свои оффера, относительно потребностей или заявленных требований другой стороны стакана предложений.
Ответы такой оценочной системы используются не в ней самой (ей пофиг), а в вышестоящей цепочке процессов — для анализа, как и в примере выше. Вот у нас есть полученная гипотеза, что идет «так», а что может «пойти не так». Где узкие места, где есть недоработка, где надо подкрутить. Как свести задачу (биддинг-матчинг) до удобной нам, или просто чуть более выгодной в моменте.
Возможность не работать вслепую там, где остальные работают вслепую — дорогого стоит.
Забавный пример из мира AI и LLM, который всегда по определению «черный ящик», получился в тот момент, когда большие языковые модели «научились» в техническую концепцию reasoning и chain of thought. Когда перед генерацией ответа программная моделька имитирует собственный же подход к генерации ответа, озвучивает контекст, и далее уже отвечает на вопрос, имея подготовленный контекст для самой себя.
Мне этот факт и пример интересен тем, что «озвучивание рассуждений» значительно помогло как самой модельке, нейро-генератору, так и пользователям и потребителям результатов.
Reasoning как явление, и созданная в нём цепочка «рассуждений» не является правдой или истиной в той же степени, в которой не является правдой (корректным ответом) или истиной (формальным знанием) итоговый ответ модели.
Но по факту оказалось на тестах, что: если предварительно добавить генератору в рабочий контекст добавочное знание, связанные смыслом и областью знаний токены, и предположить «для самого себя» ход будущего решения задачи, то и решение задачи статистически имеет меньше ошибок. Значительно меньше.
А для пользователя такая наглядность и проверяемость дает мета-знание; возможность проанализировать не ответ модели, а собственную постановку входящей задачи для модели, в этой связи. Начать ставить более правильные вопросы, добавить недостающие знания (вместо абстрактных предположений), и скорректировать сам процесс «решения», в смысле генерации ответа.
То есть, подсветить причинно-следственные связи, и проследить наблюдаемую «логику, идентичную натуральной».