Прикладна математика експертних систем: від правил і ймовірностей до графів, причинності та рішень

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Серія статей: Експертні системи для R&D
Попередня стаття: Експертна система, доказова рекомендація ШІ і корпоративна пам’ять: три кути одного трикутника
Наступна стаття: Експертні системи: крок від математичного методу до обрання технологій

У попередніх статтях я підводив читача до головної тези: експертна система не дорівнює чатботу, а рекомендація штучного інтелекту стає корисною лише тоді, коли її можна зв’язати з джерелами, правилами, обмеженнями і відповідальністю. Тепер треба перейти від визначень до фундаменту: на якій математиці такі системи існують.

Я свідомо починаю технологічну серію статей не з бібліотек і не з мовних моделей. Бібліотеки старіють, каркаси розробки змінюють назви, нові програмні інтерфейси і моделі з’являються чи не щомісяця. А прикладна математика лишається тим шаром, який пояснює, що саме ми робимо: виводимо наслідок із правил, оцінюємо невизначеність, шукаємо схожий випадок, перевіряємо обмеження, ранжуємо докази, плануємо дії або пояснюємо рішення.

Наша мета, звісно, не засипати читача формулами — стаття навмисно полегшена, хто захоче, той знайде формули в підручниках і на тематичних сайтах. Мета інша: показати, яке питання розв’язує кожен математичний метод і коли його доречно використовувати.

Якщо прибрати модні назви, сучасна експертна система відповідає на кілька важливих питань:

• що з чого випливає;
• наскільки цьому можна довіряти;
• які знання чинні саме в цьому контексті;
• які артефакти пов’язані між собою;
• що станеться, якщо змінити один елемент;
• який варіант дії кращий за кількома критеріями;
• коли система повинна не відповідати.

Кожне з цих питань має власний математичний апарат для відповідей. Саме тому експертна система не будується на одному методі. Вона є композицією логіки, теорії ймовірностей, графів, оптимізації, теорії рішень, пошуку інформації, обмежень, причинно-наслідкового аналізу і людського перегляду.

Логіка і правила: кістяк пояснюваності

Класичний образ експертної системи починається з правил: якщо виконуються умови, зроби висновок або дію. Це не примітивна умова if у коді. У нормальній системі правило має власника, версію, область застосування, пріоритет, тестові приклади і пояснення.

Правило може виглядати так: якщо вимога має рівень безпеки, змінилася після затвердженої базової версії і не має пов’язаного аналізу впливу, релізний контроль блокується. Це не рекомендація моделі, а формальний висновок із доменних умов.

Практичне застосування: у експертній системі правило варто оформлювати як керований артефакт: умови, дія, власник, версія, область чинності, пріоритет і набір тестових прикладів. Тоді релізний блокер, перевірка повноти доказового пакета, політика доступу або аудит контрольної точки стають не прихованою умовою в коді, а пояснюваним висновком: яке правило спрацювало, на яких фактах, з яким наслідком і хто має право його змінити.

Тут важливо розрізняти два способи міркування.

Пряме виведення (forward chaining) йде від фактів до висновків. У систему приходять факти: тест впав, дефект критичний, вимога пов’язана з релізом. Рушій правил поступово виводить нові факти: реліз ризикований, потрібне погодження, контрольна точка заблокована.

Зворотне виведення (backward chaining) йде від питання назад до потрібних доказів. Користувач питає: чи можна випускати реліз? Система розкладає це питання на підпитання: чи всі критичні тести пройшли, чи всі ризики погоджені, чи немає незакритих дефектів, чи є докази.

Для читача, який давно не бачив матлогіку, це можна уявити простіше. Пряме виведення — це як сигналізація: датчики спрацювали, система сама підняла тривогу. Зворотне виведення — це як аудит: ми маємо твердження і крок за кроком шукаємо, які документи його підтримують.

Rete, черга правил і розв’язання конфліктів: чому рушій правил не є купою if/then

Коли правил десятки, їх ще можна виконувати прямим перебором. Коли правил тисячі, а фактів мільйони, простий перебір стає дорогим і крихким. Саме тут історично з’явилися алгоритми на кшталт Rete, Rete-OO і TREAT. Rete запропонував Чарльз Форґі; назва походить від латинського слова «мережа». Rete-OO — це об’єктно-орієнтований варіант, а TREAT — споріднений підхід, який інакше балансує пам’ять і повторні обчислення.

