Байєс: як оновлювати впевненість після доказу
1) Звідки береться апріорна ймовірність
Що буде, якщо вона неправильна? Апріорна ймовірність (prior) — це не факт, це припущення. Якщо хтось поставить P(H) = 0.20 замість 0.05 — фінальна оцінка ризику буде зовсім іншою. Результат байєсівського оновлення сильно чутливий до вибору prior. Хто в організації вирішує, яке prior використовувати? Це не технічне питання — це управлінське рішення з великими наслідками.
2) Припущення незалежності доказів
Стаття показує, як другий сигнал піднімає ризик ще вище. Формула Байєса при послідовному оновленні мовчазно передбачає, що докази умовно незалежні. Але у реальному проєкті провалений регресійний тест і відкритий критичний дефект часто мають одну причину. Якщо трактувати їх як незалежні докази — ризик буде завищений, бо один і той самий сигнал рахується двічі.
3) Плутанина P(E|H) і P(H|E)
Грубо кажучи: «при проблемному релізі тест падає часто» не означає «якщо тест впав — реліз проблемний». Ця помилка в судженні трапляється дуже часто, коли менеджер або аудитор інтерпретує байєсівський результат без розуміння математики.
4) Проблема порогу рішення
Ризик виріс з 5% до 30%. ОК! Але що робити далі? При якому значенні блокувати реліз і хто встановлює поріг? Байєсівське оновлення дає ймовірність, але не дає рішення. Перехід від ймовірності до дії — окрема задача теорії прийняття рішень (decision theory). Можливо варто по неї написати окрему статтю.

LISP і PROLOG: дві культури раннього ШІ
1) negation as failure (Заперечення як невдача) у PROLOG
Чому це небезпечно. \+ - це не логічне заперечення.
PROLOG читає \+ verified_by(Req, _) так: «я не можу знайти жодного факту verified_by для цієї вимоги в базі» — і одразу робить висновок «прогалина в доказах».
Але в реальному проєкті відсутність факту в базі може означати три зовсім різні речі:
зв’язок «вимога — тест» справді відсутній — справжня прогалина
зв’язок є, але ще не занесений в систему — помилкова тривога
зв’язок зберігається в іншому інструменті (наприклад, Jira або DOORS) — помилкова тривога
2) closed world assumption (Припущення закритого світу)
PROLOG і класичні продукційні системи працюють за принципом: усе, що не відомо системі, є хибним. Але відсутній факт може означати «ми ще не перевірили», «дані в іншій системі» або «це неактуально».
3) scaling
Комбінаторний вибух зворотного перебору. При складних запитах і великих базах фактів дає зворотній перебір експоненційний ріст часу виконання. Саме тому промислові системи на PROLOG рідко масштабувалися за межі прототипів.
Чому саме LISP і PROLOG втратили промислову підтримку. LISP вимагав дорогого спеціалізованого апаратного забезпечення (LISP machines). Японський проєкт П’ятого покоління комп’ютерів (Fifth Generation Computer Systems, 1982-1992), побудований на PROLOG, завершився провалом після 10 років і мільярдних інвестицій. Саме ці два провали стали головними тригерами занепаду класичних експертних систем.

Велика дяка Миколе за цю статтю. Нарешті хтось написав про те, у чому я «варюся» багато років (це хобі, не робота ))). Хочу додати трошки проблематики до кожного розділу. Не сприймайте це як критику, це скоріше спроба допомогти читачам краще розібратися у питаннях.

Продукційні правила: класичне «IF-THEN»
1) knowledge acquisition bottleneck
Найбільша практична проблема — як взагалі отримати правила від експерта? Есперти часто не можуть формалізувати свої знання у вигляді чітких «IF-THEN». Кодування правил — дорогий, повільний, і часто помилковий процес. Наприклад той самий XCON потребує величезної армії інженерів знань. Було б цікаво розповісти як саме знання «виймаються» з голів експертів і формалізуються — може це варто окремої статті.
2) conflict resolution
Якщо декілька правил спрацьовують одночасно з суперечливими висновками — як визначити яке обрати?
Потрібні стратегії: пріоритет за специфічністю, за свіжістю факту, за порядком оголошення, або мета-правила як обирати правіла.
3) scaling
Той самий XCON виріс до ~10 000 правил. Додавання нового правила може зламати існуючі (ripple effect). Підтримка стає дуже дорогою. Саме це + проблема (1) призвели до занепаду класичних експертних систем.
4) monotonic reasoning
Класичні продукційні системи — монотонні. Виведений факт не відкликається, навіть якщо нові дані йому суперечать. У реальному світі знання оновлюється і система має вміти відкликати старі висновки. Немонотонне міркування (non-monotonic reasoning) і системи підтримки істинності (Truth Maintenance Systems) виникли як відповідь на цю проблему.

