Представление знаний

НЕ ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Архитектору Аналитику Инженеру

Представление знаний (англ. Knowledge Representation, KR — представление знаний) — направление информатики и искусственного интеллекта, где знания о предметной области записывают в форме, удобной для программ: поиск, проверка условий, вывод новых фактов, согласование с данными.

Обычная база данных хранит строки и отвечает на запросы вроде SELECT … WHERE …. KR добавляет явный слой понятий, правил и связей между смыслами. Обзор — статья "Представление знаний" в Википедии. Соседние статьи — семантика, онтология, концептуальные схемы, семантический веб. Раздел Мыслительная база связывает KR с логикой, графами и системами.

Термины главы — в словаре.

Явная запись знаний

Эксперт по логистике формулирует правило словами:

Если заказ оплачен
   и склад подтвердил отгрузку
   и статус заказа — "собран",
то статус можно перевести в "отправлен".

Задача KR — записать это так, чтобы система могла:

проверить условие на конкретном заказе;
объяснить, почему статус изменился;
обнаружить противоречие с другими правилами.

Без явной записи такие знания остаются в головах, в тикетах и в разрозненных if по коду. KR даёт общий слой смысла поверх приложений — в медицине, финансах, техподдержке, корпоративных справочниках.

Аналогия

База данных — журнал фактов: "заказ 1042 оплачен 15.06.2026".

Представление знаний — устав склада: "оплаченный и собранный заказ можно отправлять".

Журнал без устава не подскажет, можно ли менять статус. Устав без журнала — пустая формальность.

История представления знаний

1950–1960-е — логика и первые программы

После работ Алана Тьюринга и Джона фон Неймана стало ясно: машины манипулируют символами. Исследователи пробовали кодировать рассуждения как логические формулы. Программа Logic Theorist (1956) искала доказательства теорем — ранний пример символьного ИИ.

1970-е — семантические сети и фреймы

Семантические сети (Quillian, 1960-е; развитие в 1970-х) представили понятия как узлы графа, а отношения — как подписанные рёбра.

Фреймы Марвина Минского (1975) описали типичные ситуации шаблонами со слотами — прообраз объектных моделей в коде.

1980-е — экспертные системы

Экспертные системы (expert systems) — программы, имитирующие рассуждения специалиста в узкой области:

Система	Область	Идея
MYCIN	диагностика инфекций	цепочки правил IF-THEN
XCON (R1)	конфигурация DEC	подбор комплектующих
DENDRAL	химический анализ	гипотезы по спектрам

Успех в узком домене с чёткими правилами. Провал при попытке охватить "весь мир" без структуры понятий.

1990-е — онтологии и веб

Стандартизация онтологий для повторного использования понятий. Появление XML, затем RDF (Resource Description Framework) — основа семантического веба.

2000-е — Linked Data и графы знаний

Википедия, DBpedia, Wikidata — открытые графы фактов. Google Knowledge Graph — коммерческое применение.

2010-е — сегодня

корпоративные каталоги данных (data catalog);
графы знаний для поиска и RAG (Retrieval-Augmented Generation — дополнение ответов LLM извлечённым контекстом);
отраслевые онтологии (SNOMED CT, FIBO);
гибриды нейросетей и символьных правил.

Нейросети хорошо угадывают по тексту; для аудита, регуляторики и стыковки legacy-систем по-прежнему нужны явные модели — см. семантику.

Карта формализмов

Формализм	Суть	Близкий аналог в IT
Семантическая сеть	узлы — понятия, дуги — именованные отношения	граф с подписями на рёбрах
Фрейм	шаблон сущности со слотами (полями)	класс или структура с полями
Правила	цепочки "если … то …"	бизнес-правила, движки вроде Drools
Логика	формулы с кванторами "для всех", "существует"	ограничения, языки вроде Prolog
Онтология	классы, свойства, иерархии, аксиомы	статья Онтология в информатике
Таблицы решений	матрица условий и результатов	spreadsheet, DMN