Ідея Rete доступна: не перевіряти кожне правило з нуля після кожної зміни. Рушій будує мережу умов і запам’ятовує часткові збіги. Якщо змінився один факт, система перераховує тільки ту частину мережі, яку він зачіпає. Це схоже на інкрементальну збірку в програмуванні: якщо змінився один файл, не треба перекомпілювати весь світ.

У рушії правил також є робоча пам’ять (working memory) — набір поточних фактів, черга правил (agenda) — список правил, які готові спрацювати, і розв’язання конфліктів (conflict resolution) — механізм вибору, яке правило виконати першим, якщо спрацювали кілька. Пріоритети часто називають salience; українською це можна читати як «вага спрацьовування».

Практичне застосування: коли в робочу пам’ять постійно надходять факти з вимог, тестів, дефектів, конфігурацій і доказових пакетів, рушій не повинен переоцінювати весь набір правил після кожної події. Черга правил дає список готових спрацьовувань, salience і правила розв’язання конфліктів визначають детермінований порядок, а журнал активацій пояснює, чому одне правило виконалося раніше за інше або було відкладене.

Підтримання істинності: як відкликати висновок, коли змінилася підстава

Один із недооцінених пластів класичних експертних систем — системи підтримання істинності (Truth Maintenance Systems, TMS). Їхні різновиди: JTMS (Justification-based Truth Maintenance System, система підтримання істинності на основі обгрунтувань) і ATMS (Assumption-based Truth Maintenance System, система підтримання істинності на основі припущень). Їхня задача проста і дуже практична: пам’ятати, які висновки залежать від яких припущень.

Приклад. Система зробила висновок: «реліз готовий». Цей висновок залежить від фактів: усі критичні дефекти закриті, тести пройшли, дозвіл на виняток погоджений, перегляд впливу на безпеку завершено. Якщо через день дозвіл на виняток відкликали, система має не просто додати новий факт. Вона має відкликати висновок «реліз готовий» або позначити його як такий, що потребує повторного перегляду.

JTMS працює з обгрунтуваннями окремих тверджень. ATMS тримає множини припущень і може показати, в яких комбінаціях висновок лишається істинним. Для досліджень і розробки це дуже близько до трасування: рішення чинне тільки доки чинні його підстави.

Практичне застосування: кожен висновок має зберігати залежності від фактів, правил, джерел, версій доказів і припущень. Якщо джерело застаріло, правило змінилося або виняток відкликали, система може знайти всі залежні висновки, позначити їх як застарілі чи суперечливі, повторити тільки зачеплений ланцюг міркування і показати proof tree або why-not пояснення. У сучасній реалізації це часто робиться через граф залежностей, append-only журнал подій і версійні записи доказів.

Коефіцієнти впевненості: історичний місток між правилами і впевненістю

У MYCIN, одній із найвідоміших медичних експертних систем 1970-х років, використовували коефіцієнти впевненості (certainty factors). Ідея була практичною: лікар-експерт часто не каже «це точно інфекція X». Він каже: «це схоже на X, але доказів неповно».

Коефіцієнт впевненості не є чистою ймовірністю. Це радше інженерна шкала підтримки або спростування гіпотези. Для сучасного читача це можна уявити як попередника оцінки впевненості (confidence score), тільки прив’язаний до правил, а не до нейромережі.

Практичне застосування: коефіцієнт впевненості можна прив’язувати до спрацювання правила, доказового блоку або діагностичної гіпотези, щоб відрізняти «формально підтримано» від «підтримано слабко». Наприклад, високий коефіцієнт дозволяє автоматично запропонувати висновок, середній відправляє його на експертний перегляд, а низький створює запит на додаткові докази. У сучасній експертній системі я б не робив коефіцієнти впевненості єдиним апаратом невизначеності, але вони корисні як проста інженерна шкала, якщо для неї визначено пороги, власника і калібрувальні приклади.

Ймовірність і Байєс: як оновлювати думку при появі доказів