Згоден з автором. Хочу додати що Граф Знань має бути побудований на базі Доменної Онтології. Бо без онтології кожен буде створбвіати будь-які типи сутностей (обїектів \ субєктів) і будь-які типи зв’язків (предикатів). Такий Граф Знань теж дуже швидко перетвориться на звалку. Сопчатку — Доменна Онтологія, потім — Граф Знань на її базі. Якщо важко створити повноцінну Онтологію, то хоча б Доменний Тезаурус.

Сьогодні є тільки один більш-менш придатний підхід — гібридний квантово-класичний алгоритм на базі Quantum Annealing від D-Wave. Чисто квантові комп’ютери занадто «шумні» і нестабільні для використання в реальних задачах. Тому використовують гібридний підхід — класичний сервер керує всією логікою та даними, а квантовий чіп підключається як потужний сопроцесор всього на кілька мілісекунд, щоб вирішити один складний математичний вузол.
Quantum Annealing заточен тільки під одну задачу — комбінаторну оптимізацію (пошук найкращого варіанта з мільярдів поганих). Так, деякі компанії вже впровадили такі рішення — оптимальні логістичні маршрути, оптимальне планування виробництва, оптимальне планування графіку роботи персоналу.
Але це тільки один тип задач і алгоритм не повністю квантовий.
Про робочі алгоритми зламу шифрів або моделювання складних молекул поки що не йдеться.
Гібридний Quantum Annealing залишається єдиним зрілим інструментом для реального застосування (((

Які сектори входять в розділ «Emerging» — ніде не розкривається. В класифікаціях Світового Банку або МФВ немає такого сектору економіки. Зазвичай цей термін використовується у географічному розподілі — країни, що розвиваються або країни з перехідною економікою. Невідомо в якому сенсі ЕПАМ використовує цей термін.
Цікаво порівняти частку кожного сектора в доходах ЕПАМ з часткою цього ж сектора у світовому GDP.
Частка Financial Services у доходах ЕПАМ десь в >3,5 рази вища ніж частка цього сектора у світовому GDP.
Частка Business Information & Media у доходах ЕПАМ десь в >3 рази вища ніж частка цього сектора у світовому GDP.
З іншого боку є Manufacturing — 16%-18% світового GDP (за різними джерелами). Real Estate & Construction — десь 11%-13% світового GDP.
І ще є три сектори які разом складають >15% GDP — Education, Transportation, Telecommunication. Але в цих відносно «невеликих» секторах найбільший з усіх секторів CAGR (Compound Annual Growth Rate) ІТ-витрат. І де ці всі сектори в доходах ЕПАМ? Ховаються в «Emerging»?
Ігноруючи ці сектори економіки ЕПАМ втрачає можливості для росту (((

Цікаво було б порівняти три ціни:
1) по якій ціни викупали акції у працівників
2) ціну акції на IPO
3) ціну акції через пів року після IPO
Бо ці байбеки трошки мутна тема і зазвичай міноритарії\працівники на цьому втрачають.

я спершу подумав що

bar raising

це in the bar raising a glass разом з кандидатом ))))

Ви не розглядали можливість застосування доменної онтології або хоча б доменного тезаурусу? Тоді б не було плутанини в іменах і граф знань був би більш якісний.

Окрім Herman Miller ще Steelcase, Haworth, Okamura, Sedus, Flokk.

Романе, вдалося подолати залежність митниці від системи «Інспектор-2006»?
(dou.ua/...​/about-customs-it-system)

У всіх цих підходах ми мовчазно вважаємо, що майбутнє буде схожим на минуле. Але хіба це завжди виконується?
ІМХО, щоб більш-менш прогнозувати майбутнє, треба дивитися в бік каузальних моделей (типу Bayesian Belief Networks, тощо).

МК-54. А потім Basic, Pascal, Fortran, PL/I, dBase, FoxPro.

Якщо нове до 25к — можна подивитися на серію Ergohuman від Comfort Seating. Тестував їх — доволі зручні.
Якщо не нове — шукати на ОЛХ щось б\в від Herman Miller, Steelcase, Haworth, Ocamura або Sedus.
А ще у одного з наших клієнтів в офісі були крісла Nightingale — до 160 кг і 20 років експуатації. Але в Україні можливо їх не купиш (((

Я видаляю товари з «обраних», а вони знов там з’являються. Ще раз видаляю — вони ще раз з’являються. І так декілька разів. Це баг чи фіча? )))

Я до цих трьох складових (Моделі, Інструменти, Інструкції) додав би ще пам’ять.
Пам’ять забезпечує здатність до складних дій, що виходять за рамки одного запиту.
Короткострокова пам’ять — контекст поточного завдання.
Довгострокова пам’ять — база знань для зберігання успішних стратегій, фактів і користувацьких уподобань (щоб агент «згадував» минулий досвід і застосовував його в нових ситуаціях).

Тобто для управління акселератором оборонних стартапів зовсім непотрібно бути subject matter expert в DefTech домені?

І як 20 років досвіду в музичній індустрії можуть бути корисними в deftech?

fortran

А якщо в БД зберігається конфіденційна інформація яку неможна передавати Gemini — може краще встановити локальну LLM?