Формализмы сочетаются. Онтология задаёт типы узлов и рёбер, правила — поведение, таблица или граф — конкретные факты (экземпляры).

Семантические сети

Семантическая сеть — граф, в котором:

вершины — понятия ("Кошка", "Млекопитающее") или конкретные объекты ("кот Том");
рёбра — типы связей с подписью.

Типы связей

Связь	Обозначение	Смысл	Пример
это вид	is-a	наследование свойств	Кошка → Млекопитающее
часть целого	part-of	состав	Колесо → Автомобиль
экземпляр класса	instance-of	объект относится к типу	Том → Кошка
атрибут	has-attribute	свойство со значением	Том → цвет: рыжий
ассоциация	related-to	слабая связь	Алиса → знает → Боб

Путаница между "Москва как класс всех городов" и "Москва как один город" — частая ошибка моделирования. См. ООП (класс и объект в коде) и онтологию.

Наследование свойств

Млекопитающее имеет свойство "дышит лёгкими"
Кошка — это вид Млекопитающего
→ вывод: Кошка дышит лёгкими (если правило наследования разрешено)

Такой вывод (inference) — отличие KR от простого хранения фактов.

Запросы к семантической сети

На псевдокоде:

найти все X, где
  (Том, instance-of, X)
  И существует Y: (X, это вид, Y)

ответ: X = Кошка, Y = Млекопитающее

В графовых СУБД похожие обходы делают языком вроде Cypher. В RDF — SPARQL.

Многослойные сети

Разделение типов, экземпляров и связей упрощает сопровождение. Та же идея — в концептуальных схемах.

Промышленные графы

Семантические сети лежат в основе графов знаний (Google Knowledge Graph, Wikidata) и рекомендательных систем. В структурах данных графы применяют для социальных и смысловых связей.

Фреймы

Фрейм (концепция Марвина Минского, 1970-е) — шаблон сущности: именованные слоты (поля) и значения, часто с наследованием от более общего фрейма.

ФРЕЙМ "Транспорт"
  слот "колёса"       тип: число
  слот "вместимость"  тип: число

ФРЕЙМ "Автомобиль" НАСЛЕДУЕТ "Транспорт"
  слот "колёса"           значение по умолчанию: 4
  слот "тип_двигателя"    допустимые: бензин | дизель | электро

экземпляр "машина_компании_12"
  класс: Автомобиль
  тип_двигателя: электро

Слоты и демоны

Минский описывал демонов (procedures attached to slots) — процедуры, срабатывающие при заполнении слота:

слот "страна" → при значении "Россия" подставить слот "валюта" = "RUB"

Современный аналог — вычисляемые поля, триггеры в БД, валидаторы в формах.

Фреймы и объекты в коде

Концепция фрейма	В ООП	В данных
фрейм-шаблон	класс	JSON Schema `object`
слот	поле	property
значение по умолчанию	default в конструкторе	`default` в схеме
наследование	extends	`allOf` в JSON Schema
экземпляр	object	документ JSON

Пример фрейма заказа

ФРЕЙМ "Заказ"
  слот order_id      тип: целое, обязательный
  слот status        допустимые: draft | paid | shipped
  слот lines         тип: список СтрокаЗаказа
  слот customer      тип: Покупатель

ФРЕЙМ "СтрокаЗаказа"
  слот sku           тип: строка
  слот qty           тип: целое, минимум 1
  слот unit_price_kopecks  тип: целое

Связь с семантикой: слот unit_price_kopecks явно фиксирует единицы.

Множественное наследование фреймов

Когда фрейм наследует два родителя, слоты могут конфликтовать:

ФРЕЙМ "Летающее"   слот "среда" = воздух
ФРЕЙМ "Плавающее"  слот "среда" = вода
ФРЕЙМ "Утка" НАСЛЕДУЕТ "Летающее", "Плавающее"

Стратегии разрешения:

приоритет по порядку наследования (как в Python MRO);
запрет множественного наследования (как в Java для классов);
явное переопределение в дочернем фрейме;
разделение ролей (миксины только для отдельных слотов).

