Експертні системи: від теореми Байєса до доказових рішень ШІ

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

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

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

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

Саме тут історія експертних систем знову стає актуальною.

Для мене ця тема не є суто теоретичною. Я прийшов до неї від давнього читання книжки Дж. Елти, М. Кумбс «Экспертные системы: Концепции и примеры» на початку 1990-х, через власний досвід розбудови інформаційних систем, інформаційну безпеку, керування розробкою, регульовану автомобільну інженерію, трасування вимог, інформаційну та кібербезпеку і сучасні ШІ-асистовані робочі процеси. Тому в цій статті експертна система розглядається не як музейна технологія і не як модний додаток до мовної моделі, а як практичний спосіб зробити рішення доказовими, пояснюваними і придатними до аудиту.

До великих мовних моделей були правила, логіка і докази

Перший шар експертних систем — формальна логіка. У найпростішому вигляді це знайоме правило відокремлення, або modus ponens:

Якщо A -> B
A істинне
Отже, B істинне

У технічній системі це може звучати так:

Якщо зміна зачіпає вимогу безпеки,
то потрібен аналіз впливу.

Зміна CR-17 зачіпає вимогу безпеки SR-42.
Отже, для CR-17 потрібен аналіз впливу.

Це не ШІ у сучасному маркетинговому сенсі. Але це вже машинне міркування над фактами і правилами.

У 1950-60-х роках розвивалися булева алгебра, логіка висловлювань, логіка предикатів, автоматичне доведення теорем. Важливою віхою стало резолюційне доведення теорем Джона Робінсона у 1965 році — метод автоматичного доведення в логіці першого порядку. Ідея була амбітна: якщо знання записані формально, машина може виводити нові твердження.

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

Продукційні правила: класичне «IF-THEN»

У 1970-х і 1980-х роках багато експертних систем будувалися навколо правил виду:

IF умова
THEN висновок або дія

Класичні приклади — DENDRAL для хімічного аналізу, MYCIN для медичної діагностики, PROSPECTOR для геології, XCON/R1 для конфігурації комп’ютерних систем. Це були не чатботи. Це були системи, у яких знання експертів переводилися в правила, а механізм виведення застосовував ці правила до конкретного випадку.

Два базові режими міркування з того часу використовуються досі.

Пряме виведення — рух від фактів до висновків:

Є факти A, B, C.
Правила кажуть: A + B -> D, D + C -> E.
Отже, система виводить D, потім E.

Це зручно для перевірок: що в цьому проєкті не так, які правила порушені, які прогалини є.

Зворотне виведення — рух від цілі назад до фактів:

Ціль: довести E.
Для E потрібно D і C.
Для D потрібно A і B.
Перевіряємо, чи є A, B, C.

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

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

LISP і PROLOG: дві культури раннього ШІ

Окремо варто згадати LISP і PROLOG. Це не просто старі мови програмування, які люблять згадувати на історичних лекціях. Для експертних систем вони були практичними інструментами мислення.

LISP був природним середовищем для символьного ШІ: списки, дерева, рекурсія, динамічна побудова структур, правила як дані. У LISP-звичному стилі знання легко ставало програмою, а програма — структурою, яку можна змінювати, передавати і виконувати. Саме тому багато ранніх систем ШІ, механізмів правил і дослідницьких прототипів жили в LISP-світі або в мовах, натхненних ним.

Умовне правило для релізного рішення в LISP-подібному стилі могло б виглядати так:

(defrule reliz-zablokovano-krytychnym-defektom
    (and (reliz ?r)
             (defekt ?d)
             (vplyvaye ?d ?r)
             (seryoznist ?d krytychna)
             (stan ?d vidkrytyy))
    (assert (status-relizu ?r zablokovano)))

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

PROLOG пішов іншим шляхом: логічне програмування. Ви описуєте факти і правила, а система сама шукає доведення. Це дуже близько до зворотного виведення.

