Не Дай Себя Одурачить: Контекстные Графы

17 февраля 2026

Самая дорогая проблема в инженерной организации – не баги и не скорость. Это амнезия. А сегодня любая современная организация в той или иной степени инженерна :)

И эта амнезия – это когда вы вроде быстро доставляете фичи/продукты, но стабильно возникают ситуации с налётом археологии: приходится напрягаться, чтобы вспомнить “а кто вообще помнит про…”, “где это обсуждали”, “почему сделали именно так”.

Знания о наших системах бессистемно размазываются по слакам, жирам, гиту, AI-заметкам из созвонов, наконец (и хуже всего) – по персональным головам.

И вот на этом фоне сейчас возникли context graphs, идея использования которых преподносится примерно так: “а соберём-ка мы следы решений из разных мест, свяжем их, и получим институциональную память! Это поможет нам во всяких аудитах, онбордингах, поиске прецедентов…”.

Context graph – это просто граф, собранный из событий/решений (decision traces), который потом используют для поиска по “контексту” (часто ещё и как подложку для AI-агента).

Ничего качественно нового: под другими именами идея “контекстуальности” пронизывает IT и инженерию давным-давно, мелькая под вывесками: audit trail, process mining, data lineage, knowledge graph, ADR/decision log, event sourcing.

Замечательная штука, но не дайте себя одурачить – это не серебряная пуля и тут есть фатально критичные моменты.

И вот какие

1) Идентификация сущностей системы.

“Alex”, “Alexander”, “@alex”, “alex@corp”, “mr.crablex” в дискорде – это один человек или пять разных? Пока вы это не решили и формально не уточнили, граф с высокой вероятностью уже будет врать.

2) Возраст и версии.

Политики меняются, орг-структура меняется, любые решения имеют “срок годности”. Учитывается ли это в вашем графе? Лучше бы учитывалось, иначе вы будете применять прецедент времён прошлого CFO как “истину навсегда”.

3) Доступы и ретеншн.

Если вы просто складываете “почему мы отказали кандидату/клиенту” в единый слой, ещё и “навечно”, – вы зародили себе проблему с безопасностью и комплаенсом. И в какой-то момент кто-то с доступом (неважно кто) унесёт дамп туда, куда вам не понравится.

4) Этика и стимулы.

Как только люди понимают/думают, что “дядя всё на каждого лично пишет”, они переносят реальное обсуждение в личку слака или вообще в некорпоративный мессенджер. Полнота графа? Сомнительная.

5) Смешивание фактов и объяснений.

LLM очень любит дописывать “почему” красивым текстом. Если это попадает в тот же слой, что и реальные факты, вы навсегда теряете пригодность такого графа для аудита.

Тут же ещё важно не перепутать “память” с моделью мира. Decision traces в том формате, в котором их предлагается собирать, – это далеко не “почему”. Это просто улики. И пока их атрибуты, идентичности и связи с другими кусочками данных не проверены – это, строго говоря, ничем не подтверждённые улики.

Улики отлично отвечают на “что было и кто нажал кнопку”, но не обязаны отвечать на “что на самом деле происходило в головах и контексте? что привело к этому нажатию на кнопку? кто вообще и на основании чего решил, что надо нажать на неё и именно тогда”. Вот это всё – про “почему”.

Выходит, что если граф (AI-агент над этим графом) не умеет честно говорить “я не знаю”, он будет тупо, ненамеренно, но уверенно врать.

Многие апологеты контекстных графов уже признают этот важный момент: “почему” часто непроверяемо, а реально ловится лишь “как” – последовательность действий, политики, согласования – и уже по ней мы лишь, может быть, приблизимся к “почему”.

Вот, это уже честно. И давайте продолжать распространять эту честность в сообществе: всё, что выше уровня “как”, должно иметь статус гипотезы, а не истины.

Это чо в смысле мы ещё и статусы моделировать должны?! ДА.

Я это всё к тому, что без явных разграничений контекстов, определения словаря терминов, инвариантов нашей системы (и подсистем), а ещё – очень желательно – версионирования всего, что имеет смысл версионировать, такой граф быстро станет красивой свалкой: данных всё больше, воспроизводимости всё меньше и меньше – и так до тех пор, пока она становится практически невозможной.

В разговорах о контекстных графах фразы вроде “schema isn’t the starting point, it’s the output” звучат эффектно (и в очень узком смысле даже верны для исследования), но как инженерный принцип – это заведённая бомба.

Очевидно, что сбор следов может начинаться “без схемы”.

Но уже само рациональное использование этих следов потребует модели, онтологии, контрактов! Иначе у вас не “живой граф”, а живой спор друг с другом о том, что означают слова в выдачах этого графа.

“Схема на выходе” без уточнений – это откровенная ложь. А уточнения вот какие: я уверен, что только настоящий и упорный AGI из бессистемного, плохо смоделированного графа (мусорки) сможет хорошо восстановить модель организации, чтобы эффективно можно было сделать всё то, что нам обещают “контекстные графы”. При этом такому AGI придётся пройтись по директорам и другим сотрудникам, уточняя и проверяя многие моменты :)

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

Вот вам бесплатно быстрый тест для любого “context graph” решения:

• эта штука умеет показать пруфы (источники/ссылки/таймлайны) для каждого ответа, или только генерит красивую историю?
• эта штука умеет сказать “дядя, я не знаю, у меня недостаточно данных”?
• в этой штуке есть механизм отслеживания версии узлов (чем бы они ни были), или “всё как-то само” и “схема – потом”?
• без танцев с бубном наделяет ли вас “эта штука” возможностью воспроизвести решение на снапшоте состояния “как тогда было”?

А уже потом автоматизируйте память.

Если пост был полезным, пожалуйста, подпишитесь на мой Substack бесплатно и поделитесь этим текстом с одним другом. Это действительно помогает мне продолжать писать! Спасибо :)