Та же проблема встречается в ООП и в OWL-классах с несколькими родителями — онтология.

Фреймы в UI и формах

Конструктор форм в админке часто неосознанно повторяет фреймы:

шаблон полей для типа "Товар";
условное отображение слотов при выборе категории;
значения по умолчанию из справочника.

Явное описание фрейма в KR согласует фронтенд, бэкенд и отчёты — см. семантику про единые имена.

Продукционные правила

Продукционные правила (production rules) — формат "ЕСЛИ условия ТО действие":

ЕСЛИ   заказ.оплачен = да
   И   заказ.склад_подтвердил = да
   И   заказ.статус = "собран"
ТО     заказ.статус := "отправлен"

Структура правила

Часть	Роль
Условие (LHS)	left-hand side — что проверяем
Действие (RHS)	right-hand side — что делаем
Приоритет	порядок при нескольких срабатываниях
Салience	вес в движках вроде Drools

Цепочки вывода

Прямой вывод (forward chaining) — от фактов к заключениям; типично для мониторинга.
Обратный вывод (backward chaining) — от цели к нужным фактам; типично для диагностики ("почему заказ не отправлен?").

Конфликты правил

Правило 1: ЕСЛИ сумма > 100000 ТО требуется_ручная_проверка = да
Правило 2: ЕСЛИ клиент.vip = да ТО требуется_ручная_проверка = нет

Обе могут сработать одновременно. Нужна стратегия разрешения конфликтов — приоритет, специфичность, запрет противоречий. В тестировании покрывают пары правил таблицами кейсов.

Таблицы решений

Для бизнес-аналитиков удобна матрица:

Оплачен	Собран	Склад OK	Новый статус
да	да	да	отправлен
да	да	нет	ожидание_склада
нет	*	*	ожидание_оплаты

Нотация DMN (Decision Model and Notation) стандартизирует такие таблицы.

Логика в представлении знаний

Логические формулы удобны, когда нужны строгие доказательства и общие утверждения.

Предикаты и кванторы

для каждого x: если x — Сотрудник,
  то существует отдел y, в котором x работает

∀x (Сотрудник(x) → ∃y (Отдел(y) ∧ РаботаетВ(x, y)))

Математический фундамент — логика и алгебра логики.

Логика описаний (Description Logic)

Основа языков OWL (Web Ontology Language) в онтологиях:

Конструкция	Смысл
`SubClassOf`	каждый A — это B
`DisjointWith`	классы не пересекаются
`someValuesFrom`	существует связь с классом
`onlyValuesFrom`	все связи только с классом

Пример:

Класс "Несовершеннолетний" ⊆ возраст < 18
Класс "Водитель" ⊆ имеет_права = да
Несовершеннолетний и Водитель — непересекающиеся (в типовой юрисдикции)

Reasoner (программа логического вывода) проверяет согласованность и выводит новые факты.

Prolog и Datalog

Prolog — язык, где программа — набор фактов и правил:

родитель(алиса, боб).
родитель(боб, карл).
предок(X, Y) :- родитель(X, Y).
предок(X, Z) :- родитель(X, Y), предок(Y, Z).

Запрос ?- предок(алиса, карл). — обратный вывод.

Datalog — ограниченный поднабор для больших данных и распределённых вычислений.

Обзор старых языков — Lisp и родственные.

Когда выбирать логику

Задача	Подход
Жёсткие ограничения домена	OWL + reasoner
Цепочки событий	продукционные правила
Рекурсивные отношения на графе	Datalog
Быстрый прототип правил	Prolog

Экспертные системы

Экспертная система — архитектура из базы знаний и механизма вывода (inference engine).

Компоненты

Компонент	Функция
База фактов	текущее состояние кейса
База правил	знания домена
Механизм вывода	сопоставление, срабатывание
Модуль объяснений	"почему такой вывод"
Интерфейс	вопросы пользователю при нехватке фактов

Кейс MYCIN (упрощённо)

Система для подбора антибиотиков при бактериальных инфекциях.