vymoga_bezpeky(sr_42).
zachipaye(cr_17, sr_42).

potrebuye_analizu_vplyvu(Zmina) :-
        zachipaye(Zmina, Vymoga),
        vymoga_bezpeky(Vymoga).

Запит:

?- potrebuye_analizu_vplyvu(cr_17).

Відповідь:

true

А якщо запитати:

?- potrebuye_analizu_vplyvu(X).

система може знайти всі зміни, для яких потрібен аналіз впливу. Це вже не просто пошук у документах. Це міркування над базою фактів.

Сучасний приклад для автомобільної інженерії може бути не в тому, щоб «реалізувати ISO 26262 у PROLOG», а в тому, щоб формально перевіряти прості доказові правила навколо вимог. Наприклад, у функціональній безпеці вимога з високим ASIL не має йти в реліз без зв’язку з ціллю безпеки, технічною вимогою, перевіркою і результатом тесту. Це умовний приклад, не текст стандарту:

safety_goal(sg_brake_assist).
asil(sg_brake_assist, d).

functional_safety_requirement(fsr_detect_sensor_fault).
technical_safety_requirement(tsr_enter_degraded_mode).
technical_safety_requirement(tsr_report_diagnostic_fault).

derived_from(fsr_detect_sensor_fault, sg_brake_assist).
derived_from(tsr_enter_degraded_mode, fsr_detect_sensor_fault).
derived_from(tsr_report_diagnostic_fault, fsr_detect_sensor_fault).

verified_by(tsr_enter_degraded_mode, test_tsr_014).
test_passed(test_tsr_014).

includes(release_2026_05, tsr_enter_degraded_mode).
includes(release_2026_05, tsr_report_diagnostic_fault).

missing_iso26262_evidence(Req, safety_trace) :-
    technical_safety_requirement(Req),
    \+ derived_from(Req, _).

missing_iso26262_evidence(Req, verification) :-
    technical_safety_requirement(Req),
    \+ verified_by(Req, _).

missing_iso26262_evidence(Req, failed_test) :-
    verified_by(Req, Test),
    \+ test_passed(Test).

release_blocked_for_safety(Release) :-
    includes(Release, Req),
    missing_iso26262_evidence(Req, _).

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

?- missing_iso26262_evidence(tsr_report_diagnostic_fault, Reason).

Або ширшим:

?- release_blocked_for_safety(release_2026_05).

Для ISO/SAE 21434 логіка схожа, але предмет інший: кібербезпекові цілі, сценарії загроз, рішення з обробки ризику, вимоги і перевірки. Наприклад:

cybersecurity_goal(csg_secure_update).
threat_scenario(ts_update_tampering).
risk_treatment(ts_update_tampering, reduce).

cybersecurity_requirement(csr_signed_update).
cybersecurity_requirement(csr_secure_diagnostics).
derived_from(csr_signed_update, csg_secure_update).
derived_from(csr_secure_diagnostics, csg_secure_update).
treats(csr_signed_update, ts_update_tampering).
treats(csr_secure_diagnostics, ts_update_tampering).

verified_by(csr_signed_update, security_test_021).
test_passed(security_test_021).

changes(change_88, csr_secure_diagnostics).

missing_iso21434_evidence(Req, threat_trace) :-
    cybersecurity_requirement(Req),
    \+ treats(Req, _).

missing_iso21434_evidence(Req, risk_treatment) :-
    cybersecurity_requirement(Req),
    treats(Req, Threat),
    \+ risk_treatment(Threat, _).

missing_iso21434_evidence(Req, security_verification) :-
    cybersecurity_requirement(Req),
    \+ verified_by(Req, _).

cybersecurity_review_required(Change) :-
    changes(Change, Req),
    missing_iso21434_evidence(Req, _).

