18.5 Запись приложения не равна весам модели

Context, cache и долговременные записи — не одно и то же

Model weights меняются только training/update. Conversation context передаётся в текущем request; KV-cache ускоряет вычисление этого context; application memory хранит выбранные записи вне модели. Называть все три «памятью ИИ» без уточнения опасно: у них разные lifetime, доступ и риски.

Working memory можно ограничить последними k events. Durable fact требует явного purpose, consent/provenance, scope пользователя, срока хранения и механизма удаления. Summary является новой производной записью и может исказить исходные сообщения; source events или ссылка на них должны сохраняться согласно policy.

W_t=\operatorname{tail}_k(E_{\le t}),\qquad D=\{(fact,source,scope,created,expires)\}.

Что показывает модель. Lifecycle показывает create/read/update/expire/delete и actor для каждого события. Retrieval из memory проходит те же access filters, что документы. Пользователь видит, что сохранено, зачем и до какого срока; кнопка очистки удаляет primary и производные indexes согласно документированной процедуре.

Граница применимости. Больше истории не всегда лучше: stale или неверная запись ухудшает ответ. Удаление из UI не доказывает удаление backups, logs и caches. Текущий курс ничего не сохраняет и не подключает аккаунты; production memory нельзя добавлять без data audit и privacy review.

events_18e=[(1,'a'),(2,'b'),(3,'c'),(4,'d')]; limit_18e=3 working_18e=events_18e[-limit_18e:] durable_18e=[]; consent_18e=False if consent_18e: durable_18e.append({'fact':'demo','source':4}) assert working_18e==[(2,'b'),(3,'c'),(4,'d')] and durable_18e==[]