Graph engineering: як побудувати AI-дослідження, де нічого не губиться і не перезаписується

Цікавий підхід до роботи з knowledge graph та AI-агентами: замість однієї “розумної” системи — одне сховище, кілька спеціалізованих агентів і append-only лог.

Головний принцип:

нічого не перезаписувати

Кожен новий факт, виправлення або зв’язок додається як новий запис із timestamp і source. Старі дані залишаються в історії.

Це робить систему набагато надійнішою для великих research-проєктів.

Як виглядає архітектура

Є три агенти:

1. extractor — отримує raw source і витягує claims.
2. linker — пропонує зв’язки та можливі merge між entities.
3. checker — перевіряє новий claim проти того, що вже є в knowledge store, і визначає: він підтримується чи суперечить наявним даним.

При цьому linker ніколи сам не виконує merge.

Усі потенційні об'єднання потрапляють у:

merges.pending.jsonl

і потребують ручного підтвердження.

Schema визначається ще до першого запису

Структура проста:

nodes.yml

містить:

- entity;
- claim;
- source;
- artifact;
- run.

edges.yml описує типи зв'язків між ними.

А ids.md зберігає один стабільний ID для кожної entity та список aliases.

Це важливий момент: агенти не повинні самостійно вигадувати нову структуру даних під час роботи.

Store — єдине джерело правди

Усі записи проходять тільки через:

write.py

Скрипт:

validate → append → exit

Жодних UPDATE.

Жодного “виправити старий рядок”.

Наприклад, якщо сьогодні система записала неправильний claim, а завтра знайшла правильну інформацію, старий claim не видаляється.

Додається новий запис, який його спростовує.

У конкретному прикладі knowledge store вже містив 12 571 claims — і нуль оновлених рядків.

Навіщо append-only підхід

Уявімо, що через шість місяців AI змінив опис компанії, людини або продукту.

У звичайній базі старе значення просто перезапишеться.

Тут можна відновити:

- що система знала раніше;
- яке джерело це підтверджувало;
- коли з'явився новий факт;
- який claim його спростував;
- чому фінальна версія змінилася.

Тобто knowledge graph стає не просто базою фактів, а історією того, як формувалося знання.

Ще один плюс — основний index.duckdb є derived data.

Його можна повністю видалити й відновити з логів командою:

make rebuild

У прикладі повний rebuild займає близько 8 секунд.

Що тут можна забрати навіть без knowledge graph

Цей принцип корисний для будь-якої AI research automation:

Sources → Claims → Verification → Append-only Log → Derived Index

Не дозволяйте AI тихо “виправляти” старе дослідження.

Зберігайте source, timestamp, claim і всі наступні corrections.

Джерело: https://x.com/polydao/status/2096128417108287566