Як саме Palantir будує онтології в організаціях? Які інструменти та формалізми використовує?

Стаття у вас як завжди якісна та корисна. Але мені здається що саме в цій статті ви відразу навантажуєте на читача багато технічний деталей на пояснивши йому базові елементи архітектури експертних систем.
ІМХО, краще було б почати з опису для читачів загальної канонічної верхньорівневої архітектури експертних систем = база знань + машина виводу (солвер) + робоча пам’ять + інтерфейси (користувача та інженера зі знань)
А вже потім переходити на рівень нижче до архітектури кожного з її компонентів.
Бази знань. Які вони бувають відповідно до методів представлення знань (онтології, ембедінги, семантичні мережі, фреймові моделі, продукційні моделі і таке інше. А також їхні комбінації)
Джерела знань та їх типи. Методи отримання знань відповідно до типу джерела.
Робоча пам’ять з фактами. Яка вона буває.
Машини виводу. Які вони бувають відповідно до методу представлення знань типу виводу (детермінований, імовірнісний, нечіткий (fuzzy)).

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

Чи має право на «життя» змішана концепція? Наприклад, в домені існують стандарти (в моєму випадку — в Automotive їх чимало є). Якщо факту нема в БД і він явно заперечується стандартом (compliance failure), він вважатиметься хибним. Інакше, якщо факт проходить повз стандарти, то він невідомий з інженерної точки зору.

Так, це називається Partial Closed World Assumption (PCWA).
БЗ в цілому трактується як відкрита (OWA), але дозволяє явно позначати окремі свої частини як закриті через completeness assertions (твердження про повноту).

Якщо дозволити таксономії розростатися без централізованого контролю;

Можна зафіксувати верхній рівень (або декілька верхніх рівнів) таксономії, а нижні рівні дозволити розвивати\змінювати (як ідея )))

А які системи підтримують бітемпоральні графи знань?

Ваші статті — як бальзам ну душу )) Нарешті про хтось почав писати про це!
Трошки додам інформації, що б у читачів склалась більш повна картина.
Є декілька типів Баз Знань і у кожного типу свій набір інференсів.
1) Продукційна БЗ — IF-THEN правила
2) Фреймова БЗ — мережі фреймів, які об’єднюють слоти
3) Логічна БЗ (Prolog/Datalog) — базуються на логиці предикатів різних порядків
4) Семантичні графи без онтологій
5) Графи Знань побудовані на онтологіях
6) Векторні (ембедінгові) Бази Знань
7) Імовірності Базі Знань (наприклад Байесівські мережі)
8) Гібридні БЗ де поєднуються декілька підходів (наприклад граф та ембедінги)
В коментарях не буду описувати деталі, бо кожний тип БЗ вартує окремої статті.
І ще важливий момент. Існує дві концепції побудови Баз Знань
а) Open World Assumption (OWA) — якщо якого факту немає в БЗ, він вважається невідомим а не хибним
б) Closed World Assumption (CWA) — якщо якого факту немає в БЗ, він вважається хибним.
Яку концепцію обирати — залежить від специфіки вашої експертної системи (де і як вона буде застосовуватись).

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

Розділ «Висновки»
Я би додав ще два висновки:

1) Проблема калібрування залишається невирішеною
У кожному підході хтось має визначити якісь параметри суб’єктивно — коефіцієнти впевненості у MYCIN, функції належності нечіткої логіки, апріорні ймовірності Байєса, масові функції Демпстера-Шафера, ваги багатокритеріального аналізу, тощо. Всюди виникає та сама фундаментальна проблема — хтось призначає числа вручну, і жодного принципового способу перевірити їх коректність не існує. Методи еволюціонують, але ця проблема залишається. І це відкрита наскрізна проблема всієї дисципліни.

2) Організаційні умови важливіші за технічну архітектуру
Так, технічні аспекти доказової системи — важливі. Але навіть ідеально побудована система стає непрацюючою, якщо в організації немає людей, здатних верифікувати послідовність міркувань, підтримувати актуальність бази знань, оновлювати правила при зміні контексту (наприклад — регуляторки), нести відповідальність за фінальне рішення. Технічна доказовість без організаційної зрілості дає лише ілюзію контролю — документований слід хибного рішення. ІМХО, це є найважливішим уроком з історії провалів експертних систем.

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

