ChatGPT Memory vs Projects vs custom GPT knowledge: де зберігати контекст

ChatGPT Memory використовуйте для небагатьох стабільних персональних уподобань, які справді мають допомагати в різних розмовах. Project підходить для довгої роботи з пов’язаними чатами, файлами, project sources та окремими instructions. Knowledge у custom GPT — це підготовлений builder-ом набір довідкових файлів, з яких GPT має діставати матеріал під час розмови. Ці surfaces можуть впливати на відповідь, але мають різних власників, межі й lifecycle.

Не обирайте їх за словом «пам’ять». Поставте чотири питання: хто додає контекст, для яких чатів він доступний, чи є джерело авторитетним і як прибрати його та похідні результати. Якщо потрібен чинний залишок, дозвіл або статус замовлення, жоден із трьох механізмів не повинен заміняти system of record. Модель має виконати свіжий lookup перед рішенням або дією.

• Особиста стабільна preference між чатами → Memory після явної згоди.
• Один тривалий дослідницький або командний контур → Project.
• Повторювана довідкова база для налаштованого assistant → custom GPT knowledge.
• Чинний бізнес-факт або permission → authoritative system, не conversational context.

OpenAI документує два окремі механізми: saved memories і reference chat history. Saved memory може бути додана явним проханням або збережена продуктом як корисна деталь; reference chat history дає змогу враховувати минулі розмови без перетворення кожної деталі на окремий запис. Доступність і controls залежать від plan, account та workspace settings, тому capability manifest має фіксувати фактичні перемикачі, дату й середовище тесту.

Це найширша з трьох меж: корисна preference може з’явитися в майбутньому не пов’язаному чаті. Тому не зберігайте як memory пароль, approval, точний медичний висновок, тимчасову ціну або правило компанії. Перевірка видалення має враховувати і saved memory, і чат, де інформація була повідомлена: видалення conversation та видалення memory є різними операціями. Temporary Chat корисний для окремої розмови без reference/update memory, але його retention contract слід читати в актуальній документації, а не трактувати назву як миттєве фізичне стирання.

У червні 2026 року OpenAI описала новішу memory architecture на основі dreaming: background process синтезує релевантний стан із багатьох розмов, а не чекає лише явної команди зберегти окремий факт. Компанія позиціонує цю зміну як спосіб краще переносити контекст, дотримуватися preferences і оновлювати часові факти. Rollout почався для Plus і Pro у США з подальшим розширенням, тому наявність функції не слід виводити лише з дати статті — перевірте фактичний account і memory controls.

Синтезована пам’ять доступна користувачу через memory summary: її можна переглянути, доповнити, виправити й дати вказівки щодо тем. Але summary є керованою проєкцією того, що продукт знає, а не обіцяним event log кожного source chat або повним passage-level provenance. Для важливої рекомендації все одно потрібні чинне джерело, timestamp і fresh lookup; персоналізована відповідь не доводить, з якої саме розмови походить кожна передумова.

Практичний контроль — versioned memory checkpoint. Перед чутливою або дорогою задачею перегляньте summary, зафіксуйте лише мінімальні релевантні preferences, позначте тимчасові факти expiry date і попросіть підтвердження критичних constraints. Після зміни — перевірте старе й нове формулювання в кількох нових чатах. Якщо стара деталь з’являється знову, не маскуйте її новою instruction: виправте memory surface і source conversation за документованими controls, а потім повторіть negative recall test.

• Background synthesis → ширший freshness і provenance test, а не автоматична довіра.
• Memory summary → user-visible review surface, не повний audit ledger.
• Тимчасовий факт → expiry та повторне підтвердження перед рішенням.
• Consequential answer → current source і explicit confirmation поверх personalization.

Project об’єднує chats, uploaded files, saved project sources та project instructions. OpenAI описує project memory як механізм, що дозволяє пов’язаним чатам використовувати контекст проєкту. Режим project-only memory створює вужчу conversational boundary: зовнішні saved memories не використовуються, а project chats не мають посилатися на conversations поза цим project. Конкретна поведінка залежить від способу створення, plan і workspace controls; її треба перевіряти негативними prompts.

