Инженерные документы

ТЗ: Knowledge Explorer — исследовательский интерфейс знаний Temporality

Статус: реализовано (этапы 1–4, см. план). Explorer живёт на странице /knowledge (карта знаний — ?view=map); вкладка «Знания» в Observability удалена. Описание ниже — ТЗ эпохи проектирования; где оно говорило «сегодня» о реестре, имелась в виду допроектная вкладка.

#1. Цель

Разработать пользовательский интерфейс для исследования накопленных знаний Temporality, позволяющий человеку ориентироваться в больших объёмах утверждений, находить нужные сведения по приблизительному пониманию предметной области, изучать связи между знаниями и восстанавливать историю формирования, подтверждения, оспаривания и изменения фактов.

Интерфейс должен развить существующую вкладку «Знания» — сегодня это реестр с поиском, фасетами состояний и областей, битемпоральными фильтрами и сравнением срезов, действиями жизненного цикла (инвалидация с заменой, оспаривание, продвижение) и цепочкой активации — в полноценное исследовательское пространство.

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

#1.1. Основные проблемы

В процессе эксплуатации Temporality накопилось значительное количество утверждений с разными состояниями жизненного цикла. Существующие фильтры, полнотекстовый поиск и временные ограничения уже не обеспечивают удобную навигацию по всему объёму знаний.

Основные сценарии, которые необходимо решить:

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

#1.2. Основной принцип

Пользователь исследует предметную область, а не вручную перебирает записи.

Интерфейс должен помогать последовательно отвечать на вопросы:

Где искать?
Какие понятия и темы связаны с моим вопросом?
Какие утверждения имеют отношение к делу?
Как эти утверждения связаны?
На чём они основаны?
Что изменилось со временем?
Какие вопросы остаются нерешёнными?

#2. Область работ

Реализовать три взаимосвязанных представления:

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

Дополнительно реализовать:

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

Все представления должны использовать существующую модель знаний и предусмотренные архитектурой исследовательские сервисы.

#3. Общая структура интерфейса

#3.1. Точка входа

В существующем интерфейсе Temporality предусмотреть отдельный режим или раздел «Исследование знаний» (Knowledge Explorer).

Он должен быть доступен из раздела знаний (сегодня — страница /knowledge), без необходимости переходить в отдельное приложение.

Существующий реестр знаний и его возможности не удалять. Explorer дополняет его новым способом работы с данными.

#3.2. Главная страница

На стартовом экране должны присутствовать:

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

Пример исходного запроса:

«Найти, почему в одном из проектов отказались от первоначального механизма авторизации».

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

#3.3. Единая исследовательская область

При переходе между картой знаний, графом связей и досье необходимо сохранять:

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

Пользователь должен иметь возможность вернуться на предыдущий уровень без повторного ввода запроса и восстановления фильтров.

#4. Карта знаний

#4.1. Назначение

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

Карта должна помогать обнаружить темы, о которых пользователь не знал заранее, но которые могут быть связаны с его вопросом.

#4.2. Формирование тематических областей

Использовать существующую классификацию и отношения, если они уже доступны.

Если готовая классификация отсутствует, допускается формирование тематических групп на основании доступных формулировок утверждений, семантической близости и контекста. (Реализовано: судейская нормализация областей — canonical/hidden-алиасы.)

Тематические группы являются навигационным представлением. Они не должны автоматически становиться жёсткими категориями знаний или изменять их принадлежность.

Одно утверждение может относиться к нескольким тематическим областям.

#4.3. Отображение

Для каждой области показывать:

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

Не перегружать карту одновременным отображением всех показателей. Подробности показывать при выборе области.

Размер, цвет и другие визуальные характеристики не должны создавать впечатление, что количество знаний или интенсивность активности означает их достоверность.

#4.4. Взаимодействие

Пользователь должен иметь возможность:

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

#4.5. Альтернативный список областей

Помимо графического представления предусмотреть список тематических областей.

Список должен обеспечивать:

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

Карта не должна быть единственным способом доступа к знаниям.

#5. Исследовательский поиск

#5.1. Общие требования

Поиск должен поддерживать естественно-языковые запросы и приблизительные формулировки.

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

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