Томас Байєс був англійським священником і математиком XVIII століття. Його цікавила задача, яку тоді називали «оберненою ймовірністю»: якщо ми бачимо наслідок, що можна сказати про ймовірну причину? Саме це питання постійно виникає в інженерії: тест впав — то проблема в тесті, коді, конфігурації, середовищі чи постачальнику?

Теорема Байєса звучить страшніше, ніж працює в інженерній практиці. Вона відповідає на питання: як змінюється довіра до гіпотези, коли з’явився новий доказ.

Якщо модуль часто ламався, має складні залежності і останній тест дав аномальний результат, ймовірність ризику зростає. Якщо потім з’явився додатковий тест, який проходить на кількох конфігураціях, оцінка може знизитися. Це і є оновлення переконання.

Формула класична, у простому текстовому записі: P(H | E) = P(E | H) * P(H) / P(E). Тут H — гіпотеза, E — доказ. У дослідженнях і розробці (Research and Development, R&D) гіпотезою може бути «дефект пов’язаний із часовою поведінкою», «постачальник ризиковий», «реліз нестабільний», «вимога неперевірна».

Чому ця формула справедлива? Достатньо згадати означення умовної ймовірності. P(H | E) — це частка випадків, де одночасно істинні H і E, серед усіх випадків, де є E: P(H | E) = P(H and E) / P(E). Так само P(E | H) = P(E and H) / P(H). Подія H and E та сама, що E and H, тому P(H and E) = P(E | H) * P(H). Підставляємо це в перший вираз і отримуємо теорему Байєса.

Приклад. Нехай до аномального тесту команда вважала, що ймовірність ризикового дефекту в модулі дорівнює 20%. Якщо дефект справді є, такий тест падає у 60% випадків. Якщо дефекту немає, тест усе одно може впасти через шум середовища у 10% випадків. Загальна ймовірність падіння тесту: 0.60 * 0.20 + 0.10 * 0.80 = 0.20. Після падіння тесту оновлена ймовірність гіпотези «дефект справді є» дорівнює 0.60 * 0.20 / 0.20 = 0.60, тобто 60%. Тест не довів дефект, але різко підняв підозру і виправдав додаткову перевірку.

Практичне застосування: експертна система може зберігати початкову ймовірність гіпотези, оновлювати її при появі нового доказу і показувати користувачу не лише фінальний бал, а й шлях оновлення. У діагностиці це означає: падіння тесту підвищило ймовірність дефекту в модулі, незалежний прохід на іншій конфігурації її знизив, а суперечливий сигнал залишив потребу в додатковій перевірці. Інженерно важливо фіксувати prior, джерело доказу, припущення про надійність джерела і поріг, після якого система радить дію.

Байєсівські мережі: карта причинних підказок, а не магія

Байєсівська мережа (Bayesian network) — це граф, де вузли є змінними, а ребра показують залежності. Наприклад: складність модуля впливає на ймовірність дефекту; дефект впливає на падіння тесту; падіння тесту впливає на ризик релізу.

Для читача це можна уявити як схему «як пов’язані підозри». Якщо ми знаємо, що тест впав, мережа може підняти ймовірність кількох причин. Якщо додатково знаємо, що зміна була в конкретному модулі, частина причин стає менш імовірною, частина — більш.

Байєсівська мережа не замінює експерта. Вона змушує явно записати, які фактори на що впливають, і дає контрольований спосіб оновлювати оцінки.

Практичне застосування: байєсівська мережа може бути картою ризикових залежностей у домені: складність компонента, історія дефектів, стабільність постачальника, покриття тестами, якість доказів і готовність релізу. Коли з’являється новий сигнал, система поширює його по графу і показує, які гіпотези стали сильнішими, які ослабли і яку перевірку варто зробити наступною, бо вона найбільше зменшить невизначеність. Таку мережу треба версіонувати разом із таблицями умовних ймовірностей і поясненням, хто їх затвердив.

Марковські ланцюги і моделі рішень простими словами

Андрій Марков був російським математиком початку XX століття. Його цікавили послідовності залежних подій, зокрема такі, де наступний крок залежить не від усієї довгої історії, а від поточного стану. Це була відповідь на дуже практичну для ймовірнісної теорії проблему: як рахувати процеси, що розгортаються в часі, але не пам’ятають кожну дрібницю минулого.

