Експертиза · Інтеграції та автоматизації

Щоб ваші системи розмовляли між собою, без того щоб хтось повторно вводив ті самі дані.

Ми з’єднуємо систему запису, магазин, CRM, таблиці та канали повідомлень так, щоб агент або заплановане правило могли читати й писати в них у реальному часі. Ключі залишаються на сервері, інструменти мають прописані межі, а кожна інтеграція тестується також на випадку, коли інша система падає.

Обговорити проєкт

Вже збудованоВласні інтеграції, написані й запущені, виміряні сьогодні в коді: конектор для системи записів Altegio (946 рядків, із шістьма інструментами, відкритими агенту), конектор CRM amoCRM (2.888 рядків у платформі повідомлень, плюс 12 функцій сервера в голосовій платформі), Bitrix24 (903 рядки, плюс 4 функції), Google Sheets (615 рядків, плюс 10 функцій і окремий сервісний обліковий запис), живий каталог поверх магазину (сервіс платформи, 318 рядків), сповіщення про lead у Telegram (1.776 рядків), SMS через Infobip із антизловживальними лімітами, заплановані автоматизації (1.088 рядків) і чат-канал локальної платформи оголошень (2.459 рядків). У виконанні агент може викликати 15 типів внутрішніх інструментів, окрім інструментів через webhook і інструментів із власним кодом, запущеним в ізоляції.

Інтеграція — це не логотип на сторінці. Це відповідь на дуже конкретне запитання: чи може цю систему читати і записувати в реальному часі, хто, з якими правами, і що відбувається, коли вона не відповідає? Тому наше перше запитання для будь-якої інтеграції — не «з яким API», а «які публічні ворота вона має». Іноді відповідь повністю змінює вартість роботи: магазини на WooCommerce, наприклад, публічно відкривають API магазину, який не вимагає жодного ключа споживача, тож новий клієнт підключається лише з адресою свого сайту — не з обліковими даними, які треба згенерувати, надіслати, а потім ротаувати.

У нашій платформі меседжингу інструмент, який агент може викликати під час розмови, має один із трьох типів: виклик webhook, власний код, запущений ізоляційно, або внутрішній інструмент платформи. Внутрішні інструменти — це ті, які ми надаємо перевагу, бо вони тримають ключі поза базою даних: сьогодні їх п’ятнадцять, від читання сторінки й запису в таблицю до доступності та створення запису, надсилання SMS і запиту каталогу продуктів.

Різниця між інтеграцією, яка тримається, і тією, що ламається, майже завжди криється в дрібницях, виявлених на практиці. Система запису нічого не повертає, якщо запитати години спеціаліста для послуги, яку він не надає — послуга і спеціаліст завжди ходять разом. Та сама система відповідає відмовою, якщо запит приходить із типовим заголовком HTTP-бібліотеки, тож кожен запит має явно ідентифікуватися. Магазин може повертати нульову ціну для товарів із варіантами, а пошук за порожніми словами повертає весь каталог. Є десять таких деталей на кожну інтеграцію, і жодна з них не є в документації.

Понад інтеграціями стоять автоматизації: правила, що виконуються в часі, а не на чиєсь запитання. У нас вони заплановані через планувальник у процесі — повторне відкриття розмов без відповіді, перше повідомлення новому контакту, призупинення й повторний запуск агента після робочого часу — кожна зі своїми лічильниками, щоб було видно, скільки було запусків, скільки повідомлень пішло, скільки було пропущено і чому. Автоматизація без лічильника — це автоматизація, про яку ви не можете сказати, чи працює вона.

Прозора автоматизація — інтеграції, які можна перевірити · відео румунською, із субтитрами та розшифровкою українською

Повна транскрипція

Давайте одразу перейдемо до суті. Сьогодні ми розберемо технічні й, чесно кажучи, часто ігноровані реалії автоматизації через асистентів на базі штучного інтелекту. Ми зосередимося на дуже прагматичному підході до платформи iCat.md, розробленої Mega Promoting. Сьогодні в нас немає маркетингових обіцянок і, звісно, немає розпливчастих концепцій. Ми говоримо про платформу, яка прямо зараз у продакшені, з функціональністю, поясненою безпосередньо з архітектури бази даних. Тож давайте подивимося, як насправді виглядає повністю прозора автоматизація. План цього розбору простий і по суті. Ми пройдемося по проблемі часу, механіці технології, реальному кейсу, чітких межах системи, управлінні даними та наступних кроках. Починаємо з першого розділу, проблеми часу. Ви всі знаєте це надзвичайно дратівливе запитання? Чому ціла команда підтримки щодня втрачає купу годин, вручну пишучи відповіді на абсолютно ті самі п’ять запитань?

