Knowledge Problem

Ева керує ремонтною майстернею й отримує несподіване замовлення. У списку є обладнання, але колега знає більше: потрібний верстат щойно звільнився, а сусідня майстерня має необхідне оснащення. Саме такі знання конкретного місця й моменту підкреслює Гаєк. Технічна інструкція важлива, проте сама не підкаже, що можна організувати сьогодні після обіду. Фахові знання та досвід тут не суперники: для рішення часто потрібні обидва. [1]

Гаєк наводить приклад олова: новий попит або перебої з постачанням можуть підняти ціну. Покупці тоді шукають способи економії чи заміну, навіть не знаючи початкової причини. Ціни можуть поєднувати рішення далеких людей без спільного звіту для всіх. Проте ціна не розповідає всієї історії, а реакція не обов’язково досконала. Economic Calculation, порівняння витрат і планів через грошові ціни, використовує цей сигнал, але не перетворює його на повне знання. [1]

Звіт показує кілька придатних верстатів у регіоні. Один далеко, інший чекає ремонту, ще один буде доступний лише наступного тижня. Сума не обов’язково хибна — вона просто не відповідає на Евине питання, як завершити роботу сьогодні. Об’єднання даних у категорії прибирає певні відмінності. Огляд допомагає зорієнтуватися, але слід перевірити, чи місце, стан або строк не змінюють реально доступних варіантів. [1]

У Economics and Knowledge Гаєк відрізняє сумісність планів від пояснення її виникнення. Ева очікує деталь, а постачальник — що вона її прийме. Припустити, що обоє все правильно знають, ще не означає пояснити їхню координацію. У нашому прикладі треба дослідити підтвердження замовлення, новий строк або повідомлення про затримку й те, чи скоригували люди свої плани. Модель із повною інформацією може бути корисною, але справжній процес навчання все одно потребує пояснення. [2]

Програма показує Еві деталь на складі. Але запис міг з’явитися до того, як інший клієнт купив цю деталь, або стосуватися іншої версії. Для бази даних питання Гаєка набуває цілком практичного змісту: звідки взялася інформація, коли її оновили й що саме вона описує? Швидше програмне забезпечення краще обробляє введені дані, але цим не підтверджує їхню повноту чи придатність. Йдеться не про відмову від баз даних, а про різницю між записом і знанням, потрібним для конкретного рішення. [1] [3]

Механік добре знає верстат, але може не знати про подорожчання деталі чи транспортні проблеми постачальника. Децентралізація, розподіл рішень між учасниками, потребує також зв’язків між ними. Тому Гаєк поєднує місцеві знання з іншими сигналами, насамперед цінами. Ева не стає безпомилковою лише тому, що найближча до замовлення. Їй потрібні можливості перевіряти інформацію, змінювати план і вчитися на невдачах. [1] [2]

Майстерня легко порахує замовлення, але складніше зафіксує втрату довіри клієнта чи досвід працівника з незвичною несправністю. У The Pretence of Knowledge Гаєк застерігає від уявлення, що важливе лише те, для чого є числа. Точна таблиця ще не обґрунтовує точного прогнозу. Варто розрізняти спостереження, припущення й невідоме. Вимірювання не втрачає цінності; його межі потрібно визнавати. [3]

Ева може прийняти Bitcoin і перевірити платіж за правилами мережі. Наприклад, вона може перевірити, чи включено транзакцію до блока — групи транзакцій, прийнятої за правилами мережі. Це не повідомить їй, чи приїде деталь і чи буде клієнт задоволений ремонтом. Запис платежу, який можна перевірити, та знання ринку виконують різні завдання. Розподілена мережа не гарантує повноти ділової інформації або безпомилкових рішень. Навіть за оплати біткоїном Еві потрібні дзвінок постачальникові, досвід механіка та можливість змінити план. [1] [2] [4]