Самый простой способ сделать приложение LLM более умным — дать модели больше контекста.
Более сложная проблема — решить, какой контекст заслуживает присутствия.
Создавая Waada, я обнаружил, что постоянная память решает только половину проблемы.
Взгляд в прошлое мог дать мне надежную историю аккаунта и получить соответствующие доказательства, но мне все равно приходилось контролировать то, что достигало модели.
Это превратило оперативное составление бюджета в архитектурную проблему, а не в деталь настройки.
Больше истории — это не то же самое, что больше полезного контекста.
Waada занимается передачей продаж.
Исходный материал может включать электронные письма, разговоры в Slack, стенограммы звонков и встреч, аудио и информацию CRM.
Наивная архитектура могла бы объединить историю учетных записей и отправить ее в LLM.
Это сразу же создает несколько проблем: дублированные сообщения, нерелевантные разговоры, ограничения токенов, ограничения скорости провайдера, дорогие подсказки, ответы, которые сложнее объяснить.
Мне нужен другой поток: большая история учетных записей | v постоянная память | v отзыв по конкретному вопросу | v ограниченные доказательства | v LLM Важное слово ограничено.
Сначала нормализуются исходные данные.
Репозиторий представляет собой рабочую область TypeScript pnpm. packages/core содержит схемы, анализаторы, хранилище, интеграцию Hindsight, уровень LLM и функции агента. apps/web — это приложение TanStack Start.
Каждый импортированный источник становится взаимодействием: Interaction = { account: string; sourceId: строка; введите: «позвонить» | "электронная почта" | "слабый" | "встреча" | "примечание"; дата: строка; заголовок: строка; участники: строка[]; содержимое: строка; источник: "..."; } Это важно для управления контекстом, поскольку извлечение не может быть разумно ограничено, если каждый источник использует свое представление.
Уровень синтаксического анализатора обрабатывает сложность, зависящую от источника.
Слой памяти получает одну каноническую структуру.
Hindsight дает мне надежный источник для поиска.
Интеграция Hindsight изолирована в packages/core/src/memory/.
Каждому счету присваивается банк на основе его пула: const BankId = BankIdFor(account); Адаптер сохраняет содержимое взаимодействия, дату, контекст, идентификатор документа и метаданные.
Репозиторий Hindsight на GitHub и документация Hindsight описывают сам уровень памяти.
Для Ваады важным отличием является то, что я не рассматриваю Hindsight как вторую степень магистра права.
Это слой памяти.
Приложение запрашивает доказательства.
LLM рассуждает о доказательствах.
Такое разделение позволяет мне контролировать размер финального приглашения.
Руководство по векторизации памяти агента — полезный способ сформулировать то же различие: память дает агенту доступ к информации в ходе взаимодействий; это не означает, что каждый сохраненный элемент принадлежит каждому контекстному окну.
Реестр обязательств стал моим первым контекстным фильтром.
Реестр обязательств является хорошим примером того, почему поиск должен быть ориентирован на конкретную задачу.
Вместо того, чтобы вспоминать все, commitLedger() выполняет поиск, ориентированный на обещания.
Доказательства дедуплицируются и разбиваются на части перед структурированным извлечением. const hits = ждут отзыва PromiseEvidence (учетная запись); const Commitments = await ExtractCommitments( chunkAndDeduulate(hits)); вернуть sortLedger(обязательства); Это дает мне гораздо меньшую проблему рассуждения.
Для ответа модели не требуется вся учетная запись: какие обещания все еще открыты?
Ему нужны доказательства об обещаниях.
Это первый уровень контекстного бюджетирования: задайте более узкий вопрос.
Наземные мины — еще один контекстный фильтр.
Наземные мины ищут другой класс истории: возражения, деликатные темы и принятые соглашения.
Система хочет ответить: Что должен знать новый владелец, прежде чем вновь открыть сложную тему?
Этот запрос отличается от запроса фиксации.
Вот почему я избегал единственной универсальной функции «получить контекст учетной записи».
Разные операции требуют разных доказательств.
Результирующая структура: память учетной записи | +---- запросы обещаний ------> бухгалтерская книга | +---- запросы возражений ----> мины | +---- вопрос-запрос -------> ответ | +---- запросы временной шкалы -----> последние изменения Хранилище памяти является общим.
Цель извлечения — нет. 5000-тонный