Інформація вже є на сайті компанії, але попри це клієнти продовжують знову й знову запитувати деталі. І саме в цьому суть нашої проблеми. Без відповідного технічного рішення всі ці повторювані запити просто забивають директ, неважливо, чи це Instagram, чи Messenger. Унаслідок цього відповіді масово затримуються для клієнтів, у яких справді складна проблема, запити губляться в морі повідомлень, а весь процес підтримки стає фактично чорною скринькою, яку не можна ні перевірити, ні виміряти. Частина друга. Як насправді працює технологія під капотом? Ось у чому справа. Налаштування платформи базується на чотирьох дуже логічних кроках. Спочатку ми під’єднуємо канали комунікації, використовуючи власний код. Потім індексується вся база знань. Далі йде прив’язка інструментів, які можуть виконувати дії у ваших наявних системах. А наприкінці, і ця деталь є критичною, налаштовується чіткий маршрут, прямо записаний у базі даних, через який бот передає розмову людині-оператору.

Усе це — видима й повністю налаштовувана система. А тепер абсолютно захопливий момент. Ми тут не говоримо навмання. Це налаштування, витягнуті прямо зі схеми бази даних. Коли асистенту потрібна відповідь, він використовує так званий гібридний пошук. За замовчуванням алгоритм витягує 5 фрагментів тексту, застосовує жорсткий поріг схожості 0-70 і надає 30% ваги точному збігу слів. Усе обробляється через модель Text Embedding 3 Small. По суті, система перетворює слова на математичні концепти, щоб точно вловити контекст. Відповіді — не ворожіння, а чиста математика. Запам’ятайте це число. 15. Це абсолютна технічна межа в системі. Воно означає максимальний час, у секундах, який виділяється на запуск будь-якого інструмента або пошуку. Якщо зовнішня інтеграція триває довше, скажімо, їй потрібно 40 секунд, ми не можемо залишати її в live-потоці розмови.

Її потрібно обробляти асинхронно, інакше природний ритм діалогу повністю зламається. І ще дещо. Люди пишуть у чат ривками, правда? 2, 3, 4 короткі повідомлення, надіслані одне за одним. Щоб не звести систему з розуму, є буфер конкатенації на 15 секунд. Усе, що входить у це вікно, склеюється і стає одним чітким запитом. Ба більше, на платформах на кшталт Meta, де іноді трапляються дублікати повідомлень, надіслані помилково, система застосовує 120-секундний фільтр пам’яті за ID повідомлення. Так клієнт отримує одну цілісну відповідь, а не 3 хибні сповіщення. Розділ третій. Подивімося на реальний кейс. Маємо цей класичний e-commerce сценарій. Є онлайн-магазин із бездоганним каталогом на сайті, але він отримує лавину приватних повідомлень в Instagram і Messenger? Ще є в наявності? Яка ціна? Тут інтеграцію зробили елегантно, під’єднавши асистента безпосередньо до публічного інтерфейсу Store API від WooCommerce.

Без ускладнень із безпекою, живий каталог магазину просто передали в руки асистента. Але тут і проявляється технічна реальність кожної платформи, навіть під парасолькою тієї самої компанії, як Meta. У Messenger асистент може показувати вам чудові каруселі продуктів. В Instagram бот відповість вам лише текстом і максимум одним простим зображенням. Чому? Просто тому, що Meta не підтримує ті загальні шаблони в Instagram. Асистент має грати точно за правилами каналу, де він працює. Ось тут критична точка. Що відбувається, коли бот не справляється? Ну, у базі даних розмова має явні стани. Коли запит виходить за межі каталогу, лінія розмови одразу переходить зі стану бота в стан людини. І геніальність у тому, що система обліковує час, за який відповідає людина-оператор, чітко позначаючи все: статус OK, попередження або прострочений термін.