Project-only не є повною security boundary. Shared roles, downloadable files, connected apps, зовнішні permissions, retention і копії артефактів живуть у власних контурах. Для важливої роботи запишіть owner, participants, memory mode, source revision, allowed apps, data class і exit date. Додайте canary phrase у сусідній project: запити всередині та поза цільовим простором не повинні її відтворювати. Такий тест виявляє регресію, але не доводить математичної ізоляції.

• Default memory → перевірте, який зовнішній контекст може враховуватися у вашому plan.
• Project-only memory → тестуйте відсутність recall із зовнішніх чатів і projects.
• Shared project → перевірте roles, links, downloads, apps і offboarding окремо.
• Move chat → повторно перевірте instructions, sources і очікувану memory boundary.

Knowledge у custom GPT додає builder і призначає як довідковий матеріал. Instructions визначають поведінку, а knowledge files постачають content для retrieval. Це корисно для handbook, product guide або policy corpus, який змінюється нечасто. Якщо правила часто оновлюються, ручне завантаження файлів створює freshness risk: потрібні owner, source-of-truth URL, corpus version, review date і контроль застарілих тверджень.

Розмови з GPT не слід проектувати так, наче він успадковує персональну saved memory або пам’ятає попередню conversation. OpenAI окремо документує відсутність memory у custom GPTs як загальний механізм між розмовами. Якщо workflow потребує durable customer state, створіть авторизований зовнішній store або app contract із явними read/write rules; knowledge file не є прихованою CRM. Builder також має перевірити sharing, actions/apps і правила використання conversation data для конкретного plan.

Почніть із найменшої persistence. Одноразовій задачі достатньо звичайного або Temporary Chat. Повторюваній особистій preference може бути достатньо saved memory. Серії взаємопов’язаних артефактів потрібен Project, бажано з явно обраним memory mode. Стабільному повторюваному assistant для багатьох користувачів потрібні versioned instructions і knowledge. Не дублюйте один факт у всіх surfaces: після виправлення ви не знатимете, яка копія перемогла.

Створіть context receipt для критичної відповіді: account/workspace, surface, memory mode, project ID, GPT version, source files і revisions, enabled apps та timestamp. Він не розкриває внутрішнє reasoning, але дозволяє відтворити доступний evidence envelope. Якщо відповідь впливатиме на рішення, вимагайте citation або passage-level support із чинного джерела; recall знайомого формулювання не доводить його актуальність.

• Найвужча boundary, що завершує задачу, має перевагу.
• Один authoritative owner на кожний факт або документ.
• Personalization не надає permission і не замінює fresh lookup.
• Кожний persistent surface має export/delete/offboarding test.

Побудуйте синтетичний набір із нейтральної preference, чутливої деталі, зміненого факту, двох суперечливих документів і canary для кожної boundary. Запустіть однакові prompts у звичайному чаті, Temporary Chat, default Project, project-only Project і двох версіях custom GPT. Очікування задайте наперед: recall, abstain, cite current source або refuse. Не використовуйте реальні секрети чи персональні дані для leakage test.

Окремо проведіть lifecycle test: змініть preference, замініть source, заберіть participant, видаліть memory, archive/delete project і оновіть knowledge corpus. Після документованого propagation window перевірте user-visible recall, search/retrieval і доступ колишньої ролі. Фіксуйте unexpected recall, stale-source rate, unsupported claim, cross-boundary canary exposure, reviewer corrections і deletion exceptions. Один успішний prompt не доводить boundary; критичний leakage не компенсується зручністю.

Для особистого використання почніть з audit поточних saved memories, вимкніть непотрібний reference history і створюйте окремий Project лише для тривалої роботи. Для команди спершу погодьте data classes, owner, sharing roles, retention, apps, review cadence та incident contact. Custom GPT опублікуйте вузькій тестовій групі з corpus manifest; Project — з synthetic sources і canary; personal memory не використовуйте як канал розповсюдження organizational policy.

