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

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

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

Перші дві статті вступної серії дали загальну рамку: чому експертні системи знов потрібні в R&D (Research and Development, дослідження й розробка) і як виглядає управління на основі доказів. Ця, третя стаття, закриває вступний цикл — дає робочі визначення трьох понять, які постійно плутають в інженерних дискусіях навколо штучного інтелекту (ШІ):

• Експертна система — що це насправді є і чим вона не є.
• Рекомендація ШІ як доказ — за яких умов вона перестає бути «ШІ так сказав» і стає допустимим кандидатом на доказовий артефакт.
• Корпоративна пам’ять R&D — те, без чого перші дві теми залишаються академічними.

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

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

Експертна система не дорівнює чатбот

Після кількох років хайпу навколо великих мовних моделей (Large Language Models, LLM) багато команд опинилися у схожій ситуації: чат із ШІ під’єднано до документації, відповіді звучать переконливо, але довіри для інженерних рішень не виникло. Демо (спершу) вражає, презентації проходять, а на практиці інженери далі перевіряють усе вручну і повертаються до реальних систем щоразу, коли потрібен доказ.

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

Що вміє LLM і де він корисний

Сила LLM — у роботі з мовою (це ж Language Model все ж). Вони зводять різнорідні документи до підсумків, пояснюють складне простіше або глибше залежно від аудиторії, готують чернетки (звіти про стан, релізні нотатки, вимоги, описи ризиків), виявляють двозначності, шукають за смисловою подібністю, перекладають між доменами і ролями. У проєктному середовищі це справді економить час. Перевірено автором неодноразово.

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

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

Що таке експертна система

Експертна система — інший клас інструментів. Її компоненти стандартні і їх варто проговорити окремо.

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

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

Чому інженерні рішення потребують доказів

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

Чатбот дає відповідь у тому ж форматі, у якому отримав запит. Експертна система показує ланцюжок міркування, конкретні правила, факти й обмеження. Тому чатбот — це інтерфейс, а експертна система — підтримка рішень, навіть із нескладним інтерфейсом. Хоча створення GUI для доказів ще той челендж!

Гібридний підхід як найреалістичніший

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

Доменні знання «живуть» на різних рівнях, наприклад, але не виключно, на таких:

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

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

Власники знань і життєвий цикл знань

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

Як виміряти якість експертної системи

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

Рекомендація ШІ: коли «ШІ так сказав» все ж може бути доказом

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

Я зіткнувся з цим під час розробки прототипу складного драйвера пристрою (complex device driver, CDD). Проект мав понад триста програмних вимог (software requirement, SWR), переважно функціональних, і перевірка відповідності коду велася вручну та затягувалася: одні розробники вважали, що все реалізували, інші довго не відповідали. На цьому фоні ШІ видав акуратну рекомендацію «ризик релізу прийнятний», і частина команди була готова прийняти її як підставу. Але на питання «які саме провалені тести, відкриті дефекти, винятки і які SWR підтверджені реалізацією» вичерпної відповіді не було — усіх доказів не вистачало. Команда сприйняла висновок як «м’який» доказ; як проєктний менеджер я побачив чіткішу картину стану справ. Я теж прихильник професійного скепсису.

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

Що вважається доказом в інженерії

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

• джерело (source) — звідки походить, який інструмент, яка людина, який процес;
• версія (version) — до якої версії продукту, документа або baseline він належить;
• власник (owner) — хто відповідає за цей доказ і за його актуальність;
• контекст (context) — за яких умов він був отриманий, які припущення, які обмеження;
• затвердження (approval) — хто і коли підтвердив його придатність для конкретного рішення.

Результат тесту, запис рев’ю коду, сертифікат кваліфікації постачальника, таблиця FMEA (Failure Mode and Effects Analysis, аналіз видів і наслідків відмов), аналіз небезпек, затверджена вимога, знімок базової версії — усе це докази. Текст від ШІ без цих атрибутів може бути інтерпретацією доказів, але не їх заміною. Саме ці атрибути дозволяють через роки відтворити, на якій підставі прийняли рішення, що впливало на безпеку, кібербезпеку чи контрактні зобов’язання.

Коли відповідь ШІ стає допустимим кандидатом на доказ

Відповідь ШІ не приречена лишатися «просто думкою». Вона стає допустимим кандидатом на доказовий артефакт, коли супроводжується чотирма речами:

• Джерела — посилання на конкретні артефакти (REQ-1234, TST-5678, RSK-091, baseline B-2026.04, CR-77), а не на «галузеві стандарти» загалом.
• Версії — прив’язка до конкретної версії продукту, baseline і стандарту; зміна версії автоматично робить стару рекомендацію ШІ застарілою.
• Припущення — усі неявні припущення винесені у явний список.
• Рівень упевненості — чесний рівень упевненості і опис того, що його знижує.

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

Принцип простий: ШІ радить, але не затверджує. Хоча правильно оформлена рекомендація може бути цитованим джерелом у журналі аудиту.

Дисципліна запиту до моделі на прикладі відповідності коду

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

Ти виконуєш попередній аналіз відповідності коду для перегляду safety/cybersecurity.

Контекст:
- Вимога: REQ-SAFE-017, точний текст: "..."
- Правила кодування: CS-C-012, CS-C-019, точний текст правил: "..."
- Стандартний контекст: ISO 26262-6 (software unit), ISO/SAE 21434 (cybersecurity).
- Базова версія: B-2026.04
- Артефакт коду: src/speed_monitor.c, commit abc123

Завдання:
1. Переформулюй вимогу у перевірювані твердження.
2. Перевір код тільки проти наданих вимог, правил кодування і стандартного контексту.
3. Для кожного дефекту наведи: ID вимоги, правило кодування, стандартний контекст,
   фрагмент коду, чому це дефект, вплив, рівень упевненості (high/medium/low),
   припущення, відсутню інформацію, приклад коректного коду.
4. Якщо доказів недостатньо, не вигадуй дефект. Познач як "потребує перегляду людиною".
5. Не посилайся на стандарти загальними словами. Пояснюй конкретне інженерне очікування.

Тут важливий не стиль, а дисципліна: ШІ працює не як оракул, а як рецензент, що показує ланцюжок доказів. Не варто просити «перевірити на ISO 26262» — стандарт не є статичним аналізатором коду. Краще давати конкретні очікування: safety-вимога має мати трасовану реалізацію і верифікаційні тести; safety-related код — уникати невизначеної поведінки, неініціалізованих значень і виходу за межі масиву; зовнішній вхід — проходити перевірку до копіювання в пам’ять; security-sensitive дія — мати явну перевірку авторизації.

Стабільний формат відповіді

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

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

Журнал аудиту і перевірюваність

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

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

Корпоративна пам’ять R&D: те, що з’єднує перші два кути

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

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

Де живе знання R&D

Знання в R&D розподілені: у коді — технічні рішення й обхідні шляхи; у задачах — дефекти, першопричини, логіка тріажу; у merge requests — компроміси реалізації; у wiki — пояснення архітектури й адаптація новачків; у системах вимог — формальний намір; у звітах тестування — факти верифікації; у релізних нотатках — прийняті обмеження; у презентаціях — рішення, які більше ніде не повторюються; у головах людей — неявний контекст.

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

Чому пошук не розв’язує проблему

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

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

Адаптація як тест пам’яті

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

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

Активні вивчені уроки

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

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

ШІ + граф знань + експертна система

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

Виглядає це так: інженер відкриває дефект, AI-помічник знаходить схожі випадки в минулих проєктах — пов’язані компоненти, першопричини, виправлення, тести — і пояснює, чому схоже: той самий інтерфейс, той самий компонент постачальника, пов’язана група вимог. Далі правила експертної системи підказують: якщо дефект на шляху, пов’язаному з безпекою, треба перевірити зачеплені вимоги і докази верифікації. Для проєктного менеджера (PM) це схожі затримки, для QA (Quality Assurance, забезпечення якості) — провали тестування, для архітектора — відхилені альтернативи, для кібербезпеки — історичні шаблони вразливостей.

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

Власник знань і центр експертизи

Корпоративна пам’ять не з’явиться сама. Хтось має визначати, які джерела авторитетні, як позначати застаріле, хто веде таксономію, як уроки переходять у повторно використовуване знання, які правила доступу діють. Це може бути власник знань, PMO (Project Management Office, проєктний офіс), функція якості або Center of Excellence (центр експертизи) — назва менш важлива за відповідальність. Без власника база старіє: документи додаються, але не оновлюються; уроки накопичуються, але не застосовуються; ШІ індексує все підряд і підсилює старий шум.

