Вход — история одного вопроса
Представьте, что вы — аналитик в университете. Ваш руководитель спрашивает: «Какие научные группы в России сейчас работают на стыке графов знаний и искусственного интеллекта, какие у них гранты, публикации и программные продукты, и где результаты уже можно применить?»
Вы открываете поисковик. Через час у вас двадцать вкладок: новости, статьи, профили лабораторий, отчёты фондов, тезисы конференций. Но вы всё ещё не можете ответить строго:
- какие группы реально связаны общими проектами (а не просто упоминаются рядом);
- какие результаты подтверждены источниками, а какие — только заявления;
- как одно событие (завершение гранта, смена руководителя) влияет на другое;
- почему два документа описывают одну и ту же группу по-разному.
Проблема не в том, что «поиск плохой». Проблема в другом: поиск возвращает документы — фрагменты текста. А вам нужно связное знание: объекты, отношения и контекст, из которых можно построить проверяемый вывод.
| Ключевая идея Знание — это не набор текстов. Знание — это управляемая структура: сущности (что?), связи (как связано?) и контекст (при каких условиях?), с проверяемым происхождением каждого факта. |
Именно в этой точке появляется проект «Ковчег знаний МГУ» и курс МФК-0. Курс устроен не как «теория → экзамен», а как «понимание → артефакт → защита». Вы не просто слушаете лекции — вы начинаете производить небольшой, но пригодный к использованию фрагмент знания через мини-проект.
Три проблемы, которые делают «просто поиск» недостаточным
Проблема 1: поиск находит слова, а не смысл
Полнотекстовый поиск работает по принципу «есть запрос — найдём похожий текст». Но управленческие и исследовательские вопросы живут не в словах, а в структуре отношений. Вопрос «Какие процессы зависят от данного сервиса, кто владелец процесса и какие риски возникают при отказе?» — это сеть связей: сервис ↔ процессы ↔ роли ↔ документы ↔ риски. Если эта сеть не представлена явно, поиск не даст гарантии полноты и непротиворечивости.
Проблема 2: контекст распадается, и вместе с ним — доверие
Даже если вы нашли «правильный документ», возникают уточнения: это актуальная версия или старая? На каких данных сделаны выводы? Что изменилось после публикации? В «документоцентричном мире» на эти вопросы отвечают вручную — опытом экспертов. Но когда масштаб растёт, ручной контроль перестает работать.
Проблема 3: ИИ даёт ответы, но без гарантии происхождения
Большие языковые модели формулируют ответы убедительно. Но если модель выдаёт «красивый текст», вы снова упираетесь в вопрос доверия: откуда это? На каких источниках? Подход RAG (Retrieval-Augmented Generation) связывает генерацию с извлечёнными источниками, но ключевой вопрос остаётся: как устроена «внешняя память». Если это хаотичный набор фрагментов — проблема доверия не решена. Если это граф знаний с происхождением и онтологией — мы приближаемся к доверенному контуру.
«Ковчег знаний» — когнитивная инфраструктура, а не «ещё один портал»
«Ковчег» — это не портал и не библиотека PDF. Это инфраструктура — система правил, форматов и сервисов, которая позволяет знанию быть: собранным из разных источников, сведённым в общий смысловой каркас, проверяемым (с происхождением и контролем качества) и используемым в сценариях — от обучения до поддержки решений.
Миссия проекта задаётся тремя словами: доверенные знания → суверенный контур управления знанием → поддержка принятия решений.
| Примечание: что означает «доверие» в инженерном смысле Доверие — это не «мы верим авторам». Это четыре проверяемых свойства: (1) можно указать источник; (2) можно объяснить, как факт получен; (3) можно воспроизвести цепочку рассуждения; (4) можно обновить знание и увидеть, что изменилось. Эту способность мы называем трассировкой: вопрос → элементы знания → источники → преобразования → вывод. Если трассировки нет — доверия нет. |
Архитектура верхнего уровня — четыре элемента и поток между ними
На первой неделе вам не нужно «реализовать архитектуру». Нужно понять роль каждого элемента и увидеть своё место в системе.
Аналитический центр — управляющий контур. Здесь формулируются вопросы и показатели, утверждаются правила качества, разбираются спорные источники. Смысл: знание не должно «накопиться как-то» — оно должно управляться.
Граф знаний (Когнитивное ядро) — центральное хранилище сущностей и связей с идентификаторами, типами, словарями, привязкой к источникам, версионностью и контролем качества. Ключевая мысль недели: если вы не умеете назвать сущности и отношения — строить не из чего.
AI-аналитика — слой интеллектуальных сервисов (включая LLM/Graph-RAG), которые используют граф для извлечения, сопоставления, проверки и построения гипотез. ИИ без опоры на граф — генератор правдоподобного текста без гарантий.
Образовательный контур — не «добавка для студентов», а производственный механизм: выращивание команд, производство артефактов и обучение работе со знанием. Здесь находится МФК-0 как «ворота»: вы учитесь дисциплине инженерии знаний и одновременно поставляете первые пригодные фрагменты содержания.
Граф знаний — почему знание для управления похоже на сеть
Граф знаний — это представление предметной области как сети: узлы (сущности) и рёбра (отношения). Если вы когда-то рисовали «карты понятий» — вы уже делали первый шаг. Разница в том, что граф знаний — это формальная модель, которую можно хранить, запрашивать и проверять.
Таблицы великолепны для чётко нормализованных структур. Но как только вы выходите на задачи интеграции разнородных источников, «склейки» сущностей, сложных связных запросов и трассируемости — граф становится естественной формой.
| Важно Граф — не магия. Он не «делает всё сам». Он заставляет нас явно описывать смысловые связи. За счёт этого система становится управляемой. |
Онтология и триплеты — «грамматика» графа
Онтология — это явная договорённость о терминах и отношениях. Классическое определение: «явная спецификация концептуализации» (Gruber). На практике: вы фиксируете, какие сущности существуют, какие отношения допустимы и какие ограничения делают модель непротиворечивой.
Без онтологии смысл «уезжает в головы людей». Один говорит «инцидент», другой — «событие». Онтология позволяет согласовать словарь, отделить классы от экземпляров, зафиксировать типы отношений и обеспечить проверяемость.
В семантических технологиях знания выражаются триплетами: субъект — предикат — объект (стандарт RDF, W3C). Примеры:
- (Курс МФК-0) —имеет тему→ (Граф знаний)
- (Утверждение X) —подтверждено источником→ (Документ Y)
Триплет дисциплинирует: он заставляет формулировать знание проверяемо. Именно поэтому в «Ковчеге» важен не просто граф, а граф с контуром доверия (provenance): кто создал утверждение, когда, из каких источников, какая версия актуальна.
«Вопросы боли» — где граф даёт реальный прирост
Ключевой поворот первой недели: мы ищем не «интересные темы», а вопросы, которые плохо решаются поиском, но хорошо решаются связным знанием. Признаки таких ситуаций:
- нужно сравнение и агрегация по множеству источников;
- термины неоднозначны (в разных документах одно и то же называется по-разному);
- важен контекст: время, организация, нормативная база, версия;
- нужен вывод «кто с кем связан» и «почему».
| Правило различения Если вопрос можно решить одним документом — это, скорее всего, не вопрос для графа. Если вопрос требует связей (сравнить, выявить зависимости, объяснить влияние, проследить цепочку) — это кандидат на граф. |
8. Методика выбора домена — четыре проверки
Проверка 1 — Границы. Можно ли чётко сказать, что входит и что не входит? «Кибербезопасность вообще» — это космос. «Нормативные требования и меры защиты для конкретного типа организации» — это домен.
Проверка 2 — Объекты. Можете ли вы быстро назвать минимум 10 ключевых сущностей? Если нет — домен не оформлен.
Проверка 3 — Вопросы. Существуют ли 3–5 содержательных вопросов, на которые должен отвечать ваш граф? Если нет — непонятна польза.
Проверка 4 — Пользователь. Есть ли конкретный адресат (аналитик, преподаватель, руководитель)? Без пользователя домен — абстракция.
Три домена-примера — образец для вашего A1
Ниже — три полностью оформленных примера. Каждый содержит все элементы, требуемые критериями приёмки (DoD). Используйте их как образец для собственного паспорта домена.
Пример 1. Учебные программы, компетенции и оценочные средства
| Поле A1 | Содержание |
| Название домена | Учебные программы, компетенции и оценочные средства (на примере выбранного факультета/направления МГУ) |
| Пользователь | Руководитель программы, методист, преподаватель |
| Границы: входит | Дисциплины, компетенции, результаты обучения, оценочные средства, связь «компетенция ↔ тема ↔ задание» |
| Границы: не входит | Кадровые вопросы, финансы, общеуниверситетская статистика вне выбранного направления |
| Сущности (12) | Образовательная программа; дисциплина; модуль; результат обучения; компетенция; индикатор компетенции; тема; лекция; практическое задание; критерий оценивания (рубрика); тестовый вопрос; литература/источник |
| Источники | РПД, аннотации, фонды оценочных средств, силлабусы, LMS-материалы |
| Риски доверия | Несогласованность терминов; устаревшие версии РПД; различия между документами и LMS |
| Гипотеза WS | WS-1 (Когнитивное ядро) |
Вопросы боли:
- Какие задания и тесты реально проверяют конкретный индикатор компетенции?
- Где в программе есть «провалы»: компетенции заявлены, но не покрыты темами и оцениванием?
- Какие дисциплины дублируют одни и те же результаты обучения?
- Как меняется покрытие компетенций при изменении состава тем?
- Какие источники являются «опорными» для конкретного результата обучения?
Пример 2. Нормативные требования и ответственность в кибербезопасности
| Поле A1 | Содержание |
| Название домена | Нормативные требования и ответственность в контуре кибербезопасности организации |
| Пользователь | CISO, служба ИБ, юрист по комплаенсу, аудитор |
| Границы: входит | Требования (нормы/стандарты/политики), активы, инциденты, меры защиты, контрольные процедуры, роли ответственности |
| Границы: не входит | Техническая эксплуатация всех ИТ-систем (только контроли и риски) |
| Сущности (14) | Нормативный документ; требование; контроль (control); актив; владелец актива; риск; угроза; уязвимость; мера защиты; инцидент; роль (ответственный); подразделение; аудит/проверка; доказательство выполнения (evidence) |
| Источники | Политики ИБ, результаты аудита, реестры активов, отчёты по инцидентам, требования регуляторов |
| Риски доверия | Неполные реестры активов; разрыв между документами и фактом; «бумажные» доказательства без подтверждения |
| Гипотеза WS | WS-2 (Инженерия доверия и верификации) |
Вопросы боли:
- Какие требования покрываются какими контролями и где есть «дыры» покрытия?
- Какие активы попадают под конкретные требования и кто их владелец?
- Какие инциденты связаны с какими уязвимостями и какие меры реально снижали риск?
- Где ответственность размыта: один контроль — много владельцев, или наоборот?
Пример 3. Проекты, команды и результаты исследований
| Поле A1 | Содержание |
| Название домена | Проекты, команды и результаты исследований (публикации, гранты, ПО) в выбранной тематике/организации |
| Пользователь | Руководитель научного направления, аналитик науки, проектный офис |
| Границы: входит | Проекты, участники, организации, публикации, гранты, результаты (ПО/патенты/датасеты), связи «кто с кем и над чем» |
| Границы: не входит | Полноценная наукометрия всего мира; берём ограниченный набор организаций/период |
| Сущности (13) | Исследователь; научная группа; организация; проект; грант; публикация; тема/ключевое слово; метод/подход; результат (ПО/датасет/патент); конференция/журнал; коллаборация; роль в проекте; период/этап |
| Источники | Публикационные базы, отчёты по грантам, репозитории ПО/датасетов, профили организаций |
| Риски доверия | Разночтения ФИО/аффилиаций; неполные метаданные; «шум» ключевых слов |
| Гипотеза WS | WS-1 (Когнитивное ядро) + WS-3 (Data Pipeline) |
Вопросы боли:
- Какие группы связаны общими проектами/публикациями и где реальные «узлы» кооперации?
- Какие результаты (ПО/датасеты) возникли из каких грантов и какие публикации их подтверждают?
- Какие темы «переезжают» между группами и почему?
- Где есть противоречия: проект заявлен, но публикации не подтверждают прогресс?
- Кто является ключевыми носителями компетенций по методу X и с кем они сотрудничают?
Паспорт домена (A1): структура артефакта
На первой неделе вы создаёте документ на 1–2 страницы, содержащий шесть полей:
- Название домена (коротко и однозначно).
- Ценность и контекст (1–2 абзаца): почему область важна и кто пользователь.
- Границы: что входит / что не входит.
- Пользовательские вопросы (минимум 3): где «поиск не тянет».
- Кандидат-сущности (минимум 10): ключевые объекты/понятия домена.
- Гипотеза привязки к WS: к какому рабочему направлению ближе ваш проект.
| Три ловушки «плохого домена» 1. Слишком широко. «Вся медицина», «вся экономика» — это не домен, а космос. Сужайте до конкретной задачи/организации/периода. 2. Нет проверяемости. Если вы не можете назвать хотя бы тип источников — доверие не построить. 3. Нет отношений. Если получается только список терминов без связей — вы выбрали словарь, а не домен. |
Критерии приёмки W1 (DoD)
| Чтобы неделя считалась закрытой Границы домена сформулированы конкретно: что входит / что не входит. Есть минимум 10 кандидат-сущностей (сущности, а не темы). Есть 3–5 вопросов пользователя, требующих связей/контекста. Указаны типы источников и 2–3 риска доверия/качества. Документ оформлен структурно, читабелен, без противоречий. |
Рубрика оценивания (0–10):
| Баллы | Описание |
| 0–2 | Домен размытый или непроверяемый; нет сущностей и/или вопросов. |
| 3–5 | Домен в целом понятен, но границы размыты; сущности/вопросы абстрактные. |
| 6–8 | Домен ограничен; ≥10 сущностей; 3–5 хороших вопросов; источники/риски обозначены. |
| 9–10 | Домен «встраиваемый»: вопросы требуют связей; риски конкретны; виден путь к A2. |
12. Вопросы для самопроверки
- Почему полнотекстовый поиск не решает задачу доверенного знания?
- В чём различие между графом знаний и «просто сетью ссылок»?
- Что означает определение онтологии как «явной спецификации концептуализации»?
- Что такое provenance и какие вопросы оно закрывает?
- Сформулируйте один вопрос к вашему домену, который точно требует связей, а не справки.
13. Мини-глоссарий W1
Граф знаний — модель данных, представляющая знания как сеть сущностей и отношений.
Онтология — явная спецификация концептуализации; словарь и ограничения смысла.
RDF — стандарт W3C для представления данных как графа триплетов.
Linked Data — практики публикации структурированных данных в Web.
Provenance — происхождение данных/утверждений: кто, когда, из чего, как получено.
RAG — генерация ответа с опорой на извлечённые источники.
Трассировка — возможность пройти путь от вывода к исходным данным и обратно.
DoD (Definition of Done) — набор критериев, определяющих завершённость артефакта.
Мост в вторую лекцию W2 — от паспорта к структуре
W1 — это постановка задачи. W2 превращает постановку в структуру: сущности, атрибуты, связи и кардинальности, первый «подграф» вашего домена. Ваши 10 кандидат-сущностей из A1 получат формальные определения и типизированные связи. Ваши вопросы боли станут тестами для модели: если модель не позволяет ответить на вопрос — в ней чего-то не хватает.
| Практический совет Если вы сегодня честно сделали границы, сущности и вопросы — на следующей неделе вы превратите это в модель. Если нет — W2 начнётся с переделки A1. |
| Материалы W1 для скачивания |