Увесь контекст передається людині, без того щоб десь по дорозі зникло абсолютно щось. Розділ A4 Обмеження системи. Бо прозорість означає знати, чого вона не може зробити. Є кілька жорстких обмежень, які ми маємо прийняти. Ви не можете надсилати proactive-повідомлення у WhatsApp, якщо минуло більше ніж 24 години від повідомлення клієнта. Meta видасть помилку, точніше помилку 131047, і дія завершиться невдачею. Система не робить РPDF-файли, не читає вкладення. Щодо іноземних мов, переклади працюють лише в один бік. Клієнт отримує перекладену відповідь, але оператор бачить оригінал. І, хоча інтеграція з 999.md працює, вона неофіційна й базується на cookie у браузері. Якщо платформа змінить свої механізми, з’єднання впаде і вимагатиме ремонту. І обов’язково запам’ятайте ось що. Асистент — це дзеркало ваших даних. Неправильна ціна на сайті гарантовано стане неправильною ціною в розмові.

Він діє як читач, а не як менеджер магазину. Він не виправлятиме з власної ініціативи людські помилки в каталогах. Технічна інфраструктура тут не іграшка. Усе тримається на приватному сервері Microsoft Azure. Ми говоримо про надзвичайно структуровану базу даних MySQL, з понад 80 таблицями, чітко змодельованими для розділення каналів і для аудиту. Ключі доступу для WhatsApp, які є надчутливими, використовують шифрування fernet. Крім того, на рівні вебу домени для чат-віджета додаються вручну до білого списку. Ніхто не підключається без явного дозволу. Але ми маємо розглянути очевидну реальність. Люди писатимуть у ті чат-вікна всілякі персональні дані, номери телефонів, адреси. Технічно неможливо заблокувати вільне текстове поле. Тож рішення є адміністративним. Коли ви впроваджуєте таку систему, вам потрібні з першої секунди чіткі політики зберігання, які точно визначають, хто має право бачити ці дані і як довго вони зберігаються.

І ми дійшли до пункту 6. Наступні кроки. Центральну філософію всієї системи можна підсумувати цією цитатою. Розумний асистент — це не той, хто складає вірші або гарно пише, а той, хто підключений до реальної інформації і, дуже важливо, точно знає, де треба зупинитися. Ефективна автоматизація в бізнесі означає правильне збирання даних і впевненість, з якою ви передаєте контроль людині-оператору в потрібний момент. Тому наступний крок — не купувати софт, а уважно проаналізувати ваші поточні процеси. Оцініть, які робочі потоки справді варто побудувати й автоматизувати, як їх можна безпечно поєднати і, найголовніше, визначте, як ви будете вимірювати результати на реальних даних, а не на маркетингових ілюзіях. І я залишу вас із цим питанням для роздумів. Серед усіх процесів комунікації в бізнесі, які з них справді потребують емпатії та такту людини, а які насправді — лише повторювані завдання, що просто чекають, аби їх точно підключили до правильної бази даних? Будь-який план автоматизації має починатися з цього питання. Дякуємо, що були з нами в цьому аналізі!

Що входить

Робота, за складовими

Спочатку перевіряємо, яка публічна брама є в системи

Для магазинів на WooCommerce ми використовуємо публічний магазинний API, який не потребує ключа споживача: клієнт підключається лише з адресою сайту. Це вибір, що має реальні наслідки, а не лише естетичні — ми замінили ним зроблені вручну інструменти, які тримали ключі магазину відкрито в базі даних. Коли в системи немає публічної брами, переходимо до автентифікації, але тоді ключ стає елементом, яким керують, а не тим, який забувають у рядку бази даних.

Ключі залишаються на сервері, не в інструменті й не на сторінці

Інструмент SMS є внутрішнім для платформи саме тому, що середовище, у якому виконується власний код інструмента, не має доступу до змінних середовища — якби надсилання виконувалося з коду інструмента, ключ довелося б записати в базу даних, а цей ключ може надсилати повідомлення коштом усіх. Так само і в системі записів: партнерський токен один, він зберігається в середовищі сервера, тоді як клієнт вказує лише ідентифікатор своєї компанії.

Агент викликає інструмент під час розмови, з параметрами і терміном

Кожен інструмент має опис, написаний для моделі, типізовані параметри з тим, що є обов’язковим, а що ні, і власний термін виконання — від 15 секунд для списку послуг до 30 для пошуку доступності. Термін для кожного інструмента — не дрібниця: без нього повільна інтеграція блокує розмову, а людина на іншому кінці чує тишу.

Реальні записи в системі салону або клініки