Короткий місток до Knowledge Management

Тут доречно згадати класичні праці з Knowledge Management — без перетворення розмови на бібліографію. Модель SECI (Socialization, Externalization, Combination, Internalization) японських теоретиків менеджменту Ікуджіро Нонаки й Хіротаки Такеучі, які намагалися зрозуміти, чому японські компанії 1980-х стабільно перетворювали досвід інженерів на нові продукти, описує перехід між неявним і явним знанням: людина знає більше, ніж записує, і організація втрачає це без способу витягнути, оформити і повернути знання в практику. Томас Девенпорт і Лоренс Прусак, консультанти, які одними з перших спробували описати управління знаннями як бізнес-дисципліну, у Working Knowledge наголошували, що знання — це досвід, контекст і здатність діяти, а не просто дані. Етьєн Венґер, дослідник навчання, який разом із Джин Лейв вивчав, як люди реально вчаться на практиці, через communities of practice показав, що знання живе у спільнотах практиків. А Пітер Сенге з MIT у темі learning organization доводив, що організація має вчитися системно, а не лише після аварій.

Для експертної системи це не декор, а нагадування: база знань не дорівнює сховищу файлів. Неявне знання експертів треба переводити в правила, приклади, винятки й межі застосування; явне — регулярно перевіряти, застаріле позначати, корисне повертати в роботу. Саме тут класичний Knowledge Management зустрічається з ШІ: модель витягає й пояснює, граф тримає зв’язки, експертна система застосовує правила, а людина лишається власником змісту.

Чутливість і межі знань

Знання R&D часто конфіденційні: код, звіти постачальників, аналіз вразливостей, вимоги замовника, ще не опубліковані плани продукту. Система пам’яті має поважати межі доступу — те, що знання існує, не означає, що його мають бачити всі. Це критично для ШІ і векторних індексів: якщо чутливий документ проіндексовано без контролів, витік стається не через початковий файл, а через витягнутий контекст або резюме. Тому класифікація, редагування чутливих місць, керування доступом і журнали аудиту — частина архітектури пам’яті, а не додаток. Трохи більше це розглянемо в наступних публікаціях.

Як виміряти корпоративну пам’ять

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

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

Що ми, власне, зробили цими трьома статтями

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

Друга стаття задала умову, за якої відповідь ШІ стає допустимим кандидатом на доказ: конкретні джерела з ідентифікаторами, версії, явні припущення, чесний рівень упевненості, трасований ланцюжок міркування і фінальне людське затвердження — на прикладі перевірки відповідності коду понад триста SWR.

Третя стаття показала, чому без корпоративної пам’яті перші дві не тримаються: знання в R&D губляться не від браку документів, а від браку зв’язків між кодом, вимогами, тестами, дефектами, рішеннями і уроками, тож щоб ШІ робив цю пам’ять корисною, потрібні граф зв’язків, метадані, межі доступу і власник знань.

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

Куди рухається серія далі

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

• Прикладна математика — логіка і правила, робота з невизначеністю, ймовірнісне міркування, графи, планування, пошук і калібрування впевненості.
• Інструменти — рушії правил, графи знань, перевірка обмежень, моделі пошуку, обробка документів, локальні й хмарні моделі, механізми пояснення.
• Архітектура — як дані, правила, пошук, LLM, журнал аудиту, права доступу і життєвий цикл знань поєднуються в одну систему.
• Збирання знань (knowledge acquisition) — як знання потрапляють у систему, хто їх перевіряє, як вони оновлюються і як вимірюється покриття.

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

• Чи траплялося вам, що відповідь ШІ звучала переконливо, але під нею не було джерел, на які можна твердо послатися в рішенні?
• Де у ваших проєктах відповідь без посилань на артефакти вже точно не пройшла б? а де її поки що приймають мовчки?
• Як часто відповідь на питання вже існувала в минулому проєкті, але її не вдавалося швидко знайти?
• Що болючіше для вашої команди: розрив між чатом і реальними даними, відсутність зв’язків між документами чи залежність знань від конкретних людей?
• Скільки часу новому інженеру потрібно, щоб зрозуміти ключові рішення у вашому продукті, і від чого це залежить?

Подяка читачам

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

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