Тут PROLOG корисний не тому, що він «розумніший» за сучасні мови. Він корисний тим, що запит до знань читається майже як формальна вимога: якщо зміна зачіпає кібербезпекову вимогу, а ланцюг загроза -> рішення з ризику -> вимога -> перевірка неповний, потрібен перегляд.

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

mission_requirement(mr_secure_field_update).
cybersecurity_requirement(csr_offline_signature_check).
safety_requirement(sr_fail_safe_on_update_error).
safety_requirement(sr_operator_confirmation).

derived_from(csr_offline_signature_check, mr_secure_field_update).
derived_from(sr_fail_safe_on_update_error, mr_secure_field_update).
derived_from(sr_operator_confirmation, mr_secure_field_update).

verified_by(csr_offline_signature_check, security_test_044).
verified_by(sr_fail_safe_on_update_error, safety_test_031).

contains(field_update_2026_05, csr_offline_signature_check).
contains(field_update_2026_05, sr_fail_safe_on_update_error).
contains(field_update_2026_05, sr_operator_confirmation).

requires_independent_review(Change) :-
    changes(Change, Req),
    cybersecurity_requirement(Req).

requires_independent_review(Change) :-
    changes(Change, Req),
    safety_requirement(Req).

field_release_blocked(Item) :-
    contains(Item, Req),
    \+ verified_by(Req, _).

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

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

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

Теорема Байєса набагато старша за експертні системи, але для ШІ вона стала одним із фундаментальних способів говорити про невизначеність:

P(H | E) = P(E | H) * P(H) / P(E)

Де H — гіпотеза, E — доказ або спостереження. Формула відповідає на дуже практичне питання: якщо ми побачили новий доказ, як змінюється ймовірність гіпотези?

У діагностиці це виглядає природно: якщо симптом E часто трапляється при хворобі H, то наявність симптому підвищує ймовірність хвороби. У кібербезпеці — якщо певний набір подій часто відповідає атаці, нова подія змінює оцінку ризику. У проєктному управлінні — якщо команда має застарілі оцінки, невдалі тести і відкриті критичні дефекти, ймовірність проблемного релізу зростає.

Маленький числовий приклад. Нехай до аналізу ми оцінюємо ймовірність проблемного релізу як 5%:

P(H) = 0.05

З’явився доказ E: регресійний тест упав на критичному сценарії. З історії відомо, що при справді проблемному релізі такий симптом трапляється часто:

P(E | H) = 0.80

А при нормальному релізі такий самий симптом трапляється рідше:

P(E | not H) = 0.10

Тоді:

P(E) = P(E | H) * P(H) + P(E | not H) * P(not H)
    = 0.80 * 0.05 + 0.10 * 0.95
    = 0.135

P(H | E) = 0.80 * 0.05 / 0.135
        ≈ 0.296

Один провалений регресійний тест підняв оцінку ризику з 5% майже до 30%. Якщо потім додається другий незалежний сигнал — наприклад, зміна вимоги після базової версії без повторного погодження, — оцінка може вирости ще сильніше. Саме так математично виглядає фраза «новий доказ змінив картину».

Але чистий Байєс у промислових експертних системах має проблему: треба знати багато початкових і умовних ймовірностей. У складних доменах це важко. Експерти часто не можуть чесно сказати, що P(E | H) = 0.73. Вони кажуть: «це сильний сигнал», «це слабкий доказ», «це підозріло, але не достатньо».

Тому поряд із байєсівським підходом розвивалися більш практичні моделі невизначеності.

Коефіцієнти впевненості: інженерний компроміс MYCIN

Творці MYCIN (Едвард Шортліфф та колеги) зіткнулися з проблемою: класичний Байєсівський підхід вимагав знання величезної кількості апріорних та умовних ймовірностей, яких у лікарів просто не було. Крім того, лікарі мислять не суворими ймовірностями, а категоріями «це підтверджує» або «це спростовує» гіпотезу. Тому MYCIN використовував коефіцієнти впевненості. Ідея була не будувати повну байєсівську модель, а дати експертам спосіб виразити ступінь підтримки або заперечення гіпотези.