Текущий поиск — IDF-взвешенный матч с нормализованными признаками и объяснением (matched_by/score, движок lexical-idf.v1); семантический слой подсказок и общий исследовательский слой агентного ТЗ — см. docs/plan-priming-relevance.md §18; интерфейс не должен дублировать его логику.

#5.2. Поисковая выдача

Для каждого результата показывать:

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

Пользователь должен понимать, почему результат появился в выдаче.

Необходимо различать совпадение по тексту, семантическую близость, связь через контекст и явное отношение между утверждениями.

#5.3. Предложения по уточнению

Если запрос широк или неоднозначен, предлагать:

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

Не блокировать поиск обязательным заполнением фильтров.

#5.4. Сортировка

Предусмотреть сортировку по доступным и осмысленным критериям:

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

Релевантность, актуальность и достоверность не должны объединяться в один неинтерпретируемый показатель.

#6. Фасетная навигация

#6.1. Измерения навигации

Пользователь должен иметь возможность исследовать знания по нескольким независимым измерениям:

Организация

компания;
организационный узел;
подразделение;
команда.

Проекты и задачи

проект;
задача;
связанный процесс или запуск агента, если такие данные доступны.

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

состояния, существующие в актуальной модели Temporality: proposed, confirmed, challenged, corrected, superseded, invalidated; псевдосостояния alive и at_risk уже используются фасетами Explorer;
признаки устаревания;
замена;
инвалидация;
наличие неразрешённых противоречий.

Время

время создания;
время регистрации события;
период действия знания, если поддерживается;
временной интервал исследования.

Смысл

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

#6.2. Поведение фильтров

Фильтры должны сочетаться между собой.
Выбранные значения должны быть явно видны.
Должна быть возможность сбросить отдельный фильтр или все фильтры.
Количество результатов должно пересчитываться с учётом доступных данных и выбранных условий.
Нулевой результат должен сопровождаться понятным объяснением и предложениями ослабить ограничения.
Изменение фильтров не должно сбрасывать исходный вопрос и исследовательский контекст.

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

#6.3. Область применимости

В интерфейсе необходимо различать:

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

Нельзя автоматически считать знание, обнаруженное в проекте, утверждением, действующим для всей компании.

#7. Исследование связей

#7.1. Назначение

Позволить пользователю перейти от известного утверждения к связанным сведениям, даже если они напрямую не соответствуют исходному поисковому запросу.

Граф должен показывать релевантное окружение выбранного объекта, а не всю базу знаний.

#7.2. Типы связей

Отображать те типы отношений, которые поддерживаются существующей моделью или исследовательским слоем:

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

Не создавать фиктивные отношения ради заполнения графа.

#7.3. Визуальное представление

Для узлов и связей необходимо различать:

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

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

Цвета и иконки должны иметь понятную легенду. Нельзя кодировать несколько независимых характеристик одним и тем же цветом без дополнительного обозначения.

#7.4. Управление графом

Пользователь должен иметь возможность:

раскрывать связи выбранного узла;
выбирать типы отношений;
ограничивать глубину;
скрывать нерелевантные типы узлов;
искать узел внутри текущей области;
переходить к подробной карточке объекта;
центрировать граф на выбранном узле;
возвращаться к предыдущему состоянию;
видеть объяснение связи.

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

Необходимо предусмотреть защиту от визуальной перегрузки. Не стремиться отображать все связи одновременно.

#8. Досье знания

#8.1. Назначение

Предоставить единое подробное представление выбранного утверждения, объединяющее его содержание, состояние, применимость, происхождение, связи и историю.

#8.2. Содержание досье

Основная информация

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

Происхождение

кем и когда сформировано;
исходные события;
контекст создания;
доступные источники;
связанные задачи и агентные запуски.

Связанные знания

подтверждающие утверждения;
оспаривающие утверждения;
альтернативные версии;
уточнения;
заменённые и инвалидированные знания;
семантически близкие утверждения.

Использование

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

История

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

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

#8.3. Переходы

Из досье пользователь должен иметь возможность:

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

#9. Временная история

#9.1. Назначение