ЕСЛИ инфекция — менингит
   И грам-отрицательная
   И возраст < 18
ТО рекомендовать препарат из класса X
   с учётом аллергий из факта пациента

Сильная сторона — объяснимость. Слабая — хрупкость при выходе за рамки закодированных правил.

Кейс XCON

Конфигурация компьютеров DEC: тысячи компонентов, ограничения совместимости. Правила заменили ручной подбор. Экономический эффект — снижение ошибок сборки.

Уроки для современных систем

разбивать знания на модули по поддоменам;
вести журнал срабатываний правил;
связывать правила с тестами и эталонными кейсами;
не дублировать всё в коде — вынести в управляемый слой KR.

KR и реляционные базы

	Реляционная БД	Представление знаний
Главный вопрос	Какие факты хранятся?	Что они означают и что из них следует?
Типичный запрос	`SELECT … WHERE …`	"Выполнены ли все условия правила?"
Схема	таблицы, внешние ключи	онтология, граф, набор правил
Вывод	обычно в приложении	в reasoner или движке правил
Объяснимость	SQL показывает выборку	цепочка правил

На практике слои комбинируют:

представления (views) и материализованные справочники поверх SQL;
графовые СУБД для связей "кто с кем";
триплетные хранилища для RDF — см. семантический веб.

Концептуальная схема часто рисуется в нотации ER, а живёт в реляционной или графовой БД.

Пример гибрида

PostgreSQL  — транзакции заказов, ACID
Neo4j       — граф рекомендаций "купили вместе"
Drools      — правила скидок и комплаенса
OWL-файл    — общий глоссарий понятий для всех трёх

Согласование имён — через семантику и онтологию.

Как выбрать формализм

Дерево решений (упрощённо)

Критерии выбора

Критерий	Вопрос
Объём фактов	миллиарды строк → SQL, не reasoner на всём
Частота смены правил	часто → вынести в движок правил
Аудит и регуляторика	нужны доказательства → логика, журнал вывода
Межорганизационный обмен	открытые URI, RDF — 330
Команда	аналитики читают таблицы → DMN; онтологи — OWL

Антипаттерны

кодировать всю онтологию мира в одном JSON;
дублировать одно правило в десяти микросервисах без реестра;
выбирать графовую СУБД только "потому что модно", без запросов по связям.

Отраслевые примеры

Медицина — SNOMED CT

SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms) — клиническая терминология: болезни, симптомы, процедуры. Миллионы понятий, строгие иерархии.

Задача	Как помогает KR
Электронная медкарта	единый код диагноза
Клинические решения	правила на кодах, не на свободном тексте
Обмен между клиниками	сопоставление терминов

Свободный текст врача ("кашель") сопоставляют с кодом через терминологию и NLP — трансформеры.

Финансы — FIBO

FIBO (Financial Industry Business Ontology) — онтология финансовых инструментов, организаций, сделок.

Понятие	Роль формализации
Облигация, дериватив	отчётность регулятору
Контрагент	KYC (Know Your Customer)
Событие платежа	соответствие ISO 20022

Банки связывают внутренние справочники с FIBO при интеграциях.

Техподдержка и ITSM

База знаний с связанными статьями, дерево категорий инцидентов, правила маршрутизации:

ЕСЛИ категория = "биллинг"
   И приоритет = "критический"
ТО очередь = "duty-finops"

Граф статей помогает RAG-боту не выдумывать ответ — см. ниже.

Производство и IoT

Правила на показаниях датчиков:

ЕСЛИ температура_печи > 900
   И давление < порога_из_справочника_модели_X
ТО режим = "аварийная_остановка"

Факты — поток telemetry в БД; правила — отдельный слой KR.

Связь с ИИ и RAG

RAG (Retrieval-Augmented Generation) — пайплайн: запрос пользователя → поиск релевантных фрагментов → передача в LLM как контекста → ответ.

Роль KR в RAG

Без KR	С KR
поиск по похожести эмбеддингов	плюс точные факты из графа
риск "галлюцинации"	опора на URI и источник
сложный аудит	цитата триплета или правила