Спрощено:

CF(H, E) = MB(H, E) - MD(H, E)

де MB — міра підтримки гіпотези, а MD — міра заперечення.

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

CFcombined = CF1 + CF2 * (1 - CF1)

Наприклад, перший доказ підтримує гіпотезу «реліз має інтеграційний ризик» із коефіцієнтом 0.6. Другий незалежний доказ підтримує її з коефіцієнтом 0.5:

CF1 = 0.6
CF2 = 0.5

CFcombined = 0.6 + 0.5 * (1 - 0.6)
           = 0.6 + 0.2
           = 0.8

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

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

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

Нечітка логіка: коли світ не чорний і не білий

Лотфі Заде у 1965 році запропонував нечіткі множини. У класичній множині елемент або належить множині, або ні. У нечіткій множині є ступінь належності:

mu_A(x) in [0, 1]

Наприклад, температура 80 градусів може належати множині «висока температура» зі ступенем 0.7, а 95 градусів — зі ступенем 0.95.

В інженерній підтримці рішень це можна уявити так:

gotovnist_pokryttya_testamy = 0.84
gotovnist_pogodzhen         = 0.60
gotovnist_stanu_defektiv    = 0.70

Для правила «реліз готовий тільки настільки, наскільки готова найслабша критична умова» можна взяти нечітку кон’юнкцію як мінімум:

gotovnist_relizu = min(0.84, 0.60, 0.70) = 0.60

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

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

Сьогодні нечітку логіку не завжди так називають. Часто це просто шкали, оцінювання, нормалізовані значення, пороги. Але математична ідея та сама: не вся технічна реальність зводиться до true/false.

Демпстер-Шафер: докази без повної впевненості

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

Правило комбінування доказів у спрощеному вигляді виглядає так:

m(A) = sum(m1(B) * m2(C), де B перетин C = A) / (1 - K)

де K — конфлікт між джерелами доказів.

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

Для сучасних доказових систем ШІ це дуже актуально. Якщо тест каже одне, статус задачі інше, а вимога змінилася після базової версії, система не має вибирати найкрасивіший текст. Вона має показати конфлікт.

Графи знань: від семантичних мереж до графів знань

У 1960-70-х роках активно розвивалися семантичні мережі і фрейми — способи представити знання як поняття, властивості і зв’язки. Наприклад:

Вимога R-17 перевіряється_тестом T-9
Тест T-9 впав_на_базовій_версії B-3
Дефект D-4 зачіпає_вимогу R-17

Це вже не просто текст. Це граф.

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

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

Байєсівські мережі: причинні графи ймовірностей

У 1980-х роках байєсівський підхід отримав сильний розвиток через байєсівські мережі, пов’язані з роботами Джуди Перла. Це граф, у якому вузли — випадкові величини, а ребра — залежності. Спільний розподіл можна розкласти так:

P(X1, X2, ..., Xn) = product P(Xi | Parents(Xi))

Це потужна ідея: складну ймовірнісну модель можна розбити на локальні залежності.

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

Пошук: від TF-IDF до векторних представлень

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

Класична векторна модель простору представляла документ і запит як вектори. Схожість рахували через косинусну схожість:

cos(theta) = (A · B) / (||A|| * ||B||)

Як це працює інтуїтивно? Нехай запит представлений вектором Q = [1, 0], а два документи — векторами D1 = [0.8, 0.6] і D2 = [0.1, 0.99]. Для D1:

cos(Q, D1) = (1*0.8 + 0*0.6) / (1 * sqrt(0.8^2 + 0.6^2))
           = 0.8 / 1
           = 0.8

Для D2:

cos(Q, D2) ≈ 0.1

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

