Експертна система — це дещо більше, ніж інформаційно-довідкова система

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

Серія статей: Експертні системи для R&D
Попередня стаття: Інфраструктура виконання експертної системи: моделі, апаратура і розміщення

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

Я дивлюся на цю тему не з академічної полиці. У моєму бекграунді були Linux-системи, Internet-провайдери, інформаційна безпека, системи електронної звітності, електронні документи, цифрові сертифікати, delivery management софтверних проектів, automotive firmware, ASPICE-орієнтовані процеси, safety/cybersecurity контекст, трасування вимог та й ще багато усяких цікавих речей що вимагали технічних доказів. Тому для мене «відповідь системи» майже ніколи не є просто текстом. У контрольованому інжинірингу відповідь людини або системи повинна мати джерело, версію, власника, слід і наслідок для рішення.

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

Довідка відповідає про корпус, експертиза — про конкретний випадок

Різниця, якщо коротко, така.

• Інформаційно-довідкова система відповідає на питання про корпус: «що написано про X?», «де сказано про Y?». Відповідь це знайдений або переказаний фрагмент. Навіть коли зверху працює мовна модель і добре переформульовує знайдене, у суті це лишається пошук плюс виклад: довідкова система повертає те, що вже є в джерелах.
• Експертна система відповідає на питання про конкретний випадок: «що з цього випливає?», «чи можна?», «що робити?». Відповідь це висновок, якого немає дослівно в жодному файлі, виведений правилами з фактів, із поясненням, яке правило на якому факті спрацювало.

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

Перевірка проста. Я ставлю системі питання і дивлюся на тип відповіді. Якщо це завжди «ось що кажуть джерела», це довідка. Якщо це може бути «вердикт C, якого не пише жодне джерело, виведений правилом R на фактах F1 і F2, ось слід», це вже експертна система.

Де тут відкриті онлайн LLM

Окремо про ChatGPT, Claude і Gemini. Їх часто називають то довідковими, то експертними, але сама по собі відкрита онлайн-модель не належить до жодного з цих двох класів. Вона взагалі не «система» в моїй рамці, а компонент.

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

Клас системи визначає не модель, а архітектура, у яку її вбудовано:

• LLM плюс пошук по контрольованому корпусу (RAG) дає інформаційно-довідкову систему: тепер вона відповідає про джерела проєкту й може на них послатися.
• LLM плюс база правил, машина виводу, робоча пам’ять, пояснення й перевірка знань дає рух у бік експертної системи, і то лише коли додано слід і походження.

Є окрема причина, чому онлайн-варіант складний для R&D: щоб отримати відповідь про конкретний випадок, треба відіслати сам випадок назовні, сторонньому оператору. Для конфіденційного інжинірингу це часто неприйнятно, тому в серії є окрема стаття про локальні моделі (стаття про локальні LLM). Онлайн-модель зручна як чернетковий генератор формулювань, але не як носій доказу й не як місце, куди можна класти чутливий контекст.

Мій висновок тут такий: відкрита онлайн LLM це не клас системи, а компонент; класом вона стає лише всередині довідкової або експертної архітектури, і навіть тоді доказовість додає не модель, а те, що навколо неї побудовано.

Що робить артефакт документом

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

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

Документ у повному сенсі додає ще кілька атрибутів:

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

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

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

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

Питання, яке легко проґавити: документ-довідка проти документа-експертного висновку

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

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

1. відтворює наявне джерело, не додаючи нового твердження;
2. істинність вимірюється вірністю оригіналу, а не виводом;
3. посилається на джерело, а не на ланцюг міркування;
4. не потребує заяви про впевненість, бо нічого не виводить;
5. відповідальність автора обмежена точністю переказу.

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

1. містить нове твердження, якого немає дослівно в жодному джерелі;
2. несе ланцюг міркування, а не лише результат;
3. прив’язує походження до кожної передумови (звідки взято факт, яка версія);
4. заявляє впевненість, припущення і межі застосовності;
5. має власника-людину, яка його затверджує і відповідає за нього.

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

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

Сходинки виходу: витяг, довідка, не-експертний і експертний висновок

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

