TECH SPEC

Ниже приведено примерное Техническое Задание (ТЗ) на разработку программы, которая по выгруженной из 1С конфигурации (только XML-файлы) строит все уровни абстракции (начиная с 4-го уровня — AST) и создает “википедию” (базу знаний), а также RAG / GraphRAG-систему для AI-бота, способного отвечать на вопросы по конфигурации.

При этом предполагается, что предыдущая программа (по предыдущему ТЗ) у нас уже существует, и мы можем повторно использовать её модули (парсеры XML, AST, IR, генераторы) или логику.

---

#1. Цель проекта

1. Считать выгруженные из 1С XML-файлы (метаданные + модули в CDATA, структура директорий).

2. Автоматически построить для конфигурации все уровни абстракции (начиная от (4) AST до (10) Business Model), либо хотя бы до (8–9), а также:

   • Создать «википедию» (структурированную базу знаний, в удобном формате, например Markdown, HTML, Wiki-движок).
   • Построить GraphRAG (Retrieval-Augmented Generation на графах и/или векторных embedding) для дальнейшего ответа на вопросы.
   • Создать AI-бота, который будет использовать эту базу (вики + RAG) и отвечать на вопросы о конфигурации.

3. В ходе разбора XML и кода (AST, IR) программа может обращаться к LLM для:

   • «Суммаризации» фрагментов кода, объяснения бизнес-логики,
   • Генерации описаний для «Википедии».

4. Результат — развернутая система, где пользователь задаёт вопросы боту (естественным языком) и бот отвечает, опираясь на вики и RAG-индексы (а не «галлюцинирует» от себя).

---

#2. Требования к входным данным и взаимодействию

1. Вход: директория с выгрузкой XML-файлов конфигурации 1С (по аналогии с v8unpack).
2. Выход:
   • Полная цепочка абстракций (внутреннее хранение / БД / JSON …) от (4) AST до (8) Domain Model / (9) Business Processes / (10) Business Model (по возможности).
   • «Википедия» (набор статей/страниц), описывающих объекты конфигурации, связи, модули, процедуры, и т.п.
   • RAG-система:
     • Векторные базы (embedding содержимого),
     • Graph-хранилище для зависимостей (Graph DB или некий «GraphRAG»),
     • Механизм получения контекста (chunk retrieval) по запросу.
   • AI-бот (API или веб-интерфейс), который при получении вопроса пользователя:
     1. Ставит запрос к RAG, получает релевантные части «википедии» (chunks, embeddings).
     2. Формирует ответ (при необходимости обращается к LLM).

---

#3. Уровни абстракции (краткая спецификация)

Делаем акцент: начиная с (4) AST — все пункты включительно до (10) Business Model (по возможности):

1. (4) AST
   • Использовать готовые парсеры (из предыдущей программы) для текстов BSL: получение синтаксического дерева процедур, функций, операторов.
2. (5) Code Model / IR
   • Сопоставить AST с объектами метаданных (Документ, Справочник и т.п.), зафиксировать процедуры «ПриЗаписи», «ПриПроведении», вызвать зависимости и т.д.
3. (6) Dependency Graph
   • Построить граф, показывающий, кто вызывает что: модули, регистры, общие модули, справочники и т.д.
4. (7) Архитектурный / Функциональный
   • Определить, какие подсистемы, объекты, формы, модули — «скелет» конфигурации.
5. (8) Domain Model (Предметная модель)
   • Автоматически извлечь «сущности» (справочники, документы) и связи (реквизиты, табличные части).
   • Где возможно, обращаться к LLM, чтобы «расшифровать» названия (например, «ЗаказПокупателя → Order»).
6. (9) Business Processes (BPM)
   • Пытаться понять процедуры, связанные с жизненным циклом документов, «проведение», «отчеты», «бизнес-процесс» (если есть) и сгенерировать их диаграммы/описания.
7. (10) Business Model
   • Высший уровень (для стейкхолдеров, KPI, метрик) — по возможности, частично автоматически при помощи LLM (если названия и логику можно агрегировать).

---

#4. Побочные (основные) артефакты: «Википедия» и GraphRAG

#4.1. “Википедия”

• Формат: Markdown, HTML, MediaWiki, Confluence, … (по согласованию).
• Структура:
  • Страница про каждый объект (Справочник, Документ, Регистр) + список реквизитов, связь с другими объектами, краткое описание.
  • Страница про каждую процедуру/функцию (особенно если это ключевые методы, типа «ПриПроведении»).
  • Суммаризация логики (AST → «В этом методе происходит …»), обращение к LLM для «человеческого объяснения».
• Ссылки: wiki-статьи должны взаимосвязываться (Document «ЗаказПокупателя» → ссылка на DomainModel «Order» (если есть переименования), ссылка на регистры).

#4.2. RAG (Retrieval-Augmented Generation)

• Векторное хранилище:
  • Разбиваем тексты описаний, код (AST-суммаризацию) и «вики-статьи» на «чанки», создаём embedding (с помощью OpenAI Embeddings, SentenceTransformers и т.д.).
  • Сохраняем в векторную базу (Milvus, Pinecone, FAISS, Qdrant и т.п.).