Шість інструментів поверх Altegio: список послуг із реальними цінами, спеціалісти, повна доступність, створення запису, скасування та зміна. Доступність повертає не лише «вільно/зайнято»: вона повертає, які спеціалісти виконують потрібну послугу, і перші вільні години для кожного, відсортовані за найранішою, саме щоб агент міг запропонувати конкретну альтернативу замість того, щоб казати «недоступно».

Каталог магазину, прочитаний наживо

Ціна й доступність читаються з магазину в момент запитання, а не з застарілої копії. Каталог завантажується пагіновано, до 30 сторінок по 100 продуктів, зберігається в тимчасовій пам’яті на десять хвилин на сайті й нормалізується в одну форму, що читається без змін усіма споживачами — включно з каруселлю продуктів у месенджері, якій потрібна числова ціна, і віджетом на сторінці, якому потрібен заголовок.

CRM, таблиці та канали повідомлень

amoCRM і Bitrix24 із повним OAuth, оновленням токена та перевіркою стану. Google Sheets через окремий сервісний обліковий запис, відокремлений від решти облікових даних, із записом, що запускається агентом. Telegram для сповіщень про лід. SMS через Infobip. Плюс канал чату локальної платформи оголошень, підключений із власним токеном оновлення — тип інтеграції, якого немає в жодному міжнародному каталозі й який має велике значення локально.

Автоматизації, що виконуються в часі, з лічильниками

Повторне відкриття розмов без відповіді, перше повідомлення новому контакту, призупинення й повторний запуск агента після графіка. Кожен запуск збільшує видимі лічильники: скільки запусків, скільки надісланих повідомлень, скільки пропущено, бо агент був вимкнений, скільки — бо не мав конфігурації, скільки помилок. Без них єдиний спосіб дізнатися, що автоматизація померла, — скарга клієнта.

Антизловживальні обмеження, бо рішення ухвалює модель

Інструмент, викликаний мовною моделлю, потребує меж, які модель не може перевищити. Для SMS: у режимі «до компанії» одержувач береться з конфігурації, ніколи — від моделі; у режимі «до клієнта» номер нормалізується й перевіряється. Понад це — денна межа на агента, пауза в одну хвилину до того самого номера і обмеження довжини повідомлення. Це паркани, записані в коді, а не інструкції в промпті — промпт можна обійти, паркан — ні.

Фільтри на виході, для даних, які не мають права вийти

Коли інтеграція повертає більше, ніж клієнт повинен знати, ми фільтруємо на виході, а не сподіваємося, що агент утримається. Реальний приклад: для клієнта з транспортної сфери політика забороняє, щоб агент диктував номер телефону водія, але API повертало ці номери у відповіді. Ми написали фільтр, який рекурсивно проходить результат інструмента й видаляє поля контакту водія, зберігаючи номери диспетчерської. Фільтр застосовується рівно там, де потрібно, не глобально, щоб випадково не приховати щось інше.

Як це виглядає

Шлях, крок за кроком.

Інвентар: які системи, які шлюзи, які права

Які системи задіяні, що відкриває кожна, хто має право створювати креденціали і хто їх ротує. Для кожної базове запитання: чи можна читати без автентифікації? Якщо так, інтеграція стає значно дешевшою і набагато легше повторюється для другого клієнта.

Конектор: оголошені інструменти, ключі на сервері, терміни

Кожна дія стає інструментом із назвою, описом, написаним для моделі, типізованими параметрами та власним терміном. Ключі залишаються в серверному середовищі. Наприкінці агент не «вміє робити» щось розмите: у нього є скінченний набір дій, кожна з власними межами.

Тест на випадку, який завершується помилкою, а не лише на тому, який працює

Конектор тестується на правильному запиті, на неповному запиті, на системі, що відповідає повільно, і на системі, що не відповідає зовсім. Те, що каже агент, коли інтеграція падає, — це рішення про проєктування, а не помилка, яку виявляє клієнт: ми надаємо перевагу чесному повідомленню та передаванню людині замість правдоподібної імпровізації.

Стійкість до нестабільності іншої системи

Повторна спроба із зростаючими паузами, але лише для помилок, які має сенс повторювати, — обмеження швидкості або помилка сервера, а не неправильний запит, який і вдруге буде неправильним. А коли проблема на рівні мережі іншої сторони, підхід інший; приклад нижче — саме такий випадок.

Передача: що змінюється, коли змінюється постачальник

Ми позначаємо, що зламається, якщо інша система змінить свій API, які креденціали спливають і коли, що треба оновити вручну. Інтеграція без цього списку — це прихований борг: вона працює ідеально до дня, коли перестає працювати, і ніхто не знає чому.