Гибрид: векторный поиск находит кандидатов, граф знаний уточняет отношения ("этот препарат — противопоказан при аллергии X"). Подробнее — применение ИИ, семантический веб.

Ограничения чисто нейросетевого подхода

редкие юридические формулировки;
строгие числовые пороги из регламента;
согласованность с legacy-кодом в COBOL или 1С.

Явные правила и онтологии дополняют, а не заменяют полностью современные модели.

Пример из интернет-магазина (полный цикл)

1. Семантическая сеть каталога

(Смартфон_X, это вид, Смартфон)
(Смартфон, это вид, Электроника)
(Смартфон_X, бренд, Acme)

2. Фрейм заказа

ФРЕЙМ Заказ
  lines: список СтрокаЗаказа
  fulfillment_state: enum

3. Правило отгрузки

ЕСЛИ fulfillment_state = packed И payment = captured
ТО fulfillment_state := shipped

4. Хранение

факты заказов — PostgreSQL;
рекомендации "похожие товары" — граф в Neo4j;
правила скидок — Drools;
глоссарий — OWL или JSON-LD — 330.

5. Проверка

Контрактные тесты на кейсы из таблицы решений. Смысл полей — семантика.

Сопровождение базы знаний

Жизненный цикл

Версионирование правил

Практика	Результат
id правила в реестре	трассировка в логах
valid_from / valid_to	старые заказы по старым правилам
код-ревью правил как кода	те же стандарты, что для Java

Документация для людей

Даже формальная модель нуждается в человекочитаемых описаниях — база знаний, связь с единым языком.

Аналогии и кейсы рассуждения

KR описывает не только факты, но и шаблоны рассуждений.

Рассуждение по аналогии

Известно: Антибиотик_A эффективен при инфекции типа X
Новый кейс: инфекция похожа на X по набору признаков
→ гипотеза: рассмотреть Антибиотик_A (с проверкой противопоказаний)

В графе это пути похожести между узлами. В машинном обучении — ближайшие соседи в embedding-пространстве. Явная запись аналогий в KR помогает объяснять рекомендацию.

Кейс-рассуждение (case-based reasoning)

Хранятся прецеденты — прошлые решённые ситуации:

Поле прецедента	Пример
Симптомы	температура, тип ошибки API
Контекст	версия релиза, регион
Решение	откат, патч, обходной путь
Исход	успех / неудача

Новый инцидент сопоставляют с библиотекой кейсов. Подходит для техподдержки L2/L3 и runbook-ов в системном администрировании.

Неопределённость и достоверность

Реальные знания редко бывают абсолютными.

Факторы уверенности

правило_диагноза с уверенность 0.85
факт_от_датчика с уверенность 0.60 (шум измерения)

Fuzzy logic (нечёткая логика) и байесовские сети — расширения классического KR для градаций "скорее да, чем нет". В медицине и финансах важно хранить источник факта и дату актуальности.

Таблица — типы знаний

Тип	Пример	Как хранить
Факт	заказ 1042 оплачен	строка в БД
Правило	если оплачен — можно отгружать	движок правил
Гипотеза	возможна задержка из-за погоды	пометка confidence
Запрет	нельзя смешивать валюты в одной строке	аксиома онтологии

См. семантику про инварианты и онтологию про аксиомы.

Инструменты и нотации (обзор)

Инструмент / стандарт	Назначение
Protégé	редактор OWL-онтологий
Drools	движок бизнес-правил на JVM
Apache Jena	RDF, SPARQL на Java
Neo4j	графовая СУБД, язык Cypher
JSON-LD	JSON с семантическими URI
SHACL	валидация RDF-графов
DMN	таблицы решений для аналитиков

Выбор инструмента следует за выбором формализма, а не наоборот. Для долгоживущего домена важнее согласованная концептуальная схема, чем конкретный вендор.

Кейс-стади — корпоративный глоссарий

Проблема

Холдинг после слияния: в ERP поле partner, в CRM account, в отчётах client — одна сущность "контрагент", три имени.

