Память агента для проверки счетов

Коротко

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

Контекст

Автор описывает практический прототип агента для отдела кредиторской задолженности. Исходная проблема: поставщик Meridian Logistics пять месяцев выставлял отдельную доставку, которую сотрудники одобряли, но с 1 августа 2026 года договор потребовал включать доставку в цену; агент должен распознавать, что новое условие отменяет прежний шаблон решений. Использованы Hindsight для памяти и LLM на Groq.

Главное

• Сценарий — счета Meridian Logistics: прежде отдельная доставка одобрялась, но договор от 1 августа 2026 года потребовал включать фрахт в цену заказа.
• Агент работает в пять этапов: обнаруживает расхождения Python-кодом, ищет похожие случаи, получает рекомендацию LLM на Groq, применяет ограничения на автономное одобрение и записывает исход решения человека.
• В Hindsight используется один общий банк памяти с тегами вида vendor:meridian, exception:... и decision:..., чтобы сохранять и правила компании, и сведения о поставщиках.
• Память хранится как объясняющие предложения на естественном языке; в записи включены дата, счет, расхождение и причина/результат проверки.
• Для каждой записи задается фактический timestamp; миссия банка указывает, что новый договор или политика перекрывает прежнюю практику.
• recall находит отдельные записи для проверки человеком, а reflect отвечает на вопрос с учетом истории и временных изменений; для reflect автор указывает budget="mid" и поиск по тегам с tags_match="any".
• Агент может одобрить счет самостоятельно лишь при наличии доказательств из памяти, высокой уверенности и минимум двух предыдущих случаев.
• Python-условие не дает считать разницу налога отдельной проблемой, если она вызвана несовпадающими строками счета и заказа.
• На тестовом счете за сентябрь память связала запрет отдельного фрахта с условием договора от 1 августа и двумя счетами после изменения; без памяти модель лишь направила бы случай человеку.
• Итоги: 7 из 8 верных решений против 5 без памяти; без человека обработаны 5 против 2; около 10 секунд против 1 секунды; стоимость теста — около $0.10 кредитов Hindsight.

Как сделано

Проверка каждой строки счета, цены и налога относительно заказа на закупку выполняется обычным Python, а не языковой моделью. Затем Hindsight ищет похожие случаи в едином банке памяти для финансовой команды; записи — датированные предложения на естественном языке с тегами поставщика, типа расхождения и решения. Каждой записи задают реальную дату, а назначение банка предписывает считать новые договоры и политики приоритетнее старых привычек.

Recall возвращает отдельные найденные записи, которые можно показать проверяющему; reflect формирует обоснованный ответ на вопрос, как прежние решения относятся к текущему случаю и не изменилось ли правило. LLM на Groq получает список расхождений и контекст памяти и выдает структурированную рекомендацию. Самостоятельное одобрение ограничено защитными условиями: нужны найденные доказательства, высокая уверенность и не менее двух прошлых случаев. Решения человека — одобрить, отклонить или передать на эскалацию — добавляются в память.

Отдельное условие в Python подавляет дублирующее сообщение о налоге, если расхождение налога вызвано несовпадением строк счета и заказа: налог сравнивается отдельно только при совпадении subtotal с точностью менее 0.001; порог налогового отличия — более 0.001.

Результаты

В тесте из восьми счетов с памятью число верных решений выросло с 5 до 7, а число счетов, обработанных без человека, — с 2 до 5. Решение с памятью занимало около 10 секунд против примерно 1 секунды без нее; основное дополнительное время приходилось на reflect. Загрузка 66 воспоминаний и запуск тестов обошлись примерно в $0.10 кредитов Hindsight. В проверке смены договора система правильно отвергла отдельную доставку в сентябрьском счете, сославшись на правило от 1 августа и два более поздних счета, соответствовавших новым условиям; версия без памяти просила проверить счет вручную, не объясняя историю.

Ограничения

Все данные для теста синтетические и воспроизводимые, а выборка из восьми счетов мала: автор считает результаты демонстрацией поведения, а не бенчмарком. Не приведены независимая оценка, длительный тест в реальном финансовом процессе или подробная проверка качества на других типах поставщиков и договорных изменений. Использование reflect заметно увеличивает задержку; результаты зависят от корректных дат, качественных записей и соблюдения защитных условий.

Что взять себе

• Храните фактические даты событий: без них агент не сможет надежно понять, что новое правило отменило прежнюю практику.
• Записывайте не только итог, но и причину решения понятным языком; используйте recall для прозрачной проверки фактов и reflect для вывода по истории.
• Оставляйте арифметические сверки детерминированному коду, а модели поручайте интерпретацию контекста и подготовку рекомендации.
• Заранее задавайте условия автономного одобрения и сначала тестируйте сценарий, где новое правило должно пересилить несколько старых одобрений.

Читать оригинал, если…

Откройте оригинал, если нужны полный код агента на GitHub, точные примеры вызовов Hindsight и подробности тестовых счетов.