← Все материалы

Гайд

ИИ всё забыл: чем история чата отличается от памяти приложения?

История диалога, постоянные сведения и актуальные документы — разные части памяти ИИ-приложения. Как устроить их в Чатиуме без путаницы.

Обновлено

Открытая книга, страницы документов и лупа над выделенным фрагментом

Вчера помощник знал название проекта, а сегодня спрашивает его снова. Или хуже: уверенно использует старый срок, который уже перенесли. Проблема «памяти ИИ» часто оказывается вопросом того, какие данные приложение сохранило и передало в новый запрос.

В Чатиуме можно разделить историю разговора, подтверждённые сведения о проекте и документы. Пользователь видит, что именно считается актуальным, и может исправить запись без попыток переубедить модель десятком сообщений.

Промпт

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

Три слоя, которые не стоит смешивать

История разговора хранит, что участники сказали. Карточка проекта хранит сведения, которые приложение считает действующими. Документы содержат основания и подробности. Одна и та же фраза в этих слоях может иметь разный статус.

Например, пользователь написал «возможно, запустимся в декабре». Это часть обсуждения, но ещё не утверждённая дата. Если автоматически сохранить её как обязательный срок, следующий ответ будет уверенно опираться на предположение.

Как продолжить разговор в Чатиуме

У startCompletion есть basedOnCompletionId для продолжения предыдущего диалога. Переданный идентификатор должен относиться к разрешённому пользователю разговору. Не принимайте произвольный ID из браузера без проверки принадлежности.

ctx даёт платформа, sourceText содержит новое сообщение, previousCompletionId взят из проверенной записи истории. done и failed — зарегистрированные app.function; они проверяют источник вызова: caller.type === 'plugin' && caller.appSlug === 'start'.

TypeScript
import { startCompletion } from '@start/sdk'

const { completionId } = await startCompletion(ctx, {
  model: 'deepseek/deepseek-v4.1-flash-1017',
  basedOnCompletionId: previousCompletionId,
  messages: [{ role: 'user', content: [{ type: 'text', text: sourceText }] }],
  onCompletionCompleted: done,
  onCompletionFailed: failed,
})

Метод возвращает ID новой задачи, а ответ приходит позже в обработчик. Этот короткий пример показывает продолжение, но не создаёт полноценное хранилище памяти и не обновляет карточку проекта автоматически.

Почему пересказ истории не равен фактам

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

В учебном проекте сначала обсуждали запуск в декабре, затем утвердили январь. Карточка факта должна показывать январь и ссылку на подтверждение внутри приложения. Декабрь остаётся в истории как прежний вариант, но не конкурирует с актуальной датой на равных.

Что полезно показывать пользователю

Добавьте небольшой блок «Использовано в ответе»: выбранный проект, актуальные факты и версии документов. Пользователь может заметить ошибку до того, как она превратится в очередную уверенную рекомендацию.

У факта полезны источник, дата обновления и статус: предположение, подтверждено, заменено. Конкретные статусы зависят от продукта; не усложняйте простую записную книжку десятками полей. Но возможность увидеть и исправить основание важнее обещания «помощник всё помнит».

Удаление тоже должно быть понятным

Удалить факт из карточки и удалить все его копии из истории — разные операции. Если продукт обещает забыть сведения, нужно определить, какие хранилища, резюме и поисковые индексы затрагиваются. Интерфейс не должен показывать полное удаление, когда исчезла только одна строка на экране.

Для обычного исправления достаточно сохранить новую версию и перестать использовать старую в новых ответах. Для удаления задайте отдельное поведение и проверьте его на следующем запросе. Это задача приложения, а не просьба модели «больше не вспоминать».

Как проверить память на практике

Создайте несколько коротких сценариев: новый факт, предположение, исправление, конфликт двух источников и удаление. После каждого проверьте, что попадёт в следующий запрос и что увидит пользователь.

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

Частые вопросы

Нужно ли передавать всю историю каждый раз?

Не обязательно. Способ зависит от задачи и контракта выбранного маршрута. Главное — сохранять нужные основания и понимать, какая информация реально используется.

Длинный контекст решает забывание?

Он позволяет передать больше данных, но не определяет их актуальность. Подробнее — в окне контекста.

Можно ли поручить модели обновлять факты?

Можно поручить подготовку предложений. Проверка прав, версии и правил изменения остаётся у приложения; см. подтверждение человеком.