Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Личную память ассистента научили поднимать старое обязательство, когда наступает связанное с ним событие, не запуская LLM при каждом запросе. На сложных примерах нужная запись попадала в первые пять результатов в 95,5% случаев, но препринт не рецензирован, а числа получил сам автор Jonathan Groff. Для продукта это даёт дешёвый базовый слой проактивной памяти, если команда готова отдельно вести журнал обещаний, сроков и условий.
Как обязательство входит в ранжирование
Обычный векторный поиск возвращает записи, похожие на текущий запрос по смыслу. Это не помогает, когда формулировки различаются: фраза «заменить клапан до приезда гостей» может не оказаться рядом с сообщением о том, что гости купили билеты.
Предложенная схема хранит обязательства отдельно от заметок. У каждой записи есть действие, дата или условие срабатывания, ссылки на связанные материалы и состояние: открыто, выполнено или отменено. Выполненные записи не удаляют, но они больше не влияют на выдачу.
Связи между обязательствами и заметками рассчитывают заранее. Во время запроса детерминированный обработчик проверяет даты и условия. Если обязательство сработало, связанные записи получают дополнительный вес; вызывать языковую модель для этого не нужно.
Схема смешивания выглядит так: score = cosine × (1 + W × b). Здесь cosine — смысловая близость запроса и записи, W — вес усиления, а b показывает, сработало ли открытое обязательство. Стандартный вес равен 0,3.
Умножение сохраняет ведущую роль смысловой близости. Усиление поднимает запись среди уже подходящих кандидатов, но не превращает явно постороннюю заметку в лучший результат. Для случаев, где обязательство лежит слишком глубоко в выдаче, предусмотрен более жёсткий вариант: сработавшую запись принудительно включают в набор кандидатов.
В полной архитектуре предусмотрены также важность, частота использования, положение в графе ссылок и давность изменения. В эксперименте эти сигналы отключили, чтобы измерить только вклад журнала обязательств.
Где журнал вернул пропущенные записи
Проверка охватила 175 синтетических задач по структуре TriggerBench. В диалогах сначала появлялось обязательство, затем шли отвлекающие сообщения и событие, которое должно было напомнить о ранней записи. Отдельные варианты проверяли перегруженный контекст и ситуацию, где обязательство уже выполнено.
Сложными считали диалоги, в которых исходная запись без усиления находилась в нижней половине выдачи. На них полнота первой пятёрки — доля задач, где нужная запись вошла в первые пять результатов, — выросла с 0 до 95,5%. На более простых задачах она достигла 100%, и усиление не ухудшило выдачу.
На 53 задачах с выполненным обязательством система ни разу не подняла закрытую запись ошибочно. Проверка без учёта состояния журнала срабатывала бы во всех этих случаях, поэтому результат обеспечило именно отслеживание выполнения, а не безопасные формулировки тестов.
Эксперимент сравнивал схему с обычным ранжированием по косинусному сходству. Журнал заполняли по готовой разметке, поэтому замеры показывают верхнюю границу качества ранжирования при правильно извлечённых обязательствах, а не качество всей системы.
Тестовая среда также уже реального продукта: один пользователь, хранилище Markdown, локальные векторные представления bge-micro-v2 и диалоги, составленные с помощью LLM. На настоящих пользовательских заметках и полном наборе TriggerBench эту схему в работе не проверяли.
Когда работу стоит учитывать в планах продукта
Менять архитектуру имеет смысл, если ассистент должен помнить обещания, сроки и условия, а не только отвечать по архиву. Журнал можно добавить поверх существующего векторного поиска: он не требует заменять хранилище или оплачивать дополнительный запуск LLM для каждого запроса.
Начать придётся не с формулы ранжирования, а со схемы данных. Продукту нужны явные сущности для действия, условия, срока, связанных заметок и состояния выполнения. Без надёжного закрытия записей журнал начнёт возвращать уже неактуальные обязательства.
Следующий риск — распознавание условий. Простой обработчик ключевых слов и дат сработал на 81% перефразированных событий. Если пользователь пишет непредсказуемо, команде понадобится более устойчивый обработчик на входе или отдельная проверка сложных запросов моделью.
Не стоит превращать журнал в замену обычному поиску. Естественные формулировки расходились достаточно сильно лишь в 17–29% протестированных сценариев. В большинстве случаев векторная близость уже находила нужную запись, поэтому новый сигнал полезен как страховочный слой для меньшинства дорогих ошибок.
Для выдачи, где достаточно показать несколько подходящих воспоминаний, подходит мягкое усиление. Если обязательство обязано занять первую позицию, безопаснее включать сработавшие записи в набор кандидатов принудительно: небольшой множитель не всегда поднимает глубоко спрятанную заметку.
Работа не доказывает готовность всей проактивной памяти. Она отделяет проверенную часть — ранжирование при идеальном журнале — от ещё не решённой для продукта задачи: как извлекать обязательства из живого потока сообщений и исправлять их по мере изменения планов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