Ще декілька думок до розділу «Доказовість як головна вимога»

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

Відповідальність при задокументованій помилці.
Що відбувається, коли система надала всі дев’ять елементів доказового пакету, але при цьому висновок виявився хибним? Хто несе відповідальність — співробітник, який прийняв рекомендацію? Команда, що написала правила? Організація, що розгорнула доказову систему? У автомобільній безпеці і медицині це не філософське питання! Воно має юридичні наслідки.

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

Простий тест для будь-якої системи ШІ
Ще варто додати питанні:
— Як система обробляє конфліктуючі докази?
— Чи може система показати Inference chain?
— Як калібрується впевненість системи?
— Що відбувається зі старими висновками при появі нових суперечливих даних?

Доказовість як головна вимога
Тут взагалі купа проблем на які варто звернути увагу
1) проблема evidence grounding gap
коли джерело формально є, але відповідь фактично не випливає з нього логічно.
2) типи «доказовості»
Є чотири рівні доказовочті:
Citation — є посилання на джерело
Grounding — відповідь текстово підтверджена джерелом
Entailment — відповідь логічно випливає зі змісту джерела
Verification — факт перевірений незалежним способом
Більшість RAG-систем зупиняється на рівні citation або grounding.
3) проблема конфліктуючих доказів
Що робити, коли два надійних джерела суперечать одне одному?
І це реальна ситуація в корпоративних системах — стара версія стандарту проти нової, різні інженерні рішення в різних документах, тощо.
Доказова система повинна знаходити такі конфлікти і передавати на перевірку.
4) проблема застарілих доказів
Часова валідність доказів. Якщо джерело правильне, але датоване два роки тому, а предмет змінився — доказ формально є, але він хибний. І це дуже критично, наприклад, регуляторних систем або R&D.
5) проблема провенансу
Звідки взявся факт? Хто і коли його вніс? Чи пройшов він валідацію?
І це не питання «є посилання чи ні?», а питання чи можемо ми довіряти data pipeline і data provenance. Приклад: AI-система може посилатися на документ, який був згенерований ттією ж самою AI-системою. Це створює циклічну «доказовість» без реального підтвердження.
6) проблема coverage gaps
Доказова система може бути абсолютно правильною у тому, що вона каже, але мовчати про те, чого вона не знає. Тобто якщо доказів нема — система повинна сказати «не знаю» або «недостатньо даних», а не формулювати вигадану відповідь з тими доказами, що є.
Це один із найнебезпечніших failure modes в enterprise AI — confident incompleteness.
7) доказовість рішення і доказовість процесу
Рішення може спиратися на правильні факти, але прийматися за неправильним алгоритмом. Тому доказові системи повинні зберігати не тільки «чим підкріплено відповідь», але і «як саме до неї прийшли», тобто inference chain.
8) проблема calibration confidence
Наскільки оцінка власної правоти доказової системи відповідає реальній точності.
Система може мати всі докази і правильний ланцюжок виводу, але впевненість у відповіді може не відповідати реальній надійності.
Calibration — це окрема проблема, яка вирішується не через наявність джерел, а через статистичну перевірку на корпусі прикладів.
9) проблема adversarial inputs
У корпоративних і regulated-системах можливі навмисні маніпуляції: підроблені документи, poisoned knowledge base, prompt injection. Доказова система повинна мати input validation і tamper detection, інакше «доказовість» можна підробити.