Пізніше з’явилися TF-IDF, BM25, повнотекстовий пошук. Сьогодні до цього додалися векторні представлення і щільний векторний пошук. Але базова ідея не змінилася: знайти документи або фрагменти, які мають найбільше відношення до питання.

TF-IDF (Term Frequency-Inverse Document Frequency) — це статистичний метод оцінки значущості слова в тексті, який є частиною колекції документів. BM25 (Best Matching 25) виконує роль головного інструменту для швидкого пошуку знань та релевантних фактів у великих текстових базах даних.

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

У технічних доменах одного семантичного пошуку мало. Потрібен гібрид: точний збіг для ідентифікаторів, BM25 для ключових слів, векторні представлення для сенсу, граф для зв’язків. Якщо інженер шукає Com_SendSignal, ISO 26262-6:2018 7.4.5 або код помилки, система не має «семантично приблизно» зрозуміти запит. Вона має знайти точний символ.

Міркування за схожими випадками: ми вже бачили таку історію?

У 1980-90-х роках сформувалося міркування за схожими випадками, або CBR. Його логіка дуже людська: коли з’являється новий випадок, знайди схожий старий, подивись, що тоді спрацювало, адаптуй рішення і збережи новий досвід.

Класичний цикл CBR:

знайти -> використати -> переглянути -> зберегти

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

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

Багатокритеріальний аналіз рішень: коли є кілька поганих варіантів

Багато реальних рішень не мають ідеальної відповіді. Вибір архітектури, постачальника, релізного сценарію, стратегії пом’якшення ризику або плану розробки — це не задача «довести теорему». Це задача порівняти альтернативи.

Один із практичних апаратів — зважене оцінювання:

otsinka = sum(vaga_i * normovane_znachennya_i) / sum(vaga_i)

Наприклад, треба обрати релізний сценарій із трьох альтернатив. Критерії: бізнес-цінність, ризик постачання, готовність з погляду відповідності. Нехай ваги такі:

biznes_tsinnist              vaga = 0.4
nyzkyy_ryzyk_postachannya    vaga = 0.3
gotovnist_vidpovidnosti      vaga = 0.3

Альтернатива A: швидкий реліз із високою цінністю, але середньою готовністю:

otsinka_A = 0.4*0.90 + 0.3*0.45 + 0.3*0.60
      = 0.675

Альтернатива B: повільніший реліз із кращою картиною відповідності:

otsinka_B = 0.4*0.70 + 0.3*0.70 + 0.3*0.85
      = 0.745

Альтернатива C: мінімальний реліз із низьким ризиком, але меншою цінністю:

otsinka_C = 0.4*0.50 + 0.3*0.90 + 0.3*0.80
      = 0.710

За цією моделлю перемагає B. Але головне не сама перемога. Головне, що видно механіку рішення. Якщо бізнес збільшить вагу швидкості виходу на ринок або знизить вагу готовності з погляду відповідності, результат може змінитися. Це і є простий аналіз сценарію «що буде, якщо», а не магічна рекомендація.

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

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

Детерміновані ядра: де мовна модель не має права рахувати

Окремо треба сказати про формули. У системах безпеки або відповідності є обчислення, які не можна віддавати мовній моделі як генеративну задачу. Наприклад, FMEDA-метрики, SPFM, LFM, PMHF, ASIL-декомпозиція, фінансові або контрактні формули.

Тут потрібна не «розумна відповідь», а детерміноване обчислювальне ядро:

вхідні дані -> версія формули -> результат -> аудиторський запис

Приклад із метрик безпеки. Метрику одноточкових відмов, або SPFM, у спрощеному вигляді можна подати так:

SPFM = 1 - sum(lambda_SPF) / sum(lambda_total)

Якщо загальна інтенсивність відмов lambda_total = 100, а сума одноточкових відмов lambda_SPF = 2, тоді:

SPFM = 1 - 2 / 100 = 0.98