Слово «Марков» часто лякає, але базова ідея дуже проста: майбутній стан залежить від поточного стану, а не від усієї історії. Це не завжди повна правда про реальний світ, але часто корисне наближення.

Марковський ланцюг можна уявити як карту переходів між станами. Наприклад, вимога може переходити зі стану «чернетка» (draft) у «переглянуто» (reviewed), потім у «затверджено» (approved), потім у «змінено після базової версії» (changed after baseline), потім назад у «переглянуто». Якщо ми знаємо частоти таких переходів, можемо оцінювати, де процес застрягає.

Практичне застосування: марковський ланцюг добре лягає на життєвий цикл артефактів: вимога переходить між draft, reviewed, approved, changed after baseline, rework, verified. Експертна система може оцінювати, де процес застрягає, який стан найімовірніший наступним, скільки часу зазвичай займає вихід із проблемного стану і чи є поточний перехід аномальним для цього типу артефакта. Це не доказ істини, а інженерна телеметрія процесу, яку можна використати для раннього попередження.

Прихована марковська модель (Hidden Markov Model, HMM) додає прихований стан. Ми не бачимо реальну причину прямо, але бачимо симптоми. Наприклад, прихований стан проекту — «здоровий», «нестабільний», «передкризовий». Видимі сигнали — зростання дефектів, падіння тестів, затримки перегляду. HMM допомагає оцінити прихований стан за видимими подіями.

Практичне застосування: прихований стан може описувати не видиму подію, а режим роботи домену: здоровий, нестабільний, деградований, передкризовий. Видимими сигналами стають повторні невідповіді, падіння перевірок, зростання незакритих прогалин, прострочені перегляди, дрейф калібрування або конфліктні джерела. Якщо ймовірність прихованого деградованого стану переходить поріг, система не просто малює графік, а радить дію: зібрати докази, запустити повторну перевірку, обмежити відповідь або запросити експерта.

Марковський процес ухвалення рішень (Markov Decision Process, MDP) додає дії і винагороду. Система не просто прогнозує, а вибирає дію: запустити додатковий тест, ескалювати ризик, відкласти реліз, запросити експерта. Якщо стан повністю відомий, це MDP. Якщо стан відомий не повністю, це частково спостережуваний марковський процес ухвалення рішень (Partially Observable Markov Decision Process, POMDP).

Практичне застосування: MDP-підхід корисний там, де система має вибрати наступну дію, а не тільки оцінити стан. Діями можуть бути: запустити додатковий тест, запросити джерело, поставити питання експерту, відмовитися відповідати, ескалювати ризик або дозволити проміжну рекомендацію. Для інженерної реалізації потрібні явні стани, вартість дій, очікувана користь, обмеження безпеки і журнал того, чому саме ця дія була обрана; у першій версії часто достатньо спрощеної політики, а не повного POMDP.

Якщо коротко: марковський ланцюг показує, як система ходить між станами; прихована модель (HMM) вгадує невидимий стан за симптомами; а процеси рішень (MDP і POMDP) ще й підказують, яку дію зробити далі. Решта — деталі реалізації.

Нечітка логіка: коли межа не проходить через так/ні

Не всі інженерні твердження бінарні. Вимога може бути частково покрита. Доказ може бути достатнім для внутрішнього перегляду, але слабким для аудиту. Реліз може бути майже готовим, але мати один відкритий ризик.

Нечітку логіку розвинув Лотфі Заде у 1960-х роках. Його проблема була дуже життєвою: багато людських понять не мають різкої межі. «Високий ризик», «майже готово», «частково покрито» — це не завжди так/ні. Нечітка логіка дозволяє описувати такі стани через ступінь належності від 0 до 1. Це не «розмита відповідальність». Навпаки: це спосіб явно записати, як ми працюємо з градаціями.

Практичне застосування: нечітка логіка допомагає перетворити різкі пороги на керовані зони: джерело не просто «свіже» або «старе», а має ступінь свіжості; доказ не просто «достатній» або «недостатній», а має ступінь покриття. Експертна система може поєднати вхідні сигнали — кількість доказів, давність джерела, впевненість, покриття, суперечність — і отримати пояснювану оцінку готовності або пріоритет перегляду. Важливо: нечітка оцінка не повинна підміняти рішення. Вона має підсвічувати ситуацію, яку людина або правило потім затверджує.