• Витяг — дослівний фрагмент джерела, вирізаний без змін: «ось цей пункт стандарту». Жодного переказу, істинність дорівнює точності копіювання.
• Довідка — впорядкований переказ одного чи кількох джерел: зведена таблиця, конспект, добірка релевантних місць. Уже є обробка, але нового твердження про конкретний випадок ще немає, лише організоване відоме.
• Не-експертний висновок — судження, яке звучить як відповідь на поставлене питання, але без формального виводу, сліду й походження: думка, побіжна оцінка, згенерований моделлю абзац «схоже, все гаразд». Він навіть буває правильний, але його не можна перевірити, бо не показано, з чого він випливає. Саме сюди часто падають відповіді відкритої LLM.
• Експертний висновок — виведене судження про конкретний випадок зі слідом «факт → правило → висновок», походженням кожної передумови, заявленою впевненістю і власником, що відповідає. Єдиний щабель, де відповідь і нова, і перевірна одночасно.

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

Щоб межа експертності стала відчутнішою, візьму приклад із automotive-проєктів, де це щоденне питання: чи можна віддати реліз прошивки на наступну контрольну точку (у процесі її називають gate). Довідкова система тут знайде все дотичне: контрольний список релізу, звіт тестування, нотатки з кібербезпеки й функційної безпеки, перелік відкритих дефектів і сторінку з правилами затвердження.

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

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

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

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

Чому в експертної системи більше компонентів

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

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

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

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

Схема експертної системи ширша: у неї заходить не питання про корпус, а конкретний випадок, і між входом та виходом стоять машина виводу, робоча пам’ять, пояснення й контур самонавчання.

Порівняння двох схем і є відповідь у картинці: там, де в довідки один прямий конвеєр «знайти й переказати», в експертної системи стоїть контур виводу з окремою пам’яттю випадку, доказом і зворотним зв’язком.

Прибери машину виводу, робочу пам’ять і пояснення, і від експертної системи лишиться довідка. Саме ці компоненти довідкова архітектура не має, і саме про них решта серії.

Зведена таблиця: що присутнє в якій системі

Щоб не розсипати різницю по абзацах, зведу її в одну матрицю. Стовпці це чотири класи: простий пошук чи база даних, інформаційно-довідкова система (пошук плюс переказ, RAG), генеративна LLM сама по собі й повноцінна експертна система. Рядки це ті визначення, про які найчастіше сперечаються, плюс кілька додаткових характеристик, що добре розводять класи.

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

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

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

Підсистема самонавчання: та частина, яку я ще майже не чіпав

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

Підсистема самонавчання це не одна техніка, а кілька рівнів:

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

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

Коли рішення ухвалює сама експертна система

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

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

Підпис, довіра і юридична вага машинного висновку

Щойно висновки починає видавати експертна система, постає питання довіри до артефакта. Паперовий висновок засвідчують підпис і печатка експерта. Машинний висновок треба засвідчувати інакше: електронним підписом, слідом і політикою відповідальності.

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

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

Карта решти серії: як я веду матеріал від довідки до експертизи

Тепер, коли межу проведено, легко скласти маршрут. Кожен наступний розділ серії закриває одну конкретну нестачу, яка відділяє довідку від експертної системи.

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

Висновок

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

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

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

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

• Згадайте останній «висновок», який ви передали далі: це справді був виведений вердикт зі слідом чи гарно переказана довідка, яку прийняли за висновок?
• Яке питання у вашому проєкті звикли «шукати» в документах, хоча відповідь на нього щоразу доводиться виводити під конкретну ситуацію, а не знаходити готовою?
• Чи траплялося, що система після донавчання почала відповідати впевненіше, але пояснити свій висновок краще так і не змогла?
• Був у вас випадок, коли переконлива відповідь виявилася хибною саме тому, що ніхто не міг простежити, звідки вона взялася?
• Що у вашому процесі складання чи релізу вже блокує або пропускає рішення само, без людини, і чи лишається слід, коли воно помиляється?
• Чи бачили ви, як згенерований або підписаний звіт сприйняли за істину лише тому, що він мав офіційний вигляд, а не тому, що хтось перевірив факти?
• Де у вашій команді ChatGPT, Claude чи Gemini уже використовують як «експерта», і хто перший спіймав його на впевненій вигадці?