Контентный промпт - Этап 1
DrMax# ЭТАП 1 - СБОР СУЩНОСТЕЙ: УНИВЕРСАЛЬНЫЙ МЕТА-ПРОЦЕДУРНЫЙ ПРОТОКОЛ
## ФАЗА A. Настройка этапа (переменные, критерии, требования)
### A.0. Общие установки
1. Цель: собрать максимально полное множество сущностей и связанных поисковых интентов, релевантных объекту исследования, и представить их в структурированном машиночитаемом виде.
2. Режим: аналитический, детерминированный, без художественных формулировок. Генерация - только структурированные данные, метаданные и списки; тексты описаний минимальны и строго фактичны.
3. Формат вывода: JSON (см. спецификацию ниже).
### A.1. Базовые переменные (обязательные; указывать в промпте)
* object_name - строка: имя или идентификатор объекта (например, «SuperKettle X100», «Ford F-150», «МКС»).
* domain_hint - строка: краткая область (например: бытовая техника, автомобиль, аэрокосмическая система).
* language - строка: язык вывода (например: «ru»).
* min_entities - целое, по умолчанию 70.
* min_intents - целое, по умолчанию 70.
* min_keywords - целое, по умолчанию 70.
* max_depth_expansion - целое, по умолчанию 3 (число рекурсивных раундов расширения сущностей).
* cosine_threshold - число ∈ [0,1], по умолчанию 0.72 (порог для кластеризации эмбеддингов при поиске близких сущностей).
* output_schema - выбор: «standard» (см. ниже) или пользовательский JSON-шаблон.
### A.2. Критерии сущности (определение)
Сущность (Entity) - именуемая, атомарная единица предметной области, обладающая свойствами и ролями, пригодная для индексирования и связей в онтологии.
Формат представления сущности: {id, name, category, attributes, synonyms, preferred_label}.
### A.3. Критерии интента (определение)
Интент (User Intent) - формализованное поисковое намерение, выраженное в форме вопроса или целевого запроса пользователя.
Классификация типов интентов: informational (Info), navigational (Nav), commercial/investigational (Com), transactional (Trans), other.
Классификация подтиров: direct, related, implied, comparative, clarifying.
### A.4. Ограничения по стилю и поведению
* Никакой художественности, никаких маркетинговых клише.
* Выделение терминов: первое появление bold (при JSON - поле is_preferred_label = true).
* Все выходные данные - только JSON; никаких свободных абзацев.
* При обнаружении несоответствия - автоматически возвращаться к фазе расширения до удовлетворения критериев.
## ФАЗА B. Исполнение этапа 1 (пошаговый рабочий процесс)
> Модель должна выполнять шаги последовательно. После каждого крупного шага - валидация локальных результатов (см. Фазу C).
### B.1. Инициализация контекста
1. Зафиксировать object_name и domain_hint.
2. Сформировать seed-токены: основные термины из object_name + domain_hint.
3. Сохранить текущий список сущностей S = ∅, список интентов I = ∅, список ключевых фраз K = ∅.
### B.2. Нахождение «ядра» сущностей (Core extraction)
1. Выполнить NER на входном тексте/документах (если доступны) и на контексте object_name.
2. Сгенерировать начальный список кандидатов сущностей S0 = {e1,...,en} с первичной категоризацией (category guess) и минимальным набором атрибутов (type, short_label).
3. Для каждого кандидата заполнить поля: name, category_candidate, raw_aliases (варианты написания), confidence_estimate (0..1).
### B.3. Внутренний анализ (features и механики)
1. Для каждого e ∈ S0 извлечь структурные атрибуты, релевантные domain_hint:
* для техники: механики, спецификации, материалы, размеры, параметры;
* для ПО/систем: компоненты, интерфейсы, модули;
* для объектов площадки: персонажи, сцены, сюжеты.
2. Добавить найденные атрибуты в e.attributes[].
### B.4. Контекстный и сравнительный анализ
1. Поиск: сопоставить e с аналогичными в внутренней базе (если предоставлена) или в семантическом пространстве.
2. Для каждого e найти 4–10 ближайших аналогов (конкурентов) по cosine_similarity ≥ cosine_threshold; при отсутствии - по убывающему рангу сходства.
3. Добавить relations: {relation_type: "analogue"/"variant"/"series_member", target: id}.
### B.5. Расширение сущностей (Related / Implied / Comparative / Clarifying)
Для каждого e проделать до max_depth_expansion циклов:
1. Related: найти сущности в непосредственной семантической окрестности (embedding cluster neighbours).
2. Implied: вывести логически подразумеваемые сущности (атрибуты, последствия, сценарии использования).
3. Comparative: добавить сущности, которые естественно сравнивают e с объектами домена.
4. Clarifying: уточняющие сущности (подвопросы, измеряемые параметры).
Добавлять новые сущности в S, отмечая provenance (related/implied/comparative/clarifying) и depth.
### B.6. Сбор ключевых фраз и LSI
1. Для каждой сущности собрать список семантически связанных фраз и синонимичных выражений (LSI), включить варианты склонений и распространённые поисковые формулировки.
2. В K для каждой entity e поместить min 5 и max 50 ключевых фраз (если доступны).
### B.7. Детекция интентов и маппинг на сущности
1. Для каждой сущности e сформировать набор пользовательских вопросов (user_question[]) - 2–6 вопросов на сущность, покрывающих типы интентов.
2. Классифицировать каждый вопрос по типу интента (Info/Nav/Com/Trans/Other) и по подтелу (direct/related/implied/comparative/clarifying).
3. Добавить записи в I.
### B.8. Построение семантического графа (knowledge graph)
1. Создать граф G = (V, E) где V = S и E = relations между сущностями; каждая связь помечена типом и confidence.
2. Вычислить метрики: degree, betweenness, clustering coefficient, isolated_nodes, weak_links (low confidence edges).
### B.9. Gap detection (поиск пробелов)
1. Выявить «изолированные узлы» и «слабые связи» (confidence < 0.6 или degree = 1).
2. Сгенерировать рекомендации по добавлению «связывающих» сущностей или контента, которые заполняют выявленные пробелы.
---
## ФАЗА C. Самопроверка, валидация и коррекция (цикл качества)
### C.1. Валидационные проверки (обязательные)
Для итогового набора данных выполнить автоматически:
1. COUNT проверки:
* |S| ≥ min_entities
* |I| ≥ min_intents
* |K| ≥ min_keywords
2. Дедупликация:
* Проверить дубли по нормализованным леммам и семантической близости (cosine > 0.94) → слияние дублей.
3. Категоризация:
* Каждая сущность должна иметь category ∈ predefined_taxonomy OR category = "other" с объяснением.
4. Полнота атрибутов:
* У каждой сущности заполнены обязательные поля: id, name, category, aliases[] (≥1), attributes[] (если применимо), provenance.
5. Интенты:
* Для каждой сущности ≥ 2 user_question; для приоритетных сущностей ≥ 4.
6. Граф:
* Определено связей ≥ |S| − isolated_nodes; не более 30% изолированных узлов (если больше - возвращение к расширению).
7. Контроль качества семантики:
* Для каждого intent проверить, что хотя бы один ключевой запрос из K содержит активный лексический маркер из user_question.
8. Формальные проверки:
* Нет запрещённых символов/паттернов (по языковому регламенту вашего проекта).
* JSON валиден, соответствует схеме.
### C.2. Коррекционный цикл
Если любая из проверок C.1 не выполнена → выполнить шаги:
1. Вернуться к фазе B.5 (расширение) с аргументом: target = недостающая область (например, "увеличить связанные сущности для категорий MathModel").
2. Увеличить depth на 1 и/или снизить cosine_threshold на 0.02 (но не ниже 0.60).
3. Повторять до max_depth_expansion.
4. Если после max_depth_expansion критерии все ещё не выполнены - сообщить о невозможности достичь заданных чисел и вернуть диагностический отчёт с причинами.
### C.3. Финальная валидация и вывод
Если все проверки пройдены - перейти к выводу JSON по схеме.
## Вывод: Структура JSON (рекомендуемая «standard» схема)
Выгружать строго в JSON-объекте:
{
"object": { "name": "...", "domain": "...", "language": "..." },
"statistics": {
"entities_found": N,
"intents_found": M,
"keywords_found": K,
"iterations": r
},
"entities": [
{
"id": "E001",
"name": "string",
"preferred_label": true|false,
"category": "CoreMechanic|FeatureModifier|MathematicalModel|PlayerExperience|AudiovisualTheme|Narrative|Comparative|Other",
"provenance": ["seed","ner","embedding","manual_rule","comparison"],
"aliases": ["string","..."],
"attributes": { "attr_name": "value", "...": "..." },
"related_entities": [ {"id":"E010","relation":"analogue","confidence":0.82}, ... ],
"depth": 0,
"confidence": 0.0,
"keywords": ["phrase1","phrase2",...],
"sample_user_questions": [
{"question":"Как активировать [feature]?", "intent_type":"Info", "intent_subtype":"direct"}
]
},
...
],
"knowledge_graph": {
"nodes": [ "E001","E002",... ],
"edges": [ {"source":"E001","target":"E002","type":"enables","confidence":0.78}, ... ],
"metrics": { "isolated_nodes": 3, "weak_links": 5 }
},
"gaps_and_recommendations": [
{"issue":"weak_link_between E034 and E012","recommendation":"add content explaining relation X; add entity 'connection Y'"},
...
],
"audit_log": [
{"step":"initial_seed","timestamp":"...","note":"..."},
...
]
}
(строго без свободного текста вне JSON)
## Дополнительные технические примечания для реализации в LLM-потоке
1. При доступе к embedding-инструментам - использовать cosine_similarity для кластеризации.
2. Для генерации implied entities использовать шаблон «Если существует X, то вероятно существует Y, потому что…» - но результат записывать как гипотезу с низкой confidence.
3. Все автоматические гипотезы помечать provenance = "hypothesis".
4. При малой уверенности (confidence < 0.6) - добавлять поле review_required = true.
5. При использовании внешней БД - в relations помещать ссылку на источник.