Тобто 98%. Тут немає простору для «модель подумала». Є формула, одиниці, вхідні дані, версія стандарту, припущення і результат. Якщо вхідні дані зміняться, результат має відтворювано змінитися. Якщо формула змінилася — має бути видно, яка версія формули застосовувалася.

Формула має мати версію, джерело, обмеження застосування, хеш вхідних даних, припущення і запис виконання. Мовна модель може пояснити результат людською мовою. Але сам результат має рахувати звичайний перевірений код.

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

Що еволюціонувало

Якщо звести всю історію в одну таблицю, вийде так:

Тобто сучасна експертна система не заперечує старі методи. Вона збирає їх у нову архітектуру.

Доказовість як головна вимога

Для мене головна еволюція експертних систем не в тому, що вони стали «розмовляти природною мовою». Це важливо, але не головне. Головне — перехід від відповіді до доказового пакета.

Слабка відповідь:

Реліз виглядає готовим.

Сильна відповідь:

Релізний пакет має 84% покриття вимог тестами.
Три вимоги змінилися після базової версії B-17.
Два критичні дефекти закриті, але один тест повторного запуску відсутній.
Ризик R-12 прийнятий, але погодження ще не підписане.
Висновок: готовність часткова, релізне рішення потребує перегляду.
Джерела: вимоги, тести, дефекти, ризики, записи погоджень.

Різниця не в стилі. Різниця в тому, що другий варіант можна перевірити.

Доказова експертна система має повертати не тільки висновок, а й:

• джерела;
• версії;
• правила;
• припущення;
• рівень впевненості;
• прогалини;
• конфлікти;
• відповідального за перегляд;
• слід міркування.

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

Де тут місце великих мовних моделей

Великі мовні моделі не вороги експертних систем. Навпаки, вони закривають їхню історичну слабкість — незручний інтерфейс і складність роботи з текстом.

Мовні моделі добре:

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

Але мовна модель не має бути єдиним місцем, де живе правило, формула або рішення. Правило має бути явним. Формула має бути детермінованою. Доказ має вести до джерела. Перегляд має належати людині.

Найсильніша сучасна модель — гібридна:

мовна модель для мови і пошуку
+ правила для перевірок
+ граф для зв'язків
+ пошук для джерел
+ детерміновані ядра для чисел
+ модель впевненості для невизначеності
+ слід міркування для пояснення
+ людський перегляд для відповідальності

Це вже не просто чатбот. Це ближче до інженерного ланцюга інструментів.

Простий тест для будь-якої системи ШІ

Якщо вам показують «ШІ-експерта» або «ШІ-порадника», можна поставити кілька питань.

Перше: чи може система показати джерела кожного суттєвого твердження?

Друге: чи розрізняє вона факт, припущення, висновок і рекомендацію?

Третє: чи має вона явні правила, чи всі правила заховані в інструкції до моделі?

Четверте: чи може вона сказати «даних недостатньо»?

П’яте: чи видно, яка версія знань, моделі, формули або набору правил використана?

Шосте: чи можна повторити результат через місяць?

Сьоме: хто приймає фінальне рішення — система чи людина?

Якщо відповіді на ці питання нечіткі, перед вами, можливо, хороший асистент. Але ще не доказова експертна система.

Чотири практичні уроки, яких часто бракує у книжках

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

Маленький словничок, щоб уроки читалися легко:

• Документ — те, що ми завантажили в систему: PDF, Word, лист, презентація. Справжній документ повинен мати атрибути автора і дату створення.
• Чанк (англ. chunk) — невеликий шматок документа, наприклад абзац або кілька речень. Системи зазвичай зберігають документи саме шматками, бо так легше шукати.
• Індекс — як алфавітний покажчик у бібліотеці: швидко підказує, у якому шматку якого документа є потрібні слова або поняття.
• Ретриєвер (англ. retriever) — «бібліотекар». За запитом дістає з індексу найбільш схожі чанки.
• Промпт (англ. prompt) — вхідний текст, який ми даємо мовній моделі: і питання користувача, і знайдені чанки, і правила.
• Релевантність / score — число від 0 до 1, наскільки чанк «схожий» на запит. Чим вище, тим більше шансів, що це справді те, що шукали.
• Слід міркування (англ. reasoning trace) — звіт, який система веде поряд із відповіддю: які джерела взяла, які правила застосувала, які припущення зробила.