Демпстер-Шафер: коли важливий конфлікт між джерелами

Артур Демпстер і Гленн Шафер працювали з проблемою, де джерела не просто непевні, а ще й неповні або суперечливі. Класична ймовірність часто змушує роздати всю масу довіри між готовими гіпотезами. А в реальних доказах буває інакше: частина інформації підтримує кілька варіантів одразу, частина джерел конфліктує, частина даних узагалі мовчить.

У реальних знаннях часто є не лише невизначеність, а й конфлікт. Один документ каже, що обмеження діє для всіх варіантів продукту. Інший уточнює, що для нової апаратної ревізії воно вже не чинне. Просте середнє може приховати проблему.

Теорія Демпстера-Шафера дозволяє комбінувати маси довіри і явно бачити масу конфлікту. Для доказової системи це корисно: якщо джерела конфліктують, відповідь має не «усереднити» їх, а сказати користувачу, що існує розбіжність.

Практичне застосування: коли джерела не просто слабкі, а взаємно суперечливі, експертній системі потрібні окремі маси підтримки, спростування, невідомості і конфлікту. Тоді відповідь може сказати: це твердження має сильну підтримку з двох джерел, але третє джерело актуальнішої версії створює високий конфлікт, тому висновок блокується або йде на перегляд. Це краще, ніж усереднити все в один бал і втратити головний сигнал: проблема не в нестачі даних, а в їхній несумісності.

Міркування за випадками: досвід як пошуковий простір

Міркування за випадками (Case-Based Reasoning, CBR) мислить не правилами, а випадками. Коли виникає новий дефект, ризик або архітектурне рішення, система шукає схожі попередні випадки. Класичний цикл має чотири кроки: знайти схоже (retrieve), використати попередній досвід (reuse), адаптувати рішення (revise), зберегти новий випадок (retain).

Простими словами: знайди схоже, подивись що спрацювало, адаптуй до нового контексту, збережи новий досвід.

Практичне застосування: випадок у такій системі варто зберігати не як довільний текст, а як структурований запис: проблема, контекст, ознаки, рішення, результат, обмеження застосування, корисність і зворотний зв’язок. Коли з’являється новий дефект, аудиторська знахідка або архітектурна дилема, система знаходить схожі випадки, показує збіг ознак, відмінності, ризики адаптації і пропонує не готову істину, а стартовий сценарій дії. CBR особливо сильний там, де правила важко сформулювати, але є історія схожих ситуацій.

Графи, онтології і валідація знань

Експертна система майже завжди має справу зі зв’язками: вимога перевіряється тестом, тест дав результат, результат підтверджує доказ, доказ належить базовій версії, базова версія належить релізу. Це природно моделювати графом.

Графові алгоритми дають досяжність (reachability), найкоротший шлях (shortest path), центральність (centrality), пошук циклів (cycle detection) і пошук спільнот (community detection). Для R&D це не абстракція. Це відповіді на питання: що зачіпає ця зміна, де розірвано трасування, який компонент є критичним вузлом, які докази залежать від застарілого документа.

Онтології додають типи і смисл: що таке вимога, тест, дефект, ризик, доказ, погодження; які зв’язки допустимі; які класи є підкласами інших. Описові логіки дозволяють виводити порушення моделі: наприклад, вимога безпеки (safety requirement) не може бути затверджена (approved) без доказу перевірки (verification evidence).

Практичне застосування: експертна система може зберігати вимоги, тести, дефекти, ризики, докази, правила, погодження і джерела як типізовані вузли та зв’язки. Тоді аналіз впливу стає запитом по графу: які рішення залежать від цього джерела, де розірване трасування, який доказ застарів, який шлях веде від вимоги до перевірки. Онтологічні обмеження додають смислову валідацію: система може відхилити неправильний тип зв’язку або стан артефакта ще до того, як він зіпсує висновок.

Багатокритеріальний вибір: коли правильна відповідь залежить від ваг

