Graph engineering: от циклов к графам знаний

18 июля 2026 года Питер Штайнбергер опубликовал в X полушутливый вопрос о переходе от циклов к графам. Хамель Хусейн подхватил его и выпустил статью под названием Loop Engineering Is Dead. Enter Graph Engineering. За неделю термин был повсюду.

Это была в основном шутка о том, как быстро эта область чеканит новые дисциплины: мы прошли путь от prompt engineering к context engineering, затем harness engineering, loop engineering и graph engineering примерно за восемнадцать месяцев, причём определения сильно перекрываются.

Но шутка сработала, потому что указывает на нечто реальное. Вот та часть, которую стоит оставить.

Три вещи, которые называют «graph engineering»

Термин пришёл, неся как минимум три разные идеи. Бо́льшая часть путаницы в сети — это люди, спорящие, перескакивая между ними.

1. Графы оркестрации. Проектировать мультиагентную систему как явный граф вместо цикла while: типизированные узлы, типизированные переходы, контрольные точки для возобновления. Это территория LangGraph и Temporal. Настоящая инженерия — и важна главным образом, если вы строите инфраструктуру для агентов.

2. Графы циклов. Сети циклов самоулучшения, наблюдающих друг за другом. Концептуально любопытно и, по общему мнению, наименее применимо сегодня.

3. Знание и память со структурой графа. Знание агента, хранимое как типизированные узлы и рёбра, по которым он действительно может ходить, а не как груда документов, которую он перечитывает и заново угадывает.

Если вы не строите инфраструктуру оркестрации — а большинство из нас не строит, включая тех, кто наблюдает, как агенты въезжают в рабочее пространство, — именно третий пункт меняет ваш день. Он же самый старый и лучше всего обеспеченный из трёх: графы знаний старше термина на десятилетия.

Почему рёбра сильнее поиска

Вот пример, после которого всё встаёт на место.

Спросите агента: «Почему мы отказались от Redis для очереди задач?»

Полнотекстовый поиск вернёт каждый документ со словом «Redis» — после какого-то времени работы это десятки файлов, и ни один из них не ответ. Векторный поиск вернёт документы, которые звучат как вопрос, что часто хуже: семантически близко, причинно нерелевантно.

Граф отвечает за три перехода:

очередь задач --decided_by--> ADR-007 (очередь на Postgres)
ADR-007       --supersedes--> ADR-003 (очередь на Redis)
ADR-003       --caused------> Инцидент 2026-03-11

Ответа нет ни в одном отдельном документе. Он в пути между ними. Поиск не умеет возвращать путь: он возвращает узлы и надеется, что вы соедините их сами.

И обратите внимание на решающую деталь: рёбра именованы. supersedes — это не caused и не decided_by. Уберите метки, и вы возвращаетесь к «эти файлы как-то связаны», а значит, агенту придётся открыть все и заново выводить связь — ровно та работа, которой вы хотели избежать.

Типизированные рёбра — весь фокус. Остальное — сантехника.

Ваше Markdown-хранилище — это уже 80 %

Вот недооценённое наблюдение всей дискуссии: ухоженное Markdown-хранилище — уже бо́льшая часть индекса GraphRAG.

Подумайте, что бесплатно даёт хранилище заметок с викиссылками:

• Узлы — по файлу на идею, источник или решение
• Рёбра — каждая [[викиссылка]] есть связь, которую кто-то установил намеренно
• Разрешение сущностей решено по построению — [[ADR-007]] это один и тот же узел везде, где встречается. Никакого нечёткого сопоставления, никаких коллизий эмбеддингов, никаких «а это два упоминания одного и того же?»

Последний пункт не мелочь. Именно на разрешении сущностей тихо рассыпается большинство автоматических конвейеров построения графов знаний. Хранилище обходит это, потому что человек назвал сущность один раз, а ссылка и есть идентичность.

Чего простому хранилищу не хватает — так это меток. [[ADR-007]] говорит, что две заметки связаны. Не говорит, как. Это оставшиеся 20 %.

Как это выглядит на практике

Вокруг этой части и построен Minibase Vault, так что лучше конкретно о работе, чем отвлечённо о возможностях.

Узлы берутся из чтения. Вы жмёте расширение Minibase на всём, что стоит сохранить, — странице документации, RFC, треде в X, докладе — и оно приземляется чистым Markdown в локальную базу знаний. Без копипаста, без шага экспорта, без вкладки «прочитаю потом», умирающей при следующем падении браузера.

Рёбра записываются вместе с обоснованием. Хранилище держит _graph.json в корне:

{
  "edges": [
    {
      "from": "AI Research/attention-paper-20260405-1200.md",
      "to": "AI Research/transformer-tutorial-20260408-0900.md",
      "reason": "Both explain the attention mechanism in transformers"
    }
  ]
}

Claude пишет эти рёбра сам, через MCP-сервер хранилища, когда читает ваши заметки поперёк и замечает связь. Затем они всплывают строками Related: в _index.md каждой базы, чтобы сеть была видна и вам, а не только модели.

Пути сжимаются в страницы. Когда кластер связанных заметок становится достаточно плотным, Claude может свести их в страницу _topic-*.md, цитирующую источники. В следующий раз, когда вы сохраните что-то из этого кластера, страница-синтез уже ждёт обновления. Это и есть накопительный эффект: хранилище становится умнее, а не только больше.

Сироты помечаются. Проход lint сообщает о дубликатах, осиротевших заметках, устаревшем содержимом и кластерах, созревших для синтеза. Графы деградируют; кто-то должен это замечать.

Всё работает локально. Поисковый индекс — SQLite FTS5 с ранжированием BM25, граф — файл JSON, и ничего из ваших заметок не покидает машину.

Где я бы поумерил восторг

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

Рёбра Minibase несут обоснование, а не формальный тип. "reason": "Both explain the attention mechanism" — это фраза, а не supersedes. Намного лучше немаркированной викиссылки и заметно меньше онтологии. Если вам нужны строго типизированные связи для многошагового вывода в масштабе, вам нужна настоящая графовая база — и стоит честно оценить, чего будет стоить её поддержка.

Большинству людей всё это не нужно. Если ваше знание — пятьдесят заметок, поиска достаточно. Графы начинают окупаться, когда материала столько, что вы уже начали забывать, что у вас есть, — и когда вопросы стали причинными («почему мы»), а не лексическими («где я читал»).

Термин «graph engineering», скорее всего, не переживёт год. Идея под ним — что структура между заметками ценнее количества заметок — была верна задолго до того, как получила имя, и останется верной после.

Начните со скучной версии

1. Сохраняйте прочитанное как Markdown вместо закладки. Закладка — указатель на то, что гниёт; файл — то, что у вас есть.
2. Держите локально, в одной папке, по файлу на источник.
3. Дайте своему ИИ прочитать всю папку — через MCP, а не копипастом — и задайте вопросы, для ответа на которые нужны два документа.
4. Записывайте найденные связи. И спросите снова через месяц.

Это graph engineering для тех, кто не выпускает фреймворки оркестрации. Это context engineering с записанными связями.

---

Minibase превращает любую веб-страницу в чистый Markdown одним кликом, прямо в локальное хранилище, по которому ваш ИИ может искать и строить связи. Расширение бесплатно с неограниченным числом сохранений; Minibase Plus ($5,99/мес. или $34,99/год) добавляет ИИ-шаблоны, историю и транскрипцию видео. minibase.md.