Шаги KR-проекта

Инвентаризация — список полей из каталога данных.
Семантическая сеть — Контрагент как класс, подтипы ЮрЛицо, ФизЛицо.
Mapping — таблица соответствия legacy-имён.
Правила — "в отчёте revenue by partner использовать только Контрагент.id".
Публикация — OWL или JSON-LD в семантическом вебе; человекочитаемый глоссарий в базе знаний.

Метрики успеха

снижение расхождений в сводных отчётах;
время онбординга аналитика (меньше "устных" объяснений);
прохождение контрактных тестов между сервисами.

Кейс-стади — чат-бот поддержки с RAG

Архитектура

Что класть в граф

иерархия категорий обращений;
связи "симптом → известная причина → runbook";
ссылки на версии продукта (прагматика из 326).

Что класть в векторный индекс

полнотекстовые статьи с длинными объяснениями;
фрагменты документации API.

Проверка качества

эталонные вопросы с ожидаемой цитатой источника;
запрет ответа при низком score поиска;
эскалация на человека при конфликте правил.

Ошибки моделирования KR

Ошибка	Последствие	Лечение
Один узел "на всё"	путаница класса и экземпляра	разделить типы и объекты
Циклы is-a без аксиом	парадоксы вывода	запрет циклов, review онтологии
Правила в коде и в движке	расхождение поведения	единый реестр
Онтология без владельца	устаревание	роль data steward
Слишком общие предикаты	бессмысленный граф	именованные отношения домена

Связь с системами и моделями: модель KR тоже упрощает реальность — важно фиксировать границы применимости.

Практикум — пошаговый мини-проект

День 1 — глоссарий (10 терминов)

Согласовать с бизнесом определения. Связать с семантикой.

День 2 — семантическая сеть на доске

Нарисовать 15–20 узлов домена "подписка на SaaS" (план, пользователь, счёт, пробный период).

День 3 — пять правил

Оформить переходы состояния подписки в таблице решений.

День 4 — маппинг на SQL

Сопоставить узлы сети с таблицами концептуальной схемы.

День 5 — тест-кейсы

По одному кейсу на каждое правило; негативные сценарии (оплата не прошла, карта просрочена).

Такой практикум укладывается в спринт и даёт осязаемый артефакт без немедленного внедрения OWL.

Упражнения

Упражнение 1 — семантическая сеть

Постройте сеть для домена "библиотека": Книга, Автор, Читатель, Выдача. Укажите минимум три типа связей (это вид, экземпляр, ассоциация). Сверьте с графами.

Упражнение 2 — фрейм

Опишите фрейм Invoice (счёт) со слотами: номер, дата, валюта, сумма в минимальных единицах, плательщик. Укажите наследование от фрейма Document.

Упражнение 3 — правила

Запишите три продукционных правила для перехода статуса заказа. Добавьте таблицу решений 3×3 для оплаты, сборки и отгрузки.

Упражнение 4 — логика

Сформулируйте на русском и в кванторах: "Каждый оплаченный заказ имеет хотя бы одну строку".

Упражнение 5 — KR и SQL

Дано правило "VIP-клиенту скидка 10%". Где его место — в SQL CHECK, в приложении, в движке правил? Аргументируйте ссылкой на таблицу KR и БД.

Упражнение 6 — отрасль

Выберите медицину или финансы. Найдите название стандарта (SNOMED CT или FIBO) и один пример понятия из него.

Упражнение 7 — RAG

Опишите, какие факты магазина лучше хранить в графе знаний, а какие — только в векторном индексе описаний товаров.

Упражнение 8 — онтология и ER

Сравните сущность Patient в ER-диаграмме и класс Patient в OWL. Какие элементы ER легко переносятся в онтологию, какие требуют аксиом? См. 329 и 328.

Упражнение 9 — семантический веб

Запишите три триплета Turtle для заказа интернет-магазина с префиксами ex: и schema:. Проверьте по статье 330.

Упражнение 10 — интеграция legacy