Rollback має окремо вимикати recall surface, доступ користувачів і зовнішні integrations. Видаліть або замініть неправильний source, очистьте відповідну memory за документованою процедурою, відкличте sharing і повторіть негативний test. Не заявляйте про повне provider-side стирання без відповідного contract evidence. Якщо результат уже потрапив у документ, ticket або system of record, його треба виправляти там окремо: видалення контексту не відкочує створені ним зовнішні артефакти.

Поточна документація OpenAI дозволяє змінити Project між default і project-only memory у settings, але зміна може застосовуватися кілька годин. Це створює перехідний стан: збережене значення в UI ще не доводить, що старий context path перестав впливати на нові відповіді. Під час міграції заморозьте consequential work, зафіксуйте account/workspace, project ID, previous mode, requested mode, requestedAt і observed effectiveAt, а потім перевірте boundary у нових chats після заявленого propagation window.

Тест має містити щонайменше три синтетичні canary: один у звичайному chat поза Projects, другий у сусідньому default Project і третій у цільовому Project. Після переходу до project-only цільовий chat має використовувати лише свій canary; зовнішній chat не повинен відтворювати project canary. Після повернення до default очікувана поведінка залежить від plan і workspace settings, тому запишіть її як observed capability, а не універсальне правило. Видаліть test chats після перевірки за окремим retention procedure.

Не використовуйте mode switch як спосіб очистити сам Project. Перехід до project-only прибирає інформацію цього Project із memory, що використовується поза ним, але chats і files залишаються всередині та можуть далі давати context. Для granular exclusion треба видалити або перемістити конкретну conversation; списку окремих project memories, аналогічного personal memory list, OpenAI не обіцяє. Якщо треба зберегти accepted artifact, експортуйте його до authoritative repository до destructive cleanup і не переносіть повний transcript за замовчуванням.

• Request → зафіксувати old mode, new mode, actor, time і UI receipt.
• Quarantine → не приймати consequential output до завершення propagation window.
• Verify → new sessions, three canaries, positive recall і negative cross-boundary tests.
• Reconcile → chats, files, derived artifacts і зовнішні copies мають окремі lifecycles.
• Rollback → повернути last-known-good mode лише після повторного boundary test.

Shared Project автоматично використовує project-only memory і не підтягує personal memory, custom instructions або context учасника ззовні. Водночас кожен participant бачить спільні chats, files та instructions, а завантажений учасником матеріал може впливати на відповіді для інших. Отже, conversational isolation від зовнішніх чатів не є least-privilege всередині Project: admission нового member фактично розширює аудиторію всього context hub.

Розділіть chat, edit і owner authority. Chat role дає перегляд та взаємодію з наявним контекстом. Edit role також дозволяє змінювати instructions, додавати або прибирати files та запрошувати інших, тому може змінити evidence envelope майбутніх відповідей. Owner керує membership, permissions, назвою та видаленням Project. Перед rollout перевірте matrix `role → view chat → download file → add/remove source → change instructions → invite → remove member → delete project`; не виводьте право з назви workspace group без фактичного тесту.

Offboarding drill починається з inventory participants, groups, links, files, instructions, branched chats і accepted artifacts. Видаліть test member, відкрийте fresh session під колишньою identity та перевірте project, direct chat links і downloads; окремо перевірте downstream copies, бо revoke доступу до Project їх не повертає. Delete Project є destructive final step: OpenAI описує видалення його chats, files та instructions для всіх учасників як незворотне в UI, а provider-side retention має винятки й окремий строк. Тому спершу збережіть лише дозволені records, отримайте approval, виконайте delete і зафіксуйте postcondition без заяви про миттєве фізичне стирання.

• Chat → споживання спільного context, але не право змінювати corpus.
• Edit → mutation instructions/files і audience expansion через invites.
• Owner → membership, permissions і destructive project lifecycle.
• Removal PASS → fresh-session access denied; downstream copies reconciled окремо.
• Deletion PASS → approved export, project unavailable, retention caveat recorded.