Knowledge Problem

Ева руководит ремонтной мастерской и получает неожиданный заказ. В перечне есть оборудование, но коллега знает больше: подходящий станок только что освободился, а нужная оснастка есть в соседней мастерской. Именно такое знание конкретного места и момента подчёркивает Хайек. Техническое руководство важно, но само не скажет, что удастся организовать сегодня после обеда. Профессиональные знания и опыт здесь не соперники: при принятии решения часто приходится опираться на то и на другое. [1]

Хайек приводит пример олова: новый спрос или перебои с поставками могут поднять цену. Покупатели ищут способы экономии или замену, даже не зная исходной причины. Цены могут связывать решения далёких людей без общего отчёта для всех. Но цена не рассказывает всю историю, а реакция не обязательно идеальна. Economic Calculation, сравнение затрат и планов через денежные цены, использует этот сигнал, но не превращает его в полное знание. [1]

В отчёте указано несколько подходящих станков в регионе. Один далеко, другой ожидает ремонта, ещё один освободится только на следующей неделе. Сумма не обязательно ошибочна — она просто не отвечает на вопрос Евы, как закончить сегодня. При объединении данных в категории часть различий исчезает. Обзор помогает сориентироваться, но нужно проверить, не меняют ли место, состояние или срок реально доступные варианты. [1]

В Economics and Knowledge Хайек отличает совместимость планов от объяснения того, как она возникла. Ева ожидает деталь, а поставщик — что она её примет. Допустить, что оба всё правильно знают, ещё не значит объяснить их согласованность. В нашем примере нужно рассмотреть подтверждение заказа, изменённый срок или сообщение о задержке и то, скорректировали ли люди свои планы. Модель с полной информацией может быть полезна, но реальный процесс обучения всё равно требует объяснения. [2]

Программа показывает Еве деталь на складе. Но запись могла появиться до того, как другой клиент купил эту деталь, или относиться к иной версии. Применительно к базе данных вопрос Хайека становится вполне практическим: откуда взялась информация, когда её обновили и что именно она описывает? Более быстрое ПО лучше обрабатывает введённые данные, но тем самым не подтверждает их полноту или пригодность. Речь не об отказе от баз данных, а о различии между записью и знанием, необходимым для конкретного решения. [1] [3]

Механик может отлично знать станок, но не знать о подорожании детали или транспортных проблемах поставщика. Децентрализация, распределение решений между участниками, требует и связей между ними. Поэтому Хайек соединяет местное знание с другими сигналами, прежде всего ценами. Ева не становится безошибочной лишь потому, что находится ближе всех к заказу. Ей нужны возможности проверять информацию, менять план и учиться на неудачах. [1] [2]

Мастерская легко подсчитает заказы, но труднее отразит утраченное доверие клиента или опыт сотрудника с необычной поломкой. В The Pretence of Knowledge Хайек предостерегает от представления, что важно только то, для чего есть числа. Точная таблица ещё не оправдывает точный прогноз. Полезно разделять наблюдения, предположения и неизвестное. Измерение не теряет ценности; нужно признавать его границы. [3]

Ева может принять Bitcoin и проверить платёж по правилам сети. Например, она может проверить, включена ли транзакция в блок — группу транзакций, принятую по правилам сети. Это не скажет ей, приедет ли деталь и будет ли клиент доволен ремонтом. Проверяемая запись платежа и знание рынка выполняют разные задачи. Распределённая сеть не гарантирует полноты деловой информации или безошибочных решений. Даже при оплате биткоином Еве нужны звонок поставщику, опыт механика и возможность изменить план. [1] [2] [4]