Тепер уроки.

Урок 1. На вході має бути сито: сміття не повинно потрапити в індекс

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

Як це трапляється у системах ШІ. Дуже багато промислових документів — PDF. Усередині PDF літери часто закодовані не як «А, Б, В», а як номери малюнків (так звані гліфи). Щоб перетворити їх назад на текст, потрібна спеціальна табличка всередині файлу. Якщо її немає або вона зламана, програма витягує не текст, а послідовність кодів, схожу на бінарний шум:

"\u0026\u0003\u0002\u001f\u0007..."

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

Простий захист. Перед тим як покласти чанк в індекс, рахуємо частку нормальних друкованих символів:

частка_читабельного = кількість_друкованих_символів / усього_символів

якщо частка_читабельного < 70 % → не записуємо цей чанк, пробуємо іншим парсером

Це не захист від помилок самої мовної моделі. Це захист від помилок «бібліотекаря», які потім виглядають як помилки моделі.

Урок 2. Між пошуком і моделлю має сидіти охоронець

Аналогія. Уявіть кол-центр банку. Оператор отримує дзвінок і запит: «перевірте за документами, чи можна видати кредит цьому клієнтові». Він іде до архіву, але архіваріус видає йому п’ять папок, і всі — не цього клієнта. Що зробить дисциплінований оператор? Скаже клієнту: «ваших документів у архіві не знайшлося». А недисциплінований — відкриє чужі папки і впевнено зачитає звідти, бо «папки ж є».

Мовна модель — той самий оператор. Якщо їй у промпт покласти будь-які знайдені чанки, вона побудує впевнену відповідь, навіть коли всі вони — «чужі папки».

Як це виглядає на практиці. Ретриєвер повернув п’ять чанків, але:

• усі мають релевантність 0.31 (поріг, нижче якого ми вже не довіряємо), або
• усі — кракозябри з PDF без таблиці гліфів (див. урок 1), або
• усі — із зовсім іншого проєкту, який лежить у тій самій базі знань.

Технічно «джерела є». Семантично — їх немає.

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

придатні = чанки, які одночасно:
            - мають релевантність ≥ порогу (наприклад 0.35)
            - читабельні (частка друкованих ≥ 70 %)
            - належать дозволеному корпусу (не "чужі папки")

якщо придатних 0:
   у промпт ідуть не сирі чанки, а явна нотатка:
   "релевантні локальні джерела не знайдено"

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

Урок 3. Відтворюваність — це знімок плюс версії, а не «ті самі дані»

Аналогія. Лікар робить висновок про пацієнта. Через місяць приходить аудит і просить повторити цей самий висновок. Що для цього потрібно? Не просто «ті самі аналізи». Потрібен той самий пацієнт, той самий бланк аналізів конкретного дня, той самий протокол інтерпретації, та сама редакція клінічного гайдлайна. Якщо за цей місяць гайдлайн оновили, а ми про це не знаємо, висновок може законно змінитися — і це не помилка, це інша версія правил.

Як це виглядає у системах ШІ. Користувач питає сьогодні — отримує одну відповідь. Питає те саме через тиждень — отримує іншу. Можливі причини:

• провайдер мовної моделі тихо оновив модель;
• системний промпт відредагували;
• у базу знань додали нові документи (або, навпаки, прибрали);
• хтось підправив правило перевірки готовності релізу;
• помінявся векторний індекс, і та сама фраза тепер шукається інакше.

