Построение многосигнального рабочего процесса возобновления рисков с помощью n8n, детерминистической оценки и аудита Dual-LLM

Сигналы оттока никогда не живут в одном месте. Данные о контракте находятся в CRM. Показатели здоровья включены в платформу успеха клиентов. Настроения по билетам находятся в службе поддержки. Даты помолвки происходят совершенно в другом месте. Ни одна из этих систем сама по себе не скажет вам, действительно ли учетная запись находится под угрозой. Я построил в n8n рабочий процесс, который объединяет все четыре источника, оценивает риск с помощью детерминированной модели и вызывает LLM только тогда, когда оценка достаточно высока, чтобы оправдать затраты и риск галлюцинаций. В этом посте рассказывается об архитектуре, конкретных ошибках, которые научили меня больше всего, и о том, как я могу масштабировать ее с помощью одного веб-перехватчика. Почему бы просто не попросить LLM оценить риск? LLM хорош в написании последовательного описания рисков. Это не хороший бомбардир. Попросите одну и ту же модель дважды оценить один и тот же аккаунт, и число изменится. Это нормально для сводки, но не подходит для чего-то, что вызывает оповещение Slack для владельца учетной записи. Таким образом, сама оценка — это отдельная детерминированная услуга. LLM вмешивается только в том случае, если учетная запись уже превысила пороговое значение, и даже в этом случае его единственная задача — объяснять и рекомендовать, а не устанавливать число. Архитектура с первого взгляда Поток, от начала до конца: Webhook срабатывает на r