• Graph:
  • Информация о зависимостях (6) может быть сохранена в Neo4j, ArangoDB или аналогах — чтобы быстро находить цепочки вызовов: «кто вызывает этот общий модуль?».
  • Либо интегрировать граф с векторным подходом (GraphRAG).
• Процесс ответа:
  1. Получаем вопрос пользователя.
  2. Делаем search в векторном хранилище (RAG), находим релевантные «чанки» из вики/кода/AST.
  3. Формируем prompt (при необходимости с контекстом), вызываем LLM.
  4. LLM выдаёт ответ (в стиле ChatGPT).
  5. Выдаем пользователю, с цитированием источников (URL wiki-статей, кода).

---

#5. Использование LLM

Во многих местах:

1. Суммаризация методов, кусков кода (AST) — «Поясни, что делает эта процедура».
2. Генерация описаний (wiki-статей, пояснений о бизнес-процессах).
3. Переход от технических названий к бизнес-трактовке (8, 9, 10 уровни).

Программа должна уметь полуавтоматически вызывать LLM по фрагментам кода/описания. Можно сохранять результаты в «википедию» или «embedding» для RAG.

---

#6. Требования к архитектуре программы

1. Язык реализации: допустим, Python (возможно тот же, что и в предыдущей программе).
2. Повторное использование:
   • Парсеры XML (из предыдущего ТЗ), AST-парсер BSL, etc.
   • Модули «Code Model / IR» (или хотя бы их идеи) — чтобы не дублировать код.
3. Хранилища:
   • Как минимум, векторная БД (FAISS, Pinecone, Qdrant, etc.).
   • Возможно, графовая БД (Neo4j, ArangoDB…) для (6) Dependency Graph.
   • Или можно хранить граф в той же реляционной БД, если есть подходящая модель.
4. Wiki-генератор:
   • Создание структуры папок/файлов (Markdown) или API для MediaWiki/Confluence.

---

#7. Основные этапы работы

1. Сканирование папки с XML-файлами → извлечение метаданных (объекты, реквизиты, формы).
2. Сбор текстов модулей (BSL) из CDATA → преобразование в (4) AST.
3. Построение Code Model / IR (5) → выявление процедур, кто куда пишет/читает.
4. Dependency Graph (6) → записать связи между объектами в какую-то структуру (граф).
5. Архитектурный слой (7) → обзор, подсистемы.
6. Domain Model (8) → (получаем полуавтоматически через LLM): «Справочник:Контрагенты = Entities:Clients», «Документ:ЗаказПокупателя = Entities:Order»…
7. Business Processes (9) → анализ процедур «ПриПроведении», «ПриЗаписи», «Scheduler», etc. + LLM для диаграмм.
8. Business Model (10) → в целом, резюме для менеджмента (тоже с LLM).
9. Генерация статей («Википедия»):
   • Одноименные или переименованные сущности, их поля, логика, связи (сделать Markdown).
   • Суммаризация кода (AST).
10. Построение embedding:

• Разбить полученные тексты (статьи, код, комментарии) на чанки (N символов).
• Вызвать embedding-модель, сохранить в векторную БД.

11. GraphRAG:

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

12. AI-бот:

• REST API или чат-интерфейс, где пользователь спрашивает про конфигурацию.
• Бот возвращает обоснованный ответ + ссылки на вики (RAG).

---

#8. Выходные результаты

1. Полная база знаний (Wiki) о конфигурации:
   • Объекты, их поля, формы, модули, методы, связи, бизнес-процессы.
2. Граф зависимостей (файл или БД), где отображены вызовы/записи.
3. Векторная БД/индекс, в которую уложены описания и фрагменты кода.
4. AI-бот (CLI/веб/телеграм-бот), который может отвечать на вопросы.
5. (Опционально) BPMN-диаграммы процессов, генерируемые автоматически или полуавтоматически.

---

#9. Точки ручного вмешательства

1. Уточнение имен и смыслов (Domain Model, Business Process).
2. Коррекция описаний, если LLM выдала неточную «галлюцинацию».
3. Настройка wikitool / Graph DB / embedding-параметров.

---

#10. Приёмка

1. Запуск:

   • Указать папку c XML.
   • Программа автоматически (можно с вопросами к пользователю) строит AST, IR, Domain Model, генерирует «википедию».

2. Проверить:

   • Есть ли страницы про все объекты?
   • Отражаются ли методы (типа «ПриЗаписи», «ПриПроведении») со своим пояснением?
   • Dependency Graph в наличии (можно запросить, кто вызывает регистр «ЗаказыПоКонтрагентам» и получить ответ).
   • AI-бот: при вопросе «Как считается сумма документа “ЗаказПокупателя”?» должен найти нужную статью / кусок кода и дать осмысленный ответ.

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

---

#Заключение

По этому ТЗ должно быть создано программное решение (вероятнее всего, расширение/надстройка над предыдущей программой), которое анализирует XML-конфигурацию 1С, строит высокоуровневую базу знаний (вплоть до бизнес-процессов и бизнес-модели), генерирует «википедию», создает RAG-индекс и AI-бот.
Так пользователь сможет задавать вопросы (в т.ч. сложные: «кто вызывает процедуру X?», «как считается скидка?», «какие регистрационные движения формируются при проведении документа Y?») — и бот ответит, ссылаясь на соответствующие материалы, не «придумывая» лишнего.