Жодне з цих змін окремо не є помилкою. Але разом вони роблять відповідь невідтворюваною.

Що зберегти разом із відповіддю. Маленький «паспорт повтору» — перелік усіх версій і ідентифікаторів, від яких залежав результат:

паспорт_повтору = {
   знімок_корпусу:     "snap-2026-06-02-a1b2c3",   # стан бази знань на момент відповіді
   модель:             "qwen3:[email protected]",            # яка саме модель і її версія
   версія_промпта:     "v3",                       # яка редакція системного промпта
   версія_правил:      "1.12",                     # який набір правил діяв
   версії_формул:      { "SPFM": "1.0" },          # для детермінованих обчислень
   налаштування_пошуку:"hash:9f0e..."              # пороги, ваги, демоушени
}

Це не параноя. Це різниця між «експерт сказав» і «експертна система довела і може показати, як саме».

Урок 4. Впевненість — це не одне число, а маленький набір індикаторів

Аналогія. Уявіть приладову панель автомобіля. Якщо там була б одна-єдина лампочка «у машині щось не так», водій не знав би, що робити: долити масло, заправитися, перевірити гальма чи їхати на СТО. Тому панель показує окремі стрілки: пальне, температура, тиск масла, заряд акумулятора. Кожна стрілка має зрозумілу дію.

Як це виглядає у системах ШІ. Часто система каже: «впевненість відповіді 0.62». Що з цим робити користувачу? Він не знає — бо 0.62 може означати щонайменше п’ять різних речей:

• знайшли мало релевантних джерел,
• джерела старі і застаріли по суті,
• джерела суперечать одне одному,
• бракує обов’язкового доказу (наприклад, тестового звіту),
• докази є, але слабкі.

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

Корисніша форма — вектор з кількох компонентів. Замість одного числа — п’ять маленьких:

впевненість = {
   покриття:     0.84,   # скільки релевантних джерел знайдено
   свіжість:     0.40,   # наскільки джерела актуальні
   узгодженість: 0.55,   # чи не суперечать джерела одне одному
   повнота:      0.70,   # чи всі обов'язкові докази на місці
   якість:       0.65    # наскільки сильні самі докази
}

Тоді правило «відправити на людський перегляд» вмикається не від магічного числа, а від конкретного індикатора, що «просів». У сліді міркування одразу видно діагноз: «узгодженість 0.55 — джерело А суперечить джерелу Б по полю X». Це вже не «штучний інтелект каже, що щось не так», а конкретна задача для людини.

Ці чотири речі не з’являлися в історичних книжках, бо в епоху MYCIN і PROLOG не було ні мовних моделей, які генерують переконливий текст без джерел, ні корпусів на десятки тисяч PDF, ні жорстких аудиторських вимог до повторюваності. Сьогодні без них експертна система легко перетворюється на красивий, але непередбачуваний «оракул».

Висновок

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

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

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

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

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

У яких ваших доменах відповідь ШІ вже сьогодні має бути не просто зручною, а доказовою — з джерелами, правилами, версіями і відповідальним переглядом?

Які аналогії з прикладів цієї статті ви помітили у вашій професійній діяльності?

Чи стикалися ви з ситуацією, коли система знайшла «релевантні» джерела, відповіла впевнено, а потім виявилося, що чанки були сміттєві, конфліктні або застарілі — і як ви це побачили (або не побачили)?

Якщо у вас є ШІ-асистент, який допомагає приймати рішення, спробуйте відтворити одну і ту саму відповідь через тиждень: чи отримаєте ви той самий висновок, з тими самими джерелами і тим самим обґрунтуванням? Що в такій ситуації корисніше показати: одне число впевненості чи вектор з компонентів (покриття, свіжість, узгодженість, повнота)?

Наступна стаття вступної серії про експертні системи — Експертна система, доказова рекомендація ШІ і корпоративна пам’ять: три кути одного трикутника