🫐 Cyberries

Руководство по методологии EnMaTeS v1.0

время чтения ~5 мин.

EnMaTeS Methodology Guide v1.0

1. Введение: Назначение Руководства

Данное Руководство по Методологии EnMaTeS является основным рабочим документом для архитекторов, разработчиков и всех, кто участвует в создании и поддержке ИИ-агентов на базе системы EnMaTeS.

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

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

2. Ключевые Архитектурные Компоненты: Детальное Описание

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

  • SMF (Semantic Modeling Framework): Фундамент системы. При работе с любым бизнес-доменом строго придерживайтесь типов узлов, связей и атрибутов, определенных в актуальной версии SMF. Это гарантирует, что все Семантические Графы (SG) в экосистеме EnMaTeS будут совместимы и понятны для любого ИИ-агента.
  • FPM (Framework Prompt Modes): Определяют “операционную систему” ИИ-агента. FPM-Dev используется исключительно для разработки и содержит полный набор команд для создания и модификации артефактов. FPM-Use – это “облегченный” режим для конечного пользователя, сфокусированный на извлечении знаний (RAG) и взаимодействии с готовым SG.
  • FPS (Framework Prompt Specialization): Конкретизируют “профессию” ИИ-агента. FPS_DomainExpert является универсальной основой. Для придания специфических знаний и ограничений (например, для юриста или инженера) создается FPS-Addon, который дополняет и уточняет базовый FPS. Создание полностью кастомного FPS оправдано только для ролей с уникальной, нетиповой логикой.
  • PIC (Purpose and Introductory Context): “Техническое задание” для конкретного ИИ-агента. PIC связывает воедино все остальные компоненты, указывая, какой SG использовать, к каким SDA обращаться, и какие цели преследует данный агент. Существуют PIC для Dev-сессий (цель – разработка) и для Use-сессий (цель – обслуживание пользователя).
  • SG (Semantic Graph): “Мозг” ИИ-агента. Это живой артефакт, который моделирует бизнес-домен. Его качество напрямую влияет на качество работы ИИ. SG создается и развивается итерационно в Dev-чате.
  • SDA (Source Documents/Artifacts): “Библиотека” или “долговременная память” агента. SG содержит структуру и семантику, а SDA – детали и первоисточники. Качество RAG-механизма напрямую зависит от того, насколько хорошо SDA проиндексированы и связаны с узлами в SG.
  • ChatConfig: “Сборочный чертеж” ИИ-агента. Этот артефакт декларативно описывает, из каких версий SMF, FPM, FPS и PIC собирается полная Системная Инструкция (SI) для конкретного ИИ-агента. Это ключевой элемент для обеспечения воспроизводимости и управляемости конфигураций.

3. Основной Воркфлоу: Создание Нового ИИ-Агента “с нуля”

Этот детализированный воркфлоу является стандартной процедурой для создания нового пользовательского ИИ-агента (Use-чата) для нового бизнес-домена.

Этап I: Настройка Среды Разработки (Dev-чата)

  1. Определить Цель и Контекст для Разработки (PIC_Dev):

    • Создается артефакт PIC_Dev_{{NewDomainName}}_{{Purpose}}_vX.Y.md. В нем четко определяется, что данный Dev-чат предназначен для создания Семантического Графа (SG) и других артефактов для будущего Use-чата.

  2. Выбрать/Адаптировать Специализацию для Разработчика (FPS_Dev):

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

  3. Создать Конфигурацию для Dev-чата (ChatConfig_Dev):

    • Создается артефакт ChatConfig_Dev_{{NewDomainName}}_{{Purpose}}_vX.Y.md. В нем указываются актуальные версии SMF, FPM-Dev, выбранный FPS_Dev и созданный PIC_Dev.

  4. Инициализировать Dev-чат:

    • С помощью стартового промпта (SP) запускается Dev-чат с полной Системной Инструкцией, собранной по ChatConfig_Dev.

Этап II: Разработка Компонентов для Use-чата (внутри Dev-чата)

  1. Разработать Семантический Граф для Домена (SG):

    • С помощью ИИ-ассистента в Dev-чате создается SG_{{NewDomainName}}_{{SubsystemName}}_vX.Y.md. Проводится анализ SDA нового бизнес-домена, извлекаются и моделируются ключевые сущности и отношения.

  2. Подготовить и Структурировать Исходные Документы (SDA):

    • Собираются и подготавливаются все текстовые документы домена. Они могут быть зарегистрированы как узлы типа artifact в SG для прямой связи.

  3. Разработать/Адаптировать Специализацию для Use-чата (FPS_Use):

    • На основе FPS_DomainExpert создается или дополняется (через FPS-Addon) роль ИИ для конечного пользователя.

  4. Создать Контекст для Use-чата (PIC_Use):

    • Создается артефакт PIC_Use_{{NewDomainName}}_{{Purpose}}_vX.Y.md, который ссылается на созданный SG и SDA, и описывает контекст для ИИ-пользователя.

  5. Создать Стартовый Промпт для Use-чата (SP_Use):

    • Создается SP_Use_{{TargetAudience}}_{{NewDomainName}}_Welcome_vX.Y.md с приветствием и примерами запросов для пользователя.

  6. Создать Руководство Пользователя для Use-чата (UM_Use):

    • (Рекомендуется) Создается UM_{{Client/Target}}_{{NewDomainName}}_vX.Y.md с инструкциями по использованию агента.

Этап III: Настройка и Запуск Use-чата

  1. Создать Конфигурацию для Use-чата (ChatConfig_Use):

    • Создается ChatConfig_Use_{{TargetAudience}}_{{NewDomainName}}_vX.Y.md. В нем указываются SMF, FPM-Use, разработанный FPS_Use и PIC_Use.

  2. Собрать Системную Инструкцию (SI) и Пакет Инициализации (IP):

    • SI: Объединяются компоненты, указанные в ChatConfig_Use.
    • IP: Объединяются SG, SDA, SP_Use и UM_Use.

  3. Развернуть и Запустить ИИ-Агента:

    • На выбранной технологической платформе развертывается ИИ-агент с его SI и доступом к IP.

4. Лучшие Практики и Принципы Разработки

4.1. Размещение Артефактов

При создании нового артефакта необходимо сразу определять и рекомендовать его местоположение в согласованной структуре папок репозитория (согласно EnMaTeS_Repository_Structure.md). Это обеспечивает порядок и легкую навигацию. Например, данное руководство (EnMaTeS_MethodologyGuide.md) должно располагаться в /022100_System_Overview/.

4.2. Версионирование

  • Все ключевые, изменяемые артефакты (SMF, FPM, FPS, PIC, SG, и т.д.) должны иметь атрибут version (например, v1.0).
  • При внесении значительных изменений, ломающих обратную совместимость, увеличивается мажорная версия (v1.x → v2.0). При добавлении функциональности без нарушения совместимости – минорная (v1.0 → v1.1).
  • ChatConfig должен ссылаться на конкретные версии компонентов для обеспечения стабильности и воспроизводимости сборок.

4.3. SG как “Живой Коннектом”

  • Семантический Граф – это не статичная база данных, а динамическая модель (“коннектом”) нашего общего с ИИ понимания домена.
  • Он должен непрерывно обновляться в ходе диалога. Использование полных слепков SG для синхронизации контекста между сессиями является ключевой практикой для предотвращения потерь информации.

5. Дорожная Карта Развития

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

Вид графа