Експертні системи для R&D: від корпоративного хаосу до керованих знань

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

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

Для software-інженера це може бути питання: «чому цей модуль зроблений саме так?». Для QA: «які регресії вже були в цій зоні?». Для hardware-інженера: «які обмеження має цей компонент?». Для проєктного менеджера: «де ризики по залежностях?». Для продуктового менеджера: «які технічні рішення впливають на roadmap?». Усі ці питання насправді про одне: як компанія накопичує, структурує і повторно використовує знання.

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

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

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

Її роль у корпоративній ІТ-архітектурі — бути шаром інтелектуальної інтерпретації над уже наявними системами: GitLab або GitHub, Jira, Polarion, Confluence, системами управління вимогами, тест-менеджментом, CAD/EDA-інструментами, PLM-системами, документними сховищами та внутрішніми порталами.

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

Що таке доменні знання

Для людини доменні знання виглядають як досвід: «цей драйвер завжди ламається після зміни таймінгів», «цей клієнт дуже чутливий до latency», «цю вимогу не можна змінювати без safety review», «ось тут уже був схожий дефект два роки тому».

Для машини ці знання мають бути представлені інакше: як сутності, зв’язки, атрибути, документи, події, версії, джерела та правила. Наприклад:

• вимога пов’язана з дизайном, кодом, тестом і дефектом;
• архітектурне рішення має автора, дату, обґрунтування і наслідки;
• баг має симптом, причину, affected versions і regression tests;
• зміна в hardware може впливати на firmware, тести, документацію і план релізу;
• стандарт на кшталт ISO 26262 або Automotive SPICE має вимоги до артефактів, простежуваності й доказової бази.

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

Чим сучасна експертна система відрізняється від звичайного AI-сервісу

AI-сервіси загального призначення, включно з Claude-, ChatGPT- чи Gemini-подібними продуктами, дуже корисні для генерації тексту, пояснень, прототипів і швидкого аналізу. Але вони не є корпоративною експертною системою самі по собі.

Експертна система має бути локалізованою і спеціалізованою: працювати з конкретним доменом, конкретними процесами, конкретними джерелами даних і конкретними правилами доступу. Для компаній, які займаються новими розробками, ноу-хау, embedded-системами, automotive, semiconductor, defense або медичними продуктами, це критично. Не все можна відправити в зовнішній AI-сервіс, навіть якщо він дуже якісний.

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

Але головне не в тому, що «там є AI». Головне в тому, що система працює з корпоративним контекстом, перевіреними джерелами, правами доступу, доменними правилами і простежуваністю зв’язків між артефактами.

Що це дає різним ролям

Для software-інженера експертна система може швидко пояснити історію модуля, знайти схожі зміни, показати пов’язані дефекти, архітектурні рішення, тести й обмеження. Це особливо корисно в legacy-проєктах, де код живе довше, ніж більшість членів команди.

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

Для hardware- або embedded-інженера така система може зв’язувати специфікації, register maps, errata, firmware-драйвери, board constraints, результати вимірювань і production issues. У складних HW/SW-продуктах саме на стику дисциплін часто губляться найважливіші знання.

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

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

Onboarding і knowledge transfer

Одна з найсильніших практичних переваг експертної системи — адаптація новачків. Новий інженер зазвичай отримує доступ до репозиторію, кількох wiki-сторінок, backlog і поради «питай у команди». Але команда зайнята, документація застаріла, а контекст розмазаний по роках історії.

Експертна система може дати новачку маршрут входження: ключові модулі, важливі рішення, типові помилки, поточні ризики, людей-експертів, основні документи, пов’язані дефекти, critical flows. Це скорочує час до продуктивності й зменшує навантаження на senior-інженерів.

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

Інтеграція з інженерними системами

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

• документні системи: ECN, MEMO, ADR, waiver, errata, change requests;
• статичні бази знань: Confluence, Markdown-документація, внутрішні портали;
• системи розробки: GitLab, GitHub, code review, CI/CD, artifact repositories;
• системи управління проєктами: Jira, YouTrack, Azure DevOps;
• системи вимог і тестування: Polarion, DOORS, TestRail;
• HW/SW-інструменти: EDA/CAD, симулятори, firmware SDK, board databases.

Інтегрована експертна система може відповідати на питання, які окремий інструмент не бачить: «який документ пояснює цю зміну в коді?», «який тест підтверджує цю вимогу?», «які таски пов’язані з цим hardware errata?», «які рішення були прийняті перед цим релізом?», «які ризики повторюються з проєкту в проєкт?».

Knowledge Acquisition System

Окрема важлива частина — система збору знань, або Knowledge Acquisition System. Вона потрібна тому, що корпоративні знання створюються хаотично: на робочих станціях розробників, у локальних нотатках, у коментарях до merge request, у внутрішніх wiki, у тасках, у чатах, у документах, у тестових артефактах, а іноді й на зовнішніх форумах чи в публічних репозиторіях на GitHub.

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

