Знания в DevOps живут в разных форматах: Markdown, YAML (плейбуки, конфиги), JSON (API, метаданные), Confluence/Notion. У каждого формата — своя семантика; для базы знаний и RAG важно единообразие извлечения и индексации. Форматы не отменяют идею «слотов и значений» — просто реализованы по-современному.
Ориентиры расширений: .md, .yml, .json — парсер в пайплайне выбирает по типу файла.
YAML и JSON
YAML — плейбуки Ansible, docker-compose, описания k8s. Иерархия ключей — те же слоты и вложенные структуры. JSON — API-контракты, метаданные, конфиги приложений. Оба формата машиночитаемы; парсер извлекает поля для индекса. В RAG можно индексировать и ключи, и значения: поиск «как в docker-compose задать порт» находит релевантный фрагмент по смыслу.
Markdown и структура
Markdown — регламенты, runbook'и, README. Заголовки задают структуру (аналог имён слотов); абзацы и списки — содержимое. При чанкинге границы по заголовкам сохраняют смысл. Метаданные (front matter) в начале файла — тип документа, владелец, теги — можно выносить в отдельные поля векторной БД для фильтрации.
Единый источник истины
Один и тот же факт не должен дублироваться в десяти местах. Конфиг — в репо; документация ссылается на него или генерирует фрагменты из него. База знаний индексирует и конфиг, и описание; чат возвращает и ссылку на файл, и пояснение. Форматы тогда не конкурируют — они дополняют друг друга при единой политике обновления.
Практики применения
- Используйте YAML/JSON для типов записей и шаблонов; единый формат упрощает индексацию и RAG.
- Храните протофреймы в базе знаний — так и люди, и чат дают согласованные ответы.
Кратко: YAML/JSON — слоты и значения в современном виде; Markdown — структура через заголовки. Для RAG важны единообразное извлечение текста и метаданных, чанкинг по границам и единый источник истины для ключевых фактов.