Восстановить эволюцию знания и помочь понять, почему его текущее состояние отличается от первоначального.

#9.2. Представление

Использовать временную линию событий с возможностью просмотра подробностей.

Отображать:

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

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

#9.3. Битемпоральная навигация

Модель уже поддерживает битемпоральные срезы: фильтры as_of/known_at и сравнение срезов реализованы в Explorer (HistoryTimeline). Предусмотреть возможность исследовать:

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

Историческое состояние нельзя подменять текущим состоянием записи.

Пользовательский интерфейс должен объяснять, какой именно временной аспект используется в каждом представлении.

#10. Обнаружение противоречий

#10.1. Представление

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

Для конфликта отображать:

обе формулировки;
состояние каждой записи;
временной контекст;
область применимости;
основания и источники, если доступны;
существенные различия контекста;
статус разрешения противоречия, если он предусмотрен моделью.

#10.2. Интерфейс сравнения

Предусмотреть отдельное представление для сопоставления двух или нескольких утверждений.

Пользователь должен иметь возможность быстро увидеть:

совпадающие положения;
различающиеся формулировки;
различия условий применимости;
временные различия;
доступные свидетельства;
нерешённые вопросы.

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

Интерфейс не должен автоматически считать более новое утверждение истинным.

#10.3. Изменение жизненного цикла

В рамках этой задачи разрешено только отображение и навигация по противоречиям.

Изменение состояния утверждения, подтверждение, инвалидация или разрешение конфликта должны выполняться через существующие механизмы управления знаниями с предусмотренными правами и подтверждениями.

#11. Исследовательская сессия

#11.1. Назначение

Позволить пользователю сохранять ход расследования, возвращаться к нему и передавать его другим уполномоченным участникам.

#11.2. Состав сессии

Сохранённая сессия может включать:

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

#11.3. Требования

Сессия не должна создавать копию знаний и подменять собой первичные записи.
Ссылки должны вести к актуальным объектам с учётом их текущих прав доступа.
При изменении состояния исходного знания интерфейс должен показывать его текущее состояние.
Сохранённые выводы и заметки должны оставаться отличимыми от утверждений в базе знаний.
Сессия не должна сохранять доступ к объектам, права на которые были отозваны.
Необходимо предусмотреть создание новой сессии на основе существующей, если это соответствует текущей модели работы с проектами.

Если в системе уже есть подходящая сущность для сохранения пользовательского рабочего контекста, использовать её вместо создания параллельной модели.

#12. Работа с результатами исследования агента

Если агент использовал исследовательский API, пользователь должен иметь возможность открыть его результаты в Knowledge Explorer.

При наличии соответствующих данных отображать:

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

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

Необходимо отличать:

факты из исходных данных;
выводы агента;
предположения агента;
рекомендации по дальнейшему исследованию.

Не представлять автоматически сформированный вывод как подтверждённое знание.

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

#13. Визуальный стиль и UX

#13.1. Общие требования

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

Основные принципы:

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

#13.2. Постепенное раскрытие информации

На первом уровне показывать темы, связи и краткие сведения.

Подробные метаданные, полную историю, исходные события и дополнительные связи раскрывать по запросу.

Не выводить все характеристики знания одновременно на главном экране.

#13.3. Доступность

Предусмотреть:

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

#13.4. Пустые и ошибочные состояния

Для каждого представления предусмотреть состояния:

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

Сообщения должны объяснять ситуацию и предлагать разумный следующий шаг.

#14. Права доступа и безопасность

Все данные, отображаемые в Explorer, должны соответствовать действующей модели авторизации Temporality.

Обязательно:

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

Если объект стал недоступен после сохранения сессии, его содержимое не должно продолжать отображаться из сохранённого состояния.

#15. Архитектурные ограничения

Использовать существующие сервисы, модели, идентификаторы и механизмы доступа Temporality.
Использовать общий исследовательский слой с агентным инструментом, предусмотренным docs/agent-knowledge-exploration.md.
Не реализовывать в пользовательском интерфейсе собственную логику определения достоверности и жизненного цикла.
Не создавать параллельный механизм поиска и классификации без обоснования.
Не вводить новую графовую базу только ради визуализации.
Не превращать тематические группы в жёсткую классификацию без отдельного решения.
Не считать семантически близкие утверждения подтверждающими друг друга.
Не изменять исходные знания при просмотре, фильтрации или исследовании.
Не нарушать существующие контракты и возможности реестра знаний (/knowledge).
Не создавать дублирующую систему хранения истории и происхождения.