Хто володіє дисципліною знань

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

У різних організаціях це може бути по-різному: engineering operations, quality/process office, architecture board, systems engineering function, product governance або окремий owner корпоративної knowledge platform. Назва менш важлива, ніж мандат. Хтось має право сказати: ця вимога не має зв’язку з тестом; це архітектурне рішення не має обґрунтування; цей реліз не має достатньої доказової бази; цей post-mortem не перетворився на урок для майбутніх команд.

Граф знань настільки повний, наскільки інженери готові вкладати в нього час між закритою задачею і наступною. Тому наповнення не можна робити паралельною бюрократією. Воно має бути вшите в робочий процес: Definition of Done, pull/merge request templates, code review, тестові звіти, release gates, інцидент-менеджмент, onboarding, архітектурні рев’ю. І бажано так, щоб інженер одразу бачив віддачу: система швидше знаходить схожі дефекти, автоматично підтягує пов’язані рішення, допомагає написати release note, попереджає про відсутній тест або показує, хто вже працював із подібною проблемою.

Інакше експертна система ризикує стати ще однією базою, у яку щось заносять перед аудитом, а потім забувають. У такому випадку навіть графова база, embeddings і красива семантика стандартів перетворюються на архів останнього успішного compliance exercise, а не на живу пам’ять організації.

Експертна система як інструмент Center of Excellence

Окремо варто згадати Center of Excellence. У багатьох компаніях такі центри відповідають за стандарти розробки, архітектурні практики, якість процесів, повторне використання рішень, навчання команд і поширення експертизи між проєктами. Але на практиці їхній вплив часто обмежується документами, презентаціями, рев’ю за запитом і консультаціями кількох senior-експертів.

Експертна система може стати для Center of Excellence робочим інструментом, а не просто бібліотекою матеріалів. Вона дозволяє перетворити напрацьовані практики на живі правила, шаблони, перевірки, рекомендації й маршрути навчання. Наприклад, якщо команда починає новий модуль, система може підказати релевантні reference architectures, типові помилки, required reviews, приклади рішень з інших проєктів і людей, які мають потрібну експертизу.

Для Center of Excellence це також спосіб масштабувати вплив. Не кожен інженер піде читати довгий guideline або чекати на консультацію архітектора. Але якщо рекомендація з’являється в контексті конкретного merge request, тестового ризику, архітектурного рішення або релізного gate, вона стає частиною робочого процесу. Так експертна система допомагає перетворити «кращі практики» з пасивних документів на активну інженерну підтримку.

Переваги

Основні переваги сучасної експертної системи для R&D-компанії:

• швидший пошук відповідей і менше втрат часу;
• кращий onboarding нових людей;
• зменшення повторних помилок;
• збереження критичних знань при зміні команди;
• краща простежуваність між вимогами, кодом, тестами й рішеннями;
• підтримка аудитів і стандартів на кшталт Automotive SPICE, ISO 26262, ISO/SAE 21434;
• якісніший knowledge transfer між командами;
• краща видимість технічних і процесних ризиків;
• можливість локальної роботи з конфіденційними даними;
• чіткіший ownership за якість знань, рішень і розуміння їхніх наслідків;
• перетворення документації з пасивного архіву на активний інженерний інструмент.

Недоліки й ризики

Але є й обмеження. Експертна система не виникає магічно після підключення LLM до Confluence. Потрібні якісні джерела, дисципліна документування, модель доступу, інтеграції, підтримка онтології домену, правила валідації, відповідальні власники знань.

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

Також є ризик «AI-ілюзії»: система звучить переконливо, але не має достатньої доказової бази. Тому для інженерного застосування критично, щоб відповіді мали посилання на джерела, версії, обмеження й рівень впевненості. Для safety-critical або compliance-heavy доменів це не опція, а базова вимога.

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

Висновок

Сучасна експертна система для R&D — це не заміна інженерів і не черговий корпоративний чат-бот. Це інфраструктура роботи зі знаннями: локальна, спеціалізована, інтегрована з інженерними процесами, підсилена AI та здатна працювати з конфіденційним корпоративним контекстом.

Для software, hardware, QA, project і product-команд її цінність не в абстрактній «автоматизації», а в дуже практичних речах: швидше зрозуміти систему, не повторити стару помилку, знайти потрібне рішення, передати досвід новачкам, підготуватися до аудиту, побачити ризики раніше й приймати рішення на основі перевірених знань.

Мені цікаво, які сценарії були б найкориснішими саме у вашому досвіді. Де у ваших командах найчастіше губляться знання? Що найважче передати новачкам? Яких відповідей ви очікували б від справді корисної експертної системи? І які напрями розвитку таких систем здаються вам найбільш перспективними?