Skip to content

Latest commit

 

History

History
66 lines (41 loc) · 8.45 KB

File metadata and controls

66 lines (41 loc) · 8.45 KB
title Корпоративная память, пригодная для AI
record_kind report
status active
derived_from
rules.yaml
generation_mode human_authored
audience humans_and_agents

Корпоративная память, пригодная для AI

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

Появление AI не меняет природу этой проблемы. Оно лишь делает её заметнее: у корпоративной памяти появляется новый, быстрый и буквальный потребитель, который не умеет сам отличить устаревшую копию от канонической записи. Выход не в том, чтобы «загрузить всё в AI». Сначала нужно устроить память так, чтобы у каждого утверждения были canonical owner, происхождение, lifecycle и адрес.

Знания как код

В разработке исходный код не пересылают целиком в чат. Его кладут в репозиторий, меняют через понятный diff, оставляют историю и дают ссылку на конкретную версию. Для знаний работает тот же принцип.

Репозиторий — не обязательно Git. Это может быть система документов, база данных или профильная операционная система. Важно, чтобы у записи были канонический адрес, история, контекст и понятный владелец. Код владеет реализацией, операционные системы — транзакционными фактами, документация — intent, rationale и contracts. Git особенно хорош для правил, решений, runbook-ов и проектной документации, потому что делает изменения проверяемыми.

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

Связанный граф вместо одной свалки

  1. Источник сохраняет то, что произошло или было сказано: письмо, запись, договор, таблицу, первичную выгрузку.
  2. Каноническое утверждение фиксирует, что организация сейчас принимает в объявленном scope.
  3. Производное преобразует upstream-материал: расчёт, расшифровка, выдержка, summary или отчёт.
  4. Решение и действие опираются на утверждения, ограничения и свидетельства, но не заменяют их.

Это не строгий конвейер. Реальная модель — ациклический граф типизированных связей: у решения может быть несколько upstream-источников, а один источник может породить несколько производных. Summary полезен, но он не становится источником только потому, что написан убедительно.

Не смешивать разные оси знания

Слова «мы знаем» часто скрывают разные вещи: прямое свидетельство, чью-то оценку, расчёт, предположение или принятое решение. Но их нельзя кодировать одной меткой. Достоверность, роль записи, способ создания и lifecycle — независимые оси.

Например, письмо подтверждает факт коммуникации: «клиент написал, что бюджет подтверждён». Оно не обязательно доказывает наличие денег или полномочия отправителя. Поэтому исходное утверждение остаётся claim, пока не выполнен названный критерий проверки. «Вероятность сделки 70%» — hypothesis; «работаем с этим сегментом до конца квартала» — decision с собственным lifecycle.

Полная нотация и двенадцать правил находятся в каноническом реестре и его русском представлении.

Как выглядит хороший ответ

Хороший ответ человека или AI не только сообщает результат. Он показывает границы знания:

По договору от 14 августа срок поставки — 30 сентября (verified). Риск переноса на октябрь — гипотеза менеджера из статуса от 20 августа (hypothesis). Подтверждённого изменения срока нет (unknown).

Такой ответ можно проверить и использовать для решения. Он полезнее гладкого текста, который скрывает неуверенность.

Минимальная практика, с которой стоит начать

Не нужно сначала строить AI-поиск, векторную базу или корпоративный граф знаний. Достаточно:

  1. Определить canonical owner для каждого вида существенных знаний проекта.
  2. Завести шаблоны для решений, встреч, инструкций и ключевых сущностей.
  3. Разделить evidence, canonical_for, steward и derived_from.
  4. Отправлять в чатах и письмах ссылки на записи, а не новые копии знания.
  5. Когда появится AI, настроить его на поиск в этой памяти и обязательные ссылки на свидетельства в ответах.

Эта дисциплина делает память одновременно человеческой, аудируемой и машинно-пригодной. AI затем не заменяет её, а ускоряет поиск, сопоставление и объяснение.

AI — следствие, а не начало

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

Нормы происхождения знаний опираются на W3C PROV, машинную пригодность — на FAIR Principles, а историю изменений — на практику version control.