У R&D часто немає одного критерію. Вибір архітектури залежить від вартості, ризику, часу, супроводжуваності, продуктивності, безпеки, залежності від постачальника. Багатокритеріальний аналіз рішень робить ці критерії явними.

Найпростіший варіант — зважена сума. Більш структуровані підходи: метод аналізу ієрархій (Analytic Hierarchy Process, AHP), який популяризував Томас Сааті, для попарних порівнянь; TOPSIS (Technique for Order Preference by Similarity to Ideal Solution) для відстані до ідеального рішення; PROMETHEE (Preference Ranking Organization Method for Enrichment Evaluations) і ELECTRE (ELimination Et Choix Traduisant la REalite) для переважання, коли варіанти порівнюються не одним числом, а відношенням переваги. Усі ці методи вирішують одну людську проблему: як чесно порівнювати варіанти, коли критерії тягнуть у різні боки.

Практичне застосування: альтернатива має оцінюватися через явні критерії, ваги, джерела оцінок, відсутні дані і чутливість результату до зміни ваг. Наприклад, система може порівняти два архітектурні варіанти або два релізні сценарії й показати не лише переможця, а й внесок кожного критерію, слабкі докази, конфліктні припущення і межу, після якої рекомендація зміниться. Головна користь не в красивій формулі, а в тому, що команда перестає ховати ваги в інтуїції.

Якщо коротко: усі ці абревіатури (AHP, TOPSIS, PROMETHEE, ELECTRE) розв’язують одну задачу — чесно порівняти варіанти за кількома критеріями і показати, чому переміг саме цей. Який конкретний метод узяти — питання даних і смаку, а не принципу.

Оптимізація, розв’язання обмежень і планування

Оптимізація відповідає на питання: як знайти найкраще рішення за обмежень. Наприклад: мінімізувати час тестування, але покрити всі високоризикові вимоги; розподілити інженерів між задачами; вибрати набір тестів для нічного запуску.

Лінійне і цілочисельне програмування добре працює з ресурсами, портфелями, розкладами. Програмування в обмеженнях (constraint programming) сильне там, де важливі дискретні обмеження: не можна ставити дві задачі одному стенду одночасно, тест A має йти після тесту B, експерт X доступний тільки в певні дні.

Планування в штучному інтелекті додає модель дій. PDDL (Planning Domain Definition Language, мова опису домену планування) описує стани, дії, передумови і наслідки. HTN-планування (Hierarchical Task Network planning, планування через ієрархічну мережу задач) розкладає високорівневу задачу на підзадачі. Це корисно, коли експертна система має не просто сказати «є проблема», а запропонувати послідовність дій.

Практичне застосування: планувальний шар може перетворити ціль на набір обмежень і кроків: які докази треба зібрати, які перевірки запустити, кого залучити, що не можна виконувати паралельно і який стан означає завершення. Для експертної системи це корисно в плануванні релізу, нічного набору тестів, реагування на інцидент або закриття прогалини в доказах. На практиці часто починають не з повного планувальника, а з шаблонів HTN: високорівнева задача розкладається на перевірені підзадачі з передумовами, результатами і точками контролю.

Пошук інформації і векторна математика

Експертна система має знаходити знання. Для цього потрібні BM25 (Best Matching 25, класична функція ранжування пошуку), TF-IDF (Term Frequency — Inverse Document Frequency, частота терміна з поправкою на рідкість), щільні векторні подання (dense embeddings), косинусна схожість (cosine similarity), гібридний пошук (hybrid search) і повторне ранжування (reranking). Це не «модель думає». Це математика пошуку.

BM25 добре ловить точні терміни, ідентифікатори, назви стандартів. Вектори добре ловлять близький зміст, навіть якщо слова різні. У регульованому інжинірингу точний пошук часто важливіший, ніж здається: ASIL decomposition і «розбиття вимог безпеки» можуть бути близькими, але посилання на конкретний пункт стандарту не можна замінити красивою схожістю.

Практичне застосування: під час індексації система має зберігати не лише текстовий фрагмент, а й джерело, версію, тип артефакта, ідентифікатори, класифікацію, дату чинності і зв’язки з іншими записами. Під час пошуку вона може поєднати точний BM25 для назв стандартів та ідентифікаторів, векторну схожість для близького змісту, фільтри за доменом і повторне ранжування. Результат пошуку повинен показувати, який сигнал спрацював, і лишатися кандидатом на доказ, доки його не прив’язано до конкретного висновку.