Два сервиса отдают статус заказа разными строками. Предложите слой KR (справочник + правила mapping), не меняя сразу оба API. Связь с семантикой.

Разбор типовых ошибок (учебные задачи)

Задача A. В сети есть ребро (Москва, это вид, Город) и экземпляр (Москва, столица, Россия). Объясните, почему смешение уровней мешает выводу.

Задача B. Правило "скидка 20% всем" и правило "скидка 0% на акционные товары". Опишите стратегию приоритетов.

Задача C. В RAG бот отвечает уверенно без источника. Перечислите три меры на стороне KR и графа знаний.

Чтение и следующие шаги

После этой статьи логично перейти к:

Онтология в информатике — если нужна формальная таксономия и вывод.
Концептуальные схемы — если проект начинается с согласования сущностей с бизнесом.
Семантический веб — если данные уходят за пределы одной организации.
Семантика — если спор идёт о смысле полей, а не о формате файла.

Для углубления в математику — графы, логика. Для внедрения в продукт с ИИ — применение ИИ и трансформеры.

Вопросы для самопроверки

Чем база знаний экспертной системы отличается от реляционной таблицы?
Назовите три типа связей в семантической сети.
Что такое прямой и обратный вывод?
В чём разница между онтологией и ER-диаграммой, если обе описывают сущности?
Как KR связан с семантикой?
Приведите пример гибрида SQL + правила + граф.
Что даёт KR в пайплайне RAG?

Связь с маршрутом 326→330

Статья	Вклад
326	форма и смысл данных
327 (эта)	формализмы записи знаний
328	онтологии как стандарт понятий
329	ER, UML, уровни схемы
330	RDF, Linked Data, графы в сети

Явная запись знаний​

Аналогия​

История представления знаний​

1950–1960-е — логика и первые программы​

1970-е — семантические сети и фреймы​

1980-е — экспертные системы​

1990-е — онтологии и веб​

2000-е — Linked Data и графы знаний​

2010-е — сегодня​

Карта формализмов​

Семантические сети​

Типы связей​

Наследование свойств​

Запросы к семантической сети​

Многослойные сети​

Промышленные графы​

Фреймы​

Слоты и демоны​

Фреймы и объекты в коде​

Пример фрейма заказа​

Множественное наследование фреймов​

Фреймы в UI и формах​

Продукционные правила​

Структура правила​

Цепочки вывода​

Конфликты правил​

Таблицы решений​

Логика в представлении знаний​

Предикаты и кванторы​

Логика описаний (Description Logic)​

Prolog и Datalog​

Когда выбирать логику​

Экспертные системы​

Компоненты​

Кейс MYCIN (упрощённо)​

Кейс XCON​

Уроки для современных систем​

KR и реляционные базы​

Пример гибрида​

Как выбрать формализм​

Дерево решений (упрощённо)​

Критерии выбора​

Антипаттерны​

Отраслевые примеры​

Медицина — SNOMED CT​

Финансы — FIBO​

Техподдержка и ITSM​

Производство и IoT​

Связь с ИИ и RAG​

Роль KR в RAG​

Ограничения чисто нейросетевого подхода​

Пример из интернет-магазина (полный цикл)​

1. Семантическая сеть каталога​

2. Фрейм заказа​

3. Правило отгрузки​

4. Хранение​

5. Проверка​

Сопровождение базы знаний​

Жизненный цикл​

Версионирование правил​

Документация для людей​

Аналогии и кейсы рассуждения​

Рассуждение по аналогии​

Кейс-рассуждение (case-based reasoning)​

Неопределённость и достоверность​

Факторы уверенности​

Таблица — типы знаний​

Инструменты и нотации (обзор)​

Кейс-стади — корпоративный глоссарий​

Проблема​

Шаги KR-проекта​

Метрики успеха​

Кейс-стади — чат-бот поддержки с RAG​

Архитектура​

Что класть в граф​

Что класть в векторный индекс​

Проверка качества​

Ошибки моделирования KR​

Практикум — пошаговый мини-проект​

День 1 — глоссарий (10 терминов)​