Міркування за схожими випадками: ми вже бачили таку історію?
1) Метрика схожості випадків
Хто визначає схожість? Тест-інженер бачить схожість у одному, Архітектор — у другому, а менеджер проєкту — у третьому. Вибір метрики схожості фіксує чиюсь точку зору і приховує решту. Не існує принципового способу вибрати «правильну» метрику схожості ((( Це завжди компроміс між ролями і контекстами.
2. Адаптація випадків
Цикл Міркування за схожими випадками (CBR) включає крок «переглянути» — тобто адаптувати знайдене рішення до нового випадку. І саме на цьому кроці потрібен реальний експерт («шкіряний мішок» ))). Рішення, що спрацювало для дефекту в одному контексті може бути непридатний для дуже схожого дефекту але в іншому контексті. Алгоритм знаходить схожість у поверхневих ознаках — але не розуміє, які зміни контексту роблять старе рішення непридатним, навіть коли випадки дуже схожі за формальними ознаками.
3. Деградація бази випадків
Крок «зберегти випадок» виглядає як безкоштовне накопичення досвіду. Але база випадків з часом засмічується — застарілими рішеннями, які були правильні у старому контексті, але хибні тепер, дубльованими випадками, неякісно задокументованими випадками, де результат записаний, але причина — ні. І що більша база випадків — то сильніше ця проблема впливають на якість пошуку. Підтримка актуальності бази випадків — це окрема постійна задача яку в реальному житті мало хто хоче виконувати (((

Пошук: від TF-IDF до векторних представлень
З цим всім згоден бо про це і так написано купу статей, в тому числі і на DOU.
Єдине що впало на око «...Пізніше з’явилися TF-IDF, BM25, повнотекстовий пошук..»
Повнотекстовий пошук з’явився значно раніше векторного (десь ще у 1960-х)
Векторний пошук і TF-IDF з’явились майже одночасно. Якщо не помиляюсь десь у 1975.
BM25 — так, він з’явився значно пізніше. Років так на 20 після векторного і TF-IDF.

Байєсівські мережі: причинні графи ймовірностей
1. модель треба будувати
Так, погоджуюсь. Структура байесовської мережі — це причинні припущення. Хто вирішує, яке ребро куди спрямоване? Якщо провалений тест вказує на дефект — чи дефект є причиною падіння тесту, чи обидва є наслідком поганої вимоги? Два експерти можуть намалювати структурно різні мережі для одного домену — і обидві будуть сумісні з даними, але давати різні висновки при одному запиті. Вибір структури мережі — це непроста задача. І нажаль вона дуже суб’єктивна. Якщо структура неправильна — всі подальші обчислення математично коректні, але предметно хибні.
2. Scaling
Знов цій клятий scaling! Формула виглядає компактно: P(Xi | Parents(Xi)). Але для кожного вузла треба заповнити таблицю умовних ймовірностей. Вузол з чотирма батьківськими вузлами, кожен з двома станами — це вже 16 окремих ймовірностей тільки для одного вузла. У реальній мережі з десятками вузлів кількість параметрів, які треба оцінити вручну або навчити з даних, стає практично некерованою. Це та сама проблема, що і у всіх попередніх розділах.
Обчислення ймовірностей у загальному випадку байєсівської мережі є NP-складним завданням — тобто при зростанні кількості вузлів час обчислення зростає експоненційно. На практиці для великих мереж використовують наближені методи виводу — варіаційний вивід, методи Монте-Карло на основі ланцюгів Маркова (Markov Chain Monte Carlo), алгоритм поширення впевненості (belief propagation). Кожен із цих методів дає різну точність і різні гарантії збіжності. Тобто є обчислювальна стіна, яка стоїть між формулою і її реальним застосуванням.
3. Неперервні ймовірності
Якщо стани вузлів не дискретні а неперервні — всі проблеми ще більше погіршуються. Бо замість матриць (таблиць умовних ймовірностей) ми маємо використовувати копули. А як ефективно обчислювати копули — толком ніхто не знає. Найпростіший підхід — дискретизація неперервних ймовірності і зведення їх до дискретних (тобто до таблиць)
4. Заборона циклів
Байєсівська мережа — це орієнтований ациклічний граф (directed acyclic graph або DAG) і цикли в ньому заборонені! Чому? Це треба спитати у Перла, який перший запровадив Байесівські мережі. Бо він не зміг побудувати красивий і строгий математичний апарат для циклічних графів.
Але в реальних процесах ми постійно бачимо такі цикли — це позитивні або негативні зворотні зв’язки. Технічний борг уповільнює тести — погані тести пропускають дефекти — дефекти накопичують технічний борг. Стрес у команді знижує якість вимог — погані вимоги множать дефекти — дефекти підвищують стрес команди. Нажаль зворотні зв’язки не можна представити у стандартній байєсівській мережі без штучного розгортання у часі. Для моделювання зворотних зв’язків (і для динамічних процесів взагалі) використовують динамічні байєсівські мережі (Dynamic Bayesian Networks, DBN) — але це тема для окремої великої статті.
Ця проблема — найгірша для мене, бо система, яку я намагаюсь побудувати вимагає циклів (((

Є вільний час. Продовжу розбирати статтю.

Графи знань: від семантичних мереж до графів знань
1. Онтології для графів знань та семантична неоднозначність
«Вимога R-17 перевіряється_тестом T-9» — нібито виглядає просто, об’єкт-предикат-суб’єкт. Але хтось має вирішити: що саме означає це відношення? Чи означає воно «повністю верифіковано» чи «частково покрито»? Чи може одна вимога перевірятися кількома тестами? Чи може один тест покривати кілька вимог? Це визначається в онтології — схеми понять, відношень і обмежень. Розробка онтології вимагає участі одночасно доменних експертів і онтологічних інженерів, і різні команди будуть сперечатися про кожне таке відношення. Це таж сама проблема набуття знань, що і в продукційних правилах, тільки прихована у визначенні типів об’єктів, типів суб’єктів та типів ребер графа.
Прості трійки як в прикладі виглядають однозначно. При сотнях типів відношень у реальній системі різні команди починають використовувати різні назви для одного відношення, або одну назву для різних відношень. «Залежить_від», «пов’язаний_з», «впливає_на» — чим вони семантично розрізняються? Узгодження семантики між відділами, проєктами і системами — задача вирівнювання онтологій (ontology alignment). І вирішити її у великих організаціяї доволі складно. А без вирішення цієї проблеми різні підрозділи будуть будувати графи, які потім неможливо об’єднати для спільного запиту.
2. Оновлення графа знань
Граф починає старіє щойно його побудували. Граф треба постіно синхронізувати з усіма його джерелами. Якщо тест T-9 перейшов зі статусу «впав» у статус «пройшов» але граф не оновився — ланцюг доказів стає джерелом хибних висновків. Операційна підтримка актуальності графа це досить складна задача. ІМХО, складніша за початкову побудову.
Трійка «Тест T-9 впав_на_базовій_версії B-3» не несе інформації про час: коли впав? чи вже це виправлено? Стандартні графи знань на основі RDF та OWL нажаль не мають вбудованого механізму представлення часових відношень. Тоді доводиться або ускладнювати схему (додавати вузли-події з часовими мітками), або миритися з тим, що граф описує лише поточний знімок без історії. Наприклад, для аудиторських сценаріїв відсутність часової осі — це критична прогалина.

Дуже цікава стаття! Решту її розділів розберу пізніше бо зараз немає часу ))

Демпстер-Шафер: докази без повної впевненості
1) Нормалізація приховує конфлікт
Ви пишете «Вона має показати конфлікт». Але стандартне правило Демпстера робить рівно протилежне — ділення на (1 — K) нормалізує результат до суми 1, математично прибираючи конфлікт із фінального розподілу. Чим більший конфлікт — тим сильніша нормалізація — тим менш помітний конфлікт у виході. Але може бути що я просто невірно зрозумів що ви мали на увазі під «Вона має показати конфлікт».
2) Парадокс Заде
Уявіть, що два медичні експерти оцінюють пацієнта з трьома можливими діагнозами (Захворювання: A, B, C): Експерт 1 вважає, що у пацієнта хвороба A з ймовірністю 0.99, хвороба B з ймовірністю 0.01, а хвороба C — неможлива (0.00). Експерт 2 вважає що у пацієнта хвороба B з ймовірністю 0.01, хвороба C з ймовірністю 0.99, а хвороба A — неможлива (0.00). Експерти сходяться лише в крихітній оцінці хвороби B (0.01) і категорично розходяться у всьому іншому (високий рівень конфлікту). При комбінації їхгіх думок за допомогою алгоритму Демпстера-Шафера відбудеться наступне: Система повністю виключить можливість хвороб A і C, так як один з експертів дав їм оцінку 0. Єдиним перетином думок стане хвороба B з ймовірністю 100% (достовірно). Алгоритм теорії свідчень взяв найменший збіг і екстраполював його в абсолютну впевненість!
Цей парадокс, сформульований Лотфі Заде у 1979 році, стримує промислове застосування теорії досі.
3) Комбінаторний вибух
Таж сама проблема що вже була декілька разів описана вище. Scaling, scaling, scaling... І що ж ним робити? ((( (в мене немає відповіді)
Теорія працює над множиною всіх можливих гіпотез (frame of discernment). Для N гіпотез існує 2^N — 1 підмножин, кожна з яких може мати свою масу. При N = 10 це вже 1023 елементи для зберігання і комбінування. При N = 20 — понад мільйон. У реальних задачах, де гіпотез багато, обчислювальна складність зростає експоненційно. Саме тому теорія добре працює у вузьких задачах з двома-трьома гіпотезами і погано масштабується.
4). Проблема калібрування
Звідки беруться масові функції ? Хто призначає m1(B) = 0.4 і m2© = 0.3? Так само як CF у MYCIN і функції належності у нечіткій логіці, масові функції визначаються вручну через опитування експертів. Жодного принципового способу перевірити їх коректність не існує. Різні експерти дадуть різні значення для одного джерела доказів. Без вирішення цієї проблеми математично красива формула комбінування будується на суб’єктивному фундаменті.

Нечітка логіка: коли світ не чорний і не білий
1) що робити з нечітким виходом
Ми отримали результат 0,60. ОК! але що робити з цим числом далі? Цей нечіткий вихід треба перетворити на конкретну дію — «блокувати реліз», «вимагати перегляд», «дозволити», тощо. Це фінальний етап системах нечіткої логіки (Fuzzy Logic) — отримання чіткої дії після логічних висновків Він називається «дефаззифікація» і для нього існує кілька конкуруючих методів — центроїд, максимум, зважене середнє. Різні методи дають різні результати для одного й того самого нечіткого входу. Можливо варто було про це розповісти.
2) Вибух правил
У прикладі три критерії. У реальній системі підтримки рішень їх може бути десять-п’ятнадцять-двадцять. І кожен з кількома нечіткими множинами. Кількість правил зростає експоненційно. Саме через це нечітка логіка добре масштабується у вузьких задачах керування (наприклад — термостатом), але погано у широких задачах підтримки рішень.
3) Плутанина між розмитістю і невизначеністю
Нечітка логіка створювалася для розмитості — ситуацій, де поняття саме по собі не має чіткої межі: «висока температура», «майже готовий реліз». Це не те саме, що невизначеність — ситуація, коли межа є чіткою, але у нас бракує інформації. Тест або пройдений або ні. gotovnist_pokryttya_testamy = 0.84 — це не розмитість, це невизначеність. У стаття трошки змішуються ці два типи. Приклад з релізною готовністю 0.60 — це скоріш невизначеність ніж розмитість. І для цього випадку нечітка логіка не дуже підходить.

Коефіцієнти впевненості: інженерний компроміс MYCIN
1) Формула CF1 + CF2 * (1 — CF1)
Ця формула не виводиться з теорії ймовірностей чи будь-якої іншої формальної системи. Вона була придумана як інженерно зручна. Шортліфф пізніше сам визнав її теоретичну необґрунтованість. Вона може давати парадоксальні результати — наприклад, якщо один і той самий доказ врахувати двічі, впевненість зросте, хоча нової інформації не додалося.
2) Накопичення похибок при ланцюговому виведенні
Стаття показує комбінування двох доказів. Але у реальній експертній системі висновок одного правила стає вхідним фактом для наступного — і може бути багато таких кроків. CF знижується на кожному кроці. Система стає «невпевненою» в правильних висновках просто через довжину ланцюга виведення. Саме ця проблема обмежувала практичну глибину міркування MYCIN.