Каузальний аналіз: кореляція не є причиною

Ось типова пастка. Команда ввела нову практику код-рев’ю, і за квартал дефектів стало менше. Спокусливо записати це в перемогу процесу. Але паралельно могло статися багато іншого: прийшли сильніші інженери, задачі стали простішими, або просто змінилося те, що ми тепер вважаємо дефектом. Кореляція є, причинності може й не бути.

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

Джуда Перл, один із ключових дослідників причинності в штучному інтелекті, запропонував для цього зручну мову. Його позначення do(X) розділяє два дуже різні речення: «ми побачили X» і «ми самі змінили X». Спостереження — це коли ми помітили, що команди з частими рев’ю мають менше дефектів. Втручання — це коли ми свідомо ввімкнули рев’ю і поміряли, що змінилося. Тільки друге наближає нас до причини.

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

Пояснюваність, калібрування і контрфакти

Система, яка не пояснює відповідь, не є доказовою. Для шару машинного навчання (Machine Learning, ML) потрібні інструменти пояснюваності: важливість ознак (feature importance), SHAP (SHapley Additive exPlanations), LIME (Local Interpretable Model-agnostic Explanations) і контрфактичні пояснення (counterfactual explanations). Вони не роблять модель істинною, але допомагають побачити, чому вона схилилася до певного висновку.

Контрфактичне пояснення відповідає на питання: що треба змінити, щоб рішення стало іншим. Це той самий тип підказки, як «вам бракує 50 балів до схвалення кредиту». Наприклад: «реліз став би готовим, якби були закриті дефекти D-17 і D-22 та додано доказ (evidence) для R-41». Це дуже корисно, бо перетворює пояснення на план дій.

Калібрування відповідає на інше питання: чи відповідає заявлена впевненість реальній точності. Найпростіша аналогія — прогноз погоди. Якщо синоптик сто разів сказав «ймовірність дощу 70%», то в добре каліброваній системі дощ має піти приблизно в 70 випадках. Якщо система каже «90% впевнено», а помиляється у третині таких випадків, це не впевненість, а красиве число.

Практичне застосування: для кожної машинної або гібридної рекомендації система має показувати важливі вхідні ознаки, джерела, калібровану впевненість, відомі обмеження і причину можливої відмови відповідати. Контрфактичне пояснення перетворює це на інженерний план: які докази, пороги, дефекти, припущення або перевірки треба змінити, щоб рішення стало іншим. Такі пояснення мають потрапляти не тільки в інтерфейс, а й у журнал перегляду, щоб експерт міг прийняти, відхилити або уточнити рекомендацію.

Як вибирати апарат під задачу

Математичний метод треба вибирати не тому, що він модний, а тому, яке питання стоїть перед системою. Це як набір інструментів у майстерні: цвяхи забивають молотком, а гвинти закручують викруткою, і навпаки виходить погано. Ось проста підказка, який інструмент брати під типове питання.

• Треба перевірити жорстке правило чи політику — логіка, правила, SMT (Satisfiability Modulo Theories, перевірка виконуваності з урахуванням теорій) або Datalog.
• Треба оцінити невизначеність — ймовірнісна модель, калібрування або теорія доказів.
• Треба знайти схожий минулий випадок — CBR і метрики схожості.
• Треба пройти ланцюг залежностей — граф.
• Треба скласти план дій — планування або оптимізація.
• Треба пояснити рішення моделі — пояснюваний штучний інтелект (Explainable AI, XAI) і контрфакти.
• Треба чесно сказати «не знаю» — калібрована відмова.

Це і є головна дисципліна прикладної математики: не один метод для всього, а правильний метод для правильного класу питань.

Два уроки з математичного шару

Урок 1. Оцінка без порогу не є доказом

У багатьох системах з’являється красива оцінка: ризику 0.72, впевненості 0.85, схожості 0.91. Проблема в тому, що саме по собі число 0.72 нічого не вирішує. Це як термометр, який показує число, але ніхто не сказав, з якої температури вважати пацієнта хворим. Поки не визначено, що означає 0.72, хто затвердив поріг, для якого домену він чинний і що робити нижче порогу, це не доказ, а декоративне число.

