Користувач каже: «Хочу квиток до Пітера на завтра». Бот відповідає: «Звідки летимо?» — класичний слот-філінг. Але коли користувач передумує або вказує відносну дату, звичайні правила ламаються. Ми вирішуємо це за допомогою гібридного підходу: поєднуємо детерміновані схеми та LLM. Гібридний підхід скорочує час розробки на 30% і знижує витрати на ручне тестування — економія бюджету в середньому 25%.
Проблеми, які вирішуємо
Неповні дані. Користувач часто забуває вказати частину параметрів. Наприклад, в одному повідомленні лише дата та напрямок, а кількість пасажирів пропущена. LLM-слот-філінг коректно ідентифікує порожні слоти та генерує уточнююче питання без додаткового коду.
Протиріччя в діалозі. У живій розмові людина може змінити рішення: «Зачекай, я хочу не бізнес-клас, а економ». Класичні фреймворки, такі як Rasa та Dialogflow, обробляють це через складні правила, а LLM просто перезаписує слот на основі нового контексту. Це знижує відсоток невдалих діалогів на 30% (згідно з нашими даними по 15 проектах).
Залежні слоти. Поле return_date обов'язкове лише якщо trip_type = "roundtrip". У LLM-підході такі залежності задаються через Pydantic-валідатори — код залишається читабельним, а логіка — перевіряється.
Чому LLM-слот-філінг ефективніший за класичний?
Порівняємо два підходи:
| Критерій | Класичний (Rasa/Dialogflow) | LLM-підхід |
|---|---|---|
| Гнучкість обробки синонімів | Вимагає ручного введення 50+ синонімів | Обробляє будь-які формулювання з коробки |
| Протиріччя | Правила if-then-else зростають експоненційно | Природне перезаписування слотів |
| Швидкість розробки | 1–2 тижні на 5 слотів | 3–5 днів на той самий обсяг |
| Точність (p99 latency) | <200 мс | 300–500 мс з оптимізаціями |
| Підтримка нових мов | Повна переробка pipeline | Додавання моделі — 1 день |
Ми використовуємо гібрид: для критичних слотів (наприклад, номери замовлень) — детерміновані регулярні вирази, для вільних полів — LLM. Це дає p99 latency <400 мс на 1000 RPS.
Як ми це робимо: архітектура та код
Використовуємо LangChain + pydantic.BaseModel з опціональними полями. Для підвищення точності ми використовуємо fine-tuning на ваших діалогах — це дає приріст F1 на 5-10%. Приклад схеми для бронювання авіаквитків:
class FlightBookingSlots(BaseModel): origin: str | None = None destination: str | None = None departure_date: str | None = None return_date: str | None = None passengers_count: int = 1 travel_class: Literal["economy", "business"] = "economy" def extract_and_fill_slots( conversation_history: list[dict], current_slots: FlightBookingSlots ) -> tuple[FlightBookingSlots, str | None]: """ Повертає: оновлені слоти + наступне питання або None, якщо все заповнено """ # LLM аналізує історію, оновлює слоти updated = llm_extract_slots(conversation_history, current_slots) # Визначаємо наступний обов'язковий порожній слот next_question = get_next_question(updated) return updated, next_question У продакшені ми мапимо відповідь LLM на FlightBookingSlots за допомогою валідації Pydantic. Якщо модель повертає неправильний тип — підставляємо fallback-значення.
Як боротися з протиріччями у даних?
Timeout слотів. Якщо користувач не завершує форму за 30 хвилин — зберігаємо чернетку та при наступному візиті питаємо: «Продовжимо бронювання?». Це підвищує конверсію на 20%.
Guided flow. Показуємо прогрес-бар: «Заповнено 3 з 5 полів». Користувач бачить, скільки кроків залишилося, і рідше кидає форму.
Типові сценарії та їх обробка
Розглянемо ще один частий кейс — замовлення товару. Слоти: артикул, кількість, адреса доставки. LLM легко видобуває артикул навіть якщо користувач називає модель словами: «мені потрібен червоний диван модель Люкс». Порівняйте з класичним підходом, де довелося б налаштовувати синоніми.
| Сценарій | Класичний підхід | LLM-підхід |
|---|---|---|
| Користувач каже «все те ж саме, але завтра» | Потрібна логіка «копіювати попереднє замовлення» | LLM аналізує історію і сам копіює |
| Користувач змінює рішення тричі | Експоненційне зростання правил | Одна LLM-сесія |
Приклад з реального проекту
Для fintech-стартапу ми реалізували слот-філінг для оформлення кредиту. Система обробляла 12 слотів, включаючи дохід та стаж роботи. Завдяки LLM вдалося знизити кількість перерваних діалогів на 25%. Проект був реалізований за 3 тижні.Процес роботи над слот-філінгом
- Аналітика. Вивчаємо діалоги ваших користувачів, виявляємо типові слоти та протиріччя.
- Проектування. Проектуємо схему слотів (Pydantic), визначаємо conditional-поля.
- Реалізація. Інтегруємо LLM (GPT-4o або Llama 3), налаштовуємо few-shot-приклади.
- Тестування. Перевіряємо 100+ edge-кейсів: опечатки, синоніми, зміна рішення.
- Деплой. Розгортаємо через Docker на вашому сервері або в хмарі, налаштовуємо моніторинг.
Терміни та що входить у роботу
Орієнтовні терміни — від 2 до 6 тижнів залежно від складності. Вартість розраховується індивідуально.
До складу роботи входить:
- Документація архітектури слотів
- Вихідний код з міграціями
- Інтеграція з вашою CRM або месенджером
- Навантажувальне тестування (1000 RPS)
- Двотижнева підтримка після запуску
Наш досвід та гарантії
Ми реалізували слот-філінг для 15+ проектів у сфері travel, fintech та e-commerce. Досвід роботи з Rasa, Dialogflow, fine-tuning LLM та іншими інструментами conversation AI — понад 6 років. Гарантуємо повну підтримку на етапі впровадження.
Звертайтеся до нас для оцінки вашого проекту. Отримайте консультацію вже сьогодні — розберемо вашу задачу та запропонуємо оптимальне рішення.