Зовнішні системи навколо розмови: резервування, каталог магазину, CRM, таблиці, SMS і канали повідомлень — кожна читається за запитом, а ключі залишаються на сервері.

Дані

Чого торкаємося, де воно лежить і скільки лишається

Запитання, які ставить кожен, у кого є відповідальний за захист даних, — поставлені тут раніше, ніж їх поставить він.

Де зберігаються креденціали: Ключі постачальника платформи зберігаються в серверному середовищі, не в базі даних і ніколи не на клієнтській сторінці. Власні креденціали клієнта — там, де інтеграція їх вимагає — зберігаються зашифрованими. Різниця важлива: скомпрометований ключ платформи зачіпає всіх, креденціал клієнта зачіпає один обліковий запис; ми обробляємо їх по-різному, бо ризик різний.
Що зберігається із зовнішніх систем, а що ні: Каталог продуктів не копіюється: він читається на запит і тримається в тимчасовій пам’яті десять хвилин, щоб десять послідовних запитань про один і той самий магазин не означали десять повних проходів. Записи не дублюються у нас — джерелом істини залишається система салону. Ми зберігаємо слід розмови та результат дії, а не копію бази іншої системи.
Що потрапляє до мовної моделі: Результат інструмента потрапляє в розмову, отже потрапляє і в контекст моделі. Саме тому фільтрація робиться на результаті, перед тим як його буде передано моделі, а не в інструкціях. Поля, які клієнт не має права чути, видаляються на джерелі; те, що було видалено, не можна продиктувати, незалежно від того, як запитують агента.
Cи може підключити інтеграцію: Підключення інтеграції — це автентифікована операція, прив’язана до облікового запису бізнесу, а отримані інструменти прикріплюються до конкретного агента — не до всіх. У агента є рівно ті інструменти, які йому потрібні для його ролі. Така сама логіка, як і з доступом працівника: йому не дають усі ключі лише тому, що так простіше.
Що ще треба виправити, сказано прямо: Не всі модулі інтеграції на нашій платформі перебувають на одному рівні. Ті, що перелічені тут, написані й запущені. Є також модулі, з яких почали, на кілька десятків рядків, які ще нічого корисного не роблять — ми не подаємо їх як доступні й не включаємо в жодну пропозицію. Якщо вам потрібна система, яка у нас перебуває на такому етапі, ми розглядаємо її як роботу на розробку, з попередньою перевіркою сумісності, а не як пункт для позначки.

Випадок

Інтеграція періодично падала, і це було не в нас

Ситуація

Конектор CRM іноді працював, а іноді ні, без видимого на перший погляд шаблону. Запити зависали, доки не перевищували ліміт виконання серверного середовища, тож у журналах з’являвся тайм-аут — ознака, яка хибно підштовхує шукати повільність у власному коді.

Що ми збудували

Причина була в мережі, на іншому кінці. Ім’я домену облікового запису CRM розв’язується в кілька IP-адрес, а частина вузлів кластера була несправною. Звичайний HTTP-запит обирає одну адресу і, якщо вона не відповідає, не пробує інші адреси, які повернув DNS — автоматичного переходу до наступної відповіді немає. Виправлення полягало в тому, щоб більше не використовувати стандартний HTTP-клієнт для цього домену: ми самі розв’язуємо ім’я, відкриваємо зашифровані з’єднання безпосередньо до кожної адреси паралельно, з коротким терміном для кожної, і використовуємо першу, що відповість; якщо всі в раунді холодні, повторюємо.

Що вийшло

Періодичні збої перестали бути лотереєю. Що важливіше для клієнта: діагноз став висловлюваним в одному реченні — «вузли постачальника періодично недоступні, і ми їх оминаємо» — замість «іноді не працює».

Чого цей випадок не каже

Це виправлення компенсує проблему когось іншого, і про це треба сказати. Воно додає складності до нашого коду через дефект в інфраструктурі постачальника; якщо той виправить свій кластер, складність залишиться в нас. Ми документуємо це саме так, щоб можна було прибрати, коли воно більше не буде потрібне.

Питання

Про що нас питають, перш ніж зателефонувати

Які системи ви фактично підключили, а не теоретично?

