LendingTree запустила іпотечного AI-помічника

Що тут важливо не в технологіях, а в управлінні процесом

LendingTree не зробила один універсальний чатбот для всього. Система розділена на три ролі: Supervisor визначає намір користувача й план дій, Education пояснює іпотечні поняття, Matching збирає дані та звертається до внутрішніх API пропозицій, eligibility, rates, prequalification і профілю користувача.

Для бізнесу це корисний принцип: якщо запит одночасно містить пояснення і дію, їх краще розвести між різними частинами системи. Наприклад, користувач питає: What’s the difference between FHA and conventional, and which one fits me?. Supervisor бачить дві задачі: пояснити різницю та зробити персоналізоване порівняння. Перша йде до Education, друга — до Matching, а фінальна відповідь збирається в один діалог.

Другий приклад із джерела — короткі відповіді користувача на кшталт not sure або yes. Вони самі по собі погано шукаються в базі знань, тому система переписує їх у змістовний запит із урахуванням історії розмови. Третій приклад — ситуаційний опис: I’m a veteran with a 650 credit score looking to buy in Colorado Springs in the next 30 days. Тут відповідь залежить не від одного параметра, а від комбінації статусу, кредитного профілю, локації й строку.

Як має виглядати покроковий маршрут запиту

У LendingTree кожне повідомлення спочатку проходить Amazon Bedrock Guardrails: фільтрацію контенту, редагування PII та перевірку prompt threats. Паралельно окремий LLM-класифікатор контролює політики розмови. Це зроблено одночасно, щоб додатковий контроль не додавав затримки.

• Користувач пише запит у веб- або мобільному інтерфейсі.
• Вхідний текст проходить Guardrails і safety classifier.
• Supervisor завантажує історію розмови з PostgreSQL checkpointer.
• Supervisor аналізує намір через Amazon Nova Pro і формує план виконання.
• Запит маршрутизується до Education, Matching або обробляється напряму.
• Worker-агенти повертають свої результати через MCP.
• Supervisor збирає відповідь, знову пропускає її через Guardrails і віддає користувачу.
• Уся взаємодія зберігається, щоб наступне питання не починалося з нуля.

Окремий плюс такої схеми — аудит. Supervisor побудований у LangGraph як state machine: вузли виконують роботу, а ребра визначають наступний крок. Якщо діалог пішов неправильно, команда може побачити, який саме вузол ухвалив рішення.

Де прийом не працює без додаткової дисципліни

Multi-agent підхід не вирішує проблему сам по собі. У LendingTree early versions втрачали контекст під час передачі між агентами. Це виправили unified PostgreSQL-backed checkpointer і явною серіалізацією стану. Якщо немає спільної пам’яті розмови, користувач отримує відчуття, що його кожного разу просять почати заново.

Другий ризик — бази знань. У джерелі прямо сказано, що при кількох Knowledge Bases іноді з’являлась суперечлива інформація. Рішенням стали domain-based filtering і source prioritization: внутрішній контент LendingTree має пріоритет для product-specific questions, зовнішні ресурси — для загальної іпотечної освіти.

Третій ризик — guardrails. Ранні налаштування блокували легітимні питання, бо іпотечна термінологія спрацьовувала як небажаний контент. Це не одноразове налаштування, а постійне тюнінгування на реальних діалогах.

Що перевірити перед довірою до відповіді

Для керівника, фінансиста або юриста головне питання не «яка модель використана», а чи можна відстежити шлях відповіді. У LendingTree для цього використовуються Amazon CloudWatch logs і AWS X-Ray distributed tracing: команда бачить маршрут однієї розмови через усі три агенти, метрики по кожному агенту й таймінги.

• Чи відокремлені планування й виконання, щоб знайти помилкове рішення.
• Чи проходять вхідні й вихідні повідомлення safety checks.
• Чи редагується PII до того, як дані підуть далі.
• Чи зберігається історія розмови при handoff між агентами.
• Чи мають worker-агенти повну історію й intent summaries, а не лише останню фразу.
• Чи є пріоритет джерел, якщо Knowledge Bases суперечать одна одній.
• Чи можна оновити Education worker або його knowledge base без зміни Supervisor і Matching.
• Чи є маршрутизація складних випадків до human support і відведення off-topic conversations.

Типова помилка — використовувати найпотужнішу модель для кожного кроку. LendingTree зробила task-based model routing: Amazon Nova Pro застосовується для складного reasoning і critical classification, Amazon Nova Lite — для conversational responses і lightweight classification. Це знижує витрати без відмови від контролю там, де він потрібен.