Практичний висновок: кожна метрика має мати відповідального власника, поріг, умови чинності і тестові приклади. Інакше вона лише створює відчуття точності.

Урок 2. Модель без сценарію відмови завжди говорить зайве

Найнебезпечніша експертна система — та, що завжди знаходить відповідь. Це як співробітник, який ніколи не каже «не знаю»: рано чи пізно він впевнено порадить дурницю. У реальному світі джерел може бракувати, докази можуть конфліктувати, базова версія може не збігатися, а користувач може не мати доступу до потрібної частини даних.

Практичний висновок: математика відмови така сама важлива, як математика відповіді. Система має формально знати, коли повернути «бракує доказів», «джерела конфліктують», «доступ заборонено», «поза межами задачі» або «потрібен експертний перегляд». Чесне «не знаю» часто коштує дешевше за впевнену помилку.

Висновок

Якщо з усієї статті лишити одну думку, то таку: експертну систему робить доказовою не якийсь один геніальний алгоритм, а вміння для кожного питання взяти правильний інструмент і чесно показати свою роботу. Логіка відповідає на те, що з чого випливає. Ймовірність і теорія доказів — наскільки цьому можна вірити. Графи — що з чим пов’язано. Оптимізація і планування — що робити далі. Причинність — чи це справді причина, чи лише збіг. А математика відмови — коли краще промовчати.

Прикладна математика тут — не академічна прикраса, а набір робочих мов, якими система описує факти, невизначеність, залежності, обмеження, рішення і відмови. Без цього велика мовна модель лишається приємним співрозмовником, але не стає системою, на висновки якої можна спертися у відповідальному рішенні.

Я навмисно показав широкий спектр — від Rete і TMS до марковських моделей, CBR, графів, оптимізації, планування, причинності і XAI — не для того, щоб усе це впроваджувати в першій версії. А щоб у вас сформувалася карта методів: коли інженер бачить задачу, він має впізнавати її клас і тягнутися до доречного інструмента, а не забивати кожен цвях одним молотком.

Спойлер наступної статті. Математика сама по собі не працює в робочому середовищі. У наступній статті я перейду від методів до реалізації: які мови програмування, рушії правил, онтологічні інструменти, векторні бази, каркаси RAG, рушії політик, конвеєри розпізнавання тексту, інструменти походження даних і платформи обслуговування моделей реально використовують для побудови сучасних експертних систем.

Питання до читачів

Питання очима інженера рушія міркувань:

1) Спираючись на розділ про підтримання істинності (TMS): що у ваших системах стається з висновком «реліз готовий», коли відкликали його підставу — він автоматично відкликається й переобчислюється, чи тихо лишається застарілим «ще одним фактом»?
2) Спираючись на розділ про Rete, чергу правил і розв’язання конфліктів: коли спрацьовують кілька правил одночасно, у вас детермінований порядок (salience, журнал активацій) чи «як вийде» — і чи зможете ви потім пояснити, чому одне правило виконалося раніше за інше?

Питання очима аналітика даних і моделей невизначеності:

1) Спираючись на розділ про Байєса й оновлення переконань: де у ваших оцінках ризику явно зафіксовані початкова ймовірність (prior), надійність джерела і поріг дії — чи фінальний бал з’являється «з повітря»?
2) Спираючись на розділ про каузальний аналіз («кореляція не є причиною»): який із ваших нещодавніх висновків «процес покращив метрику» був лише спостереженням, а який — доведеним втручанням (do(X)) з контролем сторонніх факторів?

Питання очима системного аналітика доказовості:

1) Спираючись на Урок 1 «оцінка без порогу не є доказом»: які з ваших красивих чисел (0.72 ризику, 0.91 схожості) мають власника, поріг і умови чинності, а які лишаються декоративними?
2) Спираючись на Урок 2 і теорію Демпстера-Шафера: чи вміє ваша система відрізнити «бракує доказів» від «джерела конфліктують» — і чи має вона формальне право сказати «не знаю» замість упевненої помилки?