Систему запису Altegio, із шістьма діями, викликаними агентом. amoCRM і Bitrix24, із повним OAuth і оновленням токена. Google Sheets, із виділеним сервісним обліковим записом. Магазини на WooCommerce, через публічний API магазину. Telegram, для сповіщень. Infobip, для SMS. Канал чату локальної платформи оголошень. Плюс канали обміну повідомленнями Meta і Telegram для розмов. Для будь-якої іншої системи — включно з платформами магазинів, які ми не довели до кінця — чесна відповідь така: на запит, після перевірки сумісності, що розглядається як робота, а не як налаштування.

Мій магазин має генерувати мені API-ключі?

Для WooCommerce — ні. Ми використовуємо публічний API магазину, який не вимагає ключа споживача — ви підключаєтеся через адресу сайту. Це ще й безпечніше, не лише простіше: ми замінили цим підходом старіші інструменти, які зберігали ключі магазину у відкритому вигляді в базі даних. Для інших платформ усе залежить від того, що вони відкривають; ми перевіряємо це до того, як щось обіцяти.

Чи може агент зробити реальний запис, а не лише сказати, що робить його?

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

Куди потрапляють мої ключі?

Ключі платформи залишаються в середовищі сервера, ніколи не в базі даних і ніколи на вашій сторінці. Креденціали, які належать вам, зберігаються зашифрованими. Правило, яке ми застосовуємо: якщо ключ може витрачати гроші або може читати дані для всіх клієнтів, йому не місце ніде, куди потрапляє код, що виконується на запит мовної моделі.

Чи може агент надсилати SMS кому завгодно?

Ні, і це навмисне обмеження. У режимі сповіщення компанії одержувач береться з конфігурації — модель не може його обрати. У режимі до клієнта номер нормалізується і перевіряється. Понад це є добова межа на агента, пауза в одну хвилину до того самого номера і ліміт довжини повідомлення. Це запобіжники в коді, не інструкції в промпті; промпт можна обійти через розмову, запобіжник — ні.

Що стається, коли система іншої сторони падає або відповідає повільно?

Кожен інструмент має власний час виконання, тож повільна система не блокує розмову. Ми повторюємо спроби з наростаючими паузами, але лише для тих помилок, які варто повторювати, — обмеження швидкості або помилка сервера, не неправильний запит. А поведінка агента при збої прописується в сценарії: він каже, що зараз не може перевірити, і передає розмову, замість того щоб вигадувати правдоподібну відповідь.

Що стається, якщо постачальник змінює свій API?

Щось ламається, і саме тому ми надаємо перевагу офіційним шлюзам, а не читанню сторінок. Інструменти, що витягують інформацію з HTML сайту, ламаються від будь-якої зміни теми — ми свідомо замінили їх однією реалізацією поверх офіційного API, саме щоб не підтримувати десятки крихких варіантів. Коли альтернативи немає, ми кажемо, що це крихке рішення, і ставимося до нього саме так.

Ви можете робити автоматизації без агента, лише за запланованими правилами?

Так. Повторне відкриття розмов, що залишилися без відповіді, перше повідомлення новому контакту, зупинка і запуск агента після робочого часу — це заплановані завдання, що виконуються самі. Кожне має власні лічильники запусків, надісланих повідомлень, пропущених повідомлень і помилок, щоб на запитання «чи спрацювало?» можна було відповісти цифрою, а не припущенням.

Як ви забезпечуєте, щоб агент не казав зайвого з інтеграції?

Ми фільтруємо результат до того, як він потрапить до моделі, а не після. Конкретний випадок, який ми вирішили: політика клієнта забороняла агенту диктувати номер телефону водія, але API повертав ці номери. Ми написали фільтр, що рекурсивно проходить відповідь інструмента і прибирає поля контактів водія, зберігаючи номери диспетчерської, застосований саме до того інструмента. Те, що не потрапляє до моделі, не може бути сказане, незалежно від того, як питають агента.

На чому ґрунтуються твердження вище (18 джерел)

18 з них — це код і файли з наших репозиторіїв. Ми не публікуємо їхні назви чи номери рядків: разом, на одній сторінці, це надто точно описало б, як побудовані системи, які належать не лише нам. Ми проходимо їх разом із вами, у репозиторії, за запитом — перевірка залишається можливою, просто вона відбувається в розмові.

Як ми працюємо Усі послуги

Що вам хотілося б налагодити?

Розкажіть про свій процес. Разом визначимо, що варто збудувати, що можна підключити і як перевіримо результат.

Поговорімо