…
ПРОТОК
войти →

Как собрать надёжный LLM-воркфлоу для ежедневного мониторинга кредитных условий

Как построить надёжный LLM-воркфлоу для ежедневного мониторинга кредитных условий: снимки данных, четыре точки вызова модели, расчёты в коде и 14 проверок перед публикацией.

Ежедневный мониторинг банковских условий — это не просто задача «прочитать несколько страниц и написать сводку». Данные меняются в таблицах, PDF-файлах, блоках с примечаниями и формах, а важные различия часто скрыты в деталях: сроке действия ставки, комиссии, минимальной сумме или требованиях к клиенту.

Надёжный LLM-воркфлоу должен разделять две задачи. Модель извлекает информацию из текста и формулирует объяснение. Код отвечает за загрузку страниц, сравнение снимков, арифметику, структуру результата и автоматические проверки. Такой подход снижает риск того, что убедительно написанный текст будет содержать неверное число.

Из чего состоит конвейер

Практичный процесс можно разделить на несколько последовательных этапов:

  1. загрузка страниц и документов;
  2. нормализация текста;
  3. извлечение условий в структурированный формат;
  4. сравнение с предыдущим снимком;
  5. расчёт последствий изменений;
  6. подготовка сводки;
  7. проверка результата перед публикацией.

Ключевой принцип — языковая модель не должна самостоятельно выбирать следующий шаг. Ей передают конкретную операцию и ограниченный набор данных. Например, на этапе извлечения она заполняет поля product, rate, term и source_text, а не решает, какие страницы нужно посетить или какие изменения считать важными.

Это делает процесс воспроизводимым. Если на выходе обнаружена ошибка, можно понять, где она появилась: при загрузке, извлечении, сравнении или генерации текста.

Снимок данных важнее красивого ответа

Для ежедневного мониторинга нужно сохранять не только итоговую заметку, но и исходный снимок каждого документа. Минимальная запись может выглядеть так:

{
  "url": "адрес страницы",
  "collected_at": "2025-01-15T09:00:00Z",
  "content_hash": "...",
  "text": "...",
  "extracted": {
    "product": "кредитная карта",
    "rate": 29.9,
    "term_months": 12,
    "commission": 0
  }
}

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

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

Где нужна модель, а где достаточно кода

Модель полезна там, где требуется понять смысл текста: выделить условие из длинного документа, связать примечание с конкретным продуктом или кратко объяснить изменение. Но арифметика и контроль формата должны оставаться в обычном коде.

Например, если изменились ставка и срок, расчёт переплаты выполняется отдельно:

old_payment = calculate_payment(old_rate, principal, old_term)
new_payment = calculate_payment(new_rate, principal, new_term)
delta = new_payment - old_payment

assert isinstance(delta, (int, float))

Модель получает уже рассчитанные значения и формулирует объяснение: что изменилось, для какого сценария и какова разница. Она не должна самостоятельно подставлять числа в формулу из текста, если эти числа можно проверить программно.

Такое разделение особенно важно для финансовой тематики. Ошибка в одном знаке, периоде или разряде меняет вывод, а естественный язык может скрыть проблему за уверенной формулировкой.

Четыре точки вызова модели

В компактном воркфлоу достаточно использовать модель в четырёх местах.

Извлечение

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

Классификация изменения

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

Подготовка разбора

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

Редактура выпуска

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

Набор проверок перед публикацией

Оценивать выпуск лучше не общим впечатлением, а набором бинарных критериев. Например:

  • у каждого изменения есть подтверждающий фрагмент;
  • у каждой строки есть ссылка на исходную страницу;
  • все числа присутствуют в сохранённом снимке или расчёте;
  • процентные значения имеют корректный период;
  • арифметика совпадает с результатом кода;
  • старое и новое значения не перепутаны;
  • продукт однозначно определён;
  • отсутствуют неподтверждённые выводы;
  • обязательные поля JSON заполнены;
  • выпуск не содержит дубликатов;
  • дата сбора указана корректно;
  • текст укладывается в заданный формат;
  • неработающие страницы отмечены отдельно;
  • итоговая сводка проходит ручную выборочную проверку.

Каждую проверку удобно сохранять как true или false. Тогда качество видно в динамике: можно сравнить выпуски за неделю и найти этап, который чаще всего даёт сбой.

Как выбрать модель и контролировать расходы

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

На дату публикации в Протоке, например, для извлечения структурированных полей можно рассмотреть GLM-5.2: вход стоит 3,66 ₽, выход — 11,50 ₽ за 1M токенов. Для короткой классификации доступен GLM-5.3 Flash: 11,76 ₽ за вход и 39,18 ₽ за выход за 1M токенов. Если требуется более сложный разбор документа или аккуратная редактура, можно использовать GLM-5.3 — 20,47 ₽ за вход и 64,34 ₽ за выход за 1M токенов.

Для сценариев, где важны более длинные рассуждения, на дату публикации доступны GPT-5.6 Luna по цене 8,57 ₽ за вход и 51,26 ₽ за выход за 1M токенов, а также GPT-5.6 Terra — 27,36 ₽ и 164,09 ₽ соответственно. Конкретный выбор стоит делать по результатам проверок, а не только по названию модели: более дорогой вызов не заменяет валидацию чисел.

В примерах кода параметр model должен содержать slug модели латиницей, как в котировках Протока. Например:

from OpenAI import OpenAI

client = OpenAI(
    api_key="",
    base_url="https://dualchat.pro/v1"
)

response = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[
        {"role": "system", "content": "Верни только JSON по заданной схеме."},
        {"role": "user", "content": source_text}
    ],
    temperature=0
)

Ключ вида sk-dc-… создаётся в кабинете Протока, в разделе «Ключи». Клиенты, совместимые с OpenAI и Anthropic SDK, подключаются заменой base_url на https://dualchat.pro/v1. Оплата списывается по факту за каждый запрос, а пополнить баланс можно картой онлайн, по счёту для организации или через СБП.

Что даёт такая архитектура

Главный результат — не один удачный текст, а управляемый процесс. Снимки позволяют восстановить историю, код защищает арифметику, модель экономит время на извлечении и объяснении, а набор проверок делает качество измеримым.

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

Вывод

Надёжный LLM-воркфлоу строится вокруг разделения ответственности: модель работает с языком, код — с данными и правилами. Для ежедневного мониторинга особенно важны сохранённые снимки, структурированный JSON, расчёты вне модели и автоматические проверки перед публикацией.

Попробуйте собрать такой процесс через API Протока: сравните модели и котировки на https://dualchat.pro/models?utm_source=blog&utm_medium=article&utm_campaign=nadezhnyy-llm-workflow-dlya-monitoringa-kreditnyh-usloviy, изучите документацию на https://dualchat.pro/docs?utm_source=blog&utm_medium=article&utm_campaign=nadezhnyy-llm-workflow-dlya-monitoringa-kreditnyh-usloviy и подключите первый сценарий через https://dualchat.pro?utm_source=blog&utm_medium=article&utm_campaign=nadezhnyy-llm-workflow-dlya-monitoringa-kreditnyh-usloviy.

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