Telegram-канал nobilix - Refat Talks: Tech & AI: Unsorted

Refat Talks: Tech & AI

14 October 2026 12:03

Сложные системы знаний умирают, текстовые файлы остаются. И при чем тут frontmatter.

Горячая тема последних лет: как строить "мозг компании", чтобы он одинаково хорошо работал для людей и агентов. Приходилось видеть, как компании строили, перестраивали и снова строили такие системы: сначала вокруг векторных БД, потом на графовых и самописных системах. Все это с болючими миграциями, а многие knowledge-системы сейчас как чемодан без ручки. Вы и сами видите, как все быстро меняется (где все эти посты про чанкование и веторный RAG?). А еще эти постоянные конвертации docx -> pdf -> md -> odt и тд. А сколько форматов файлов уже нет в живых? А знаете, какой формат жив практически всю историю компьютеров и, я уверен, проживет еще очень долго? Правильно: plain text. Отличный пост как раз на эту тему: Why Plain Text Is Still One of the Best Technologies We Have. На plain text стоят код, конфиги, CSV, markdown, HTML и тд. Скучность plain text и есть его суперсила. Плюс портативность, универсальность, скорость и доступность как для людей, так и для агентов.

Но есть и минусы

Их несколько, и они в целом преодолимы. Отсутствие структуры, сложность организации доступа, масштабируемость и тд. Разберу их по порядку в нескольких постах. В этом про главный - структуру.

Frontmatter

Markdown - это тоже текстовый формат, там есть заголовки, списки и прочие элементы структуры контента, но вот данных о самом документе (тип, дата, участники) в нем нет. Решается это давно и просто - через frontmatter. Это YAML-блок между --- в начале markdown-файла, по сути ключ-значение. Популяризовал его Jekyll в 2008-м, пример:


---
type: meeting
category: client
date: "2026-10-13"
attendees:
  - "[[Анна Петрова]]"
  - "[[CTO]]"
---

Дальше *текст* документа

Главный плюс - машиночитаемость такой структуры. Дальше вступает онтология: типы документов, их поля, допустимые значения и связи. Зная ее, агент обычными grep или лучше yq отвечает на вопросы, ради которых заводят БД: на скольких встречах был CTO, кто чаще принимает решения, какие отчеты провалидированы и кем. Либо можно построить быстрый индекс поверх этого, но важно, что источником истины остаются сами файлы.

OKF

В июне Google выпустил Open Knowledge Format, по сути стандарт такой базы: папка markdown-файлов с YAML-шапкой, а также ряд разумных предложений именно для агентной работы. В анонсе прямо ссылаются на старый добрый markdown, LLM Wiki Карпаты и Obsidian - Google признает сложившийся тренд и оформляет его в стандарт, удобный для агентных сценариев. Спеку как минимум стоит прочитать ради идей. Например, в секции про доверие раздельно хранится, кто написал документ и кто его подтвердил:


generated: { by: claude-code/opus-5-5, at: 2026-09-27T22:53:05Z }
verified:
  - { by: human:Refat, at: 2026-09-28T09:00:00Z }
  - { by: process:validate-format, at: 2026-09-28T09:01:00Z }

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

Там еще есть разделы про источники с сигналами достоверности, статус и срок годности документа, index.md и log.md для навигации и истории изменений и тд., а главное, онтологию можно начать с одного type и спокойно развивать.

А вокруг самого frontmatter есть развитый тулинг: его читают библиотеки под все популярные языки и yq из консоли, валидируют по JSON Schema, а markdown-to-sqlite или DuckDB собирают из папки готовый индекс для SQL.

--

Остальные нюансы (включая права доступа) разберу в отдельных постах.

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

🔥 ➕ 🔁 @nobilix