Если существующие API не обеспечивают необходимую функциональность, сначала определить минимальное расширение общего исследовательского слоя и согласовать его с архитектурой проекта.

#16. Производительность

Большие наборы данных не должны приводить к загрузке всех утверждений в браузер.
Карта и граф должны получать ограниченные и релевантные выборки.
Граф должен загружать соседние узлы по запросу.
Временная линия должна поддерживать ограничение интервала и постепенную загрузку истории.
Поисковая выдача должна поддерживать пагинацию или эквивалентный механизм постепенного получения результатов.
При изменении фильтров не следует полностью пересоздавать исследовательскую сессию.
Кеширование допустимо только при корректном учёте прав доступа и временных ограничений.

Целевые показатели задержки и объёма данных определить после измерения текущей реализации и проведения испытаний на реалистичном объёме знаний.

#17. Тестирование

#17.1. Функциональные сценарии

Проверить следующие сценарии:

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

#17.2. Проверка корректности

Проверить, что:

фильтры не смешивают несовместимые временные контексты;
состояние жизненного цикла не подменяет оценку достоверности;
предположительные связи визуально отличаются от явных;
граф не показывает недоступные объекты;
карта не раскрывает запрещённые данные через агрегаты;
исторические данные не подменяются текущим состоянием;
сохранённая сессия не превращается в независимую копию знаний;
выводы агента не отображаются как подтверждённые утверждения.

#17.3. UX-проверка

Провести сценарные испытания с пользователями, которым не предоставляются точные названия искомых утверждений.

Оценить:

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

Не принимать работу только на основании технической работоспособности отдельных экранов.

#18. Критерии приёмки

Задача считается выполненной, если:

В Temporality доступен Knowledge Explorer, не заменяющий существующий реестр знаний.
Пользователь может начать исследование с приблизительного запроса.
Доступны карта тематических областей и альтернативный список.
Поиск поддерживает смысловые совпадения и объясняет релевантность результатов.
Реализована фасетная навигация по контексту, времени и жизненному циклу.
Доступно исследование локального графа связей.
Реализовано досье знания с происхождением, состоянием и историей.
Реализовано сопоставление конфликтующих утверждений.
Переходы между представлениями сохраняют контекст исследования.
Пользователь может сохранять и открывать исследовательские сессии, если соответствующая функция включена в согласованный объём.
Результаты агентного исследования можно открыть и проверить, если соответствующая интеграция реализована.
Все представления соблюдают существующую модель доступа.
Исследование больших наборов данных не требует загрузки всей базы в браузер.
Пройдены автоматизированные функциональные тесты и согласованные UX-сценарии.
Все новые компоненты используют общие сервисы и не дублируют бизнес-логику.

#19. Этапы реализации

#Этап 1. Аудит и прототипирование

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

Результат: согласованная структура интерфейса и технический план реализации.

#Этап 2. Базовая исследовательская навигация

Главная страница Explorer.
Поиск по приблизительному запросу.
Карта тематических областей и список.
Фасетная навигация.
Сохранение контекста переходов.

Результат: пользователь может ориентироваться в предметной области и находить релевантные знания.

#Этап 3. Исследование и проверка

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

Результат: пользователь может проверить происхождение и контекст найденных знаний.

#Этап 4. Рабочие сессии и интеграция с агентами

Сохранение исследовательских сессий.
Повторное открытие и продолжение расследований.
Просмотр результатов исследования агента.
Переход от выводов агента к исходным данным.

Результат: воспроизводимые исследования, которые можно продолжить или проверить.

#20. Итоговый результат

Knowledge Explorer должен позволять человеку пройти путь:

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

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

Интерфейс должен делать накопленные знания обозримыми, объяснять связи между ними и помогать человеку отличать подтверждённые сведения от гипотез, исторических утверждений и нерешённых противоречий.

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