Як зібрати базу знань компанії для ШІ, щоб асистент не відповідав зі старого прайсу?

Як зібрати базу знань компанії для ШІ, щоб асистент не відповідав зі старого прайсу?

Базу знань компанії для ШІ варто збирати як 5-7 файлів, кожен з яких є джерелом істини для однієї теми, і біля кожного стоїть імʼя людини, яка його оновлює: прайс, залишки, оферта разом із шаблоном договору, опис ключового процесу, FAQ, правила знижок і заборони для бота. Поки прайс або залишки відстають від реальності, асистент лише швидше рознесе стару цифру по всіх клієнтах одразу. Тому першим ділом треба знайти файл, який бреше найчастіше, і на час його ремонту заборонити боту називати ціну й наявність, поки відповідальна людина не поверне файлу актуальну версію.

Типова картина в інтернет-магазинах виглядає так. Асистент сидить у месенджері, відповідає на питання про товар і наявність, приймає замовлення і видає номер ТТН, коли посилка вже поїхала. Ціна при цьому живе в Excel у комерційного директора, залишки в складській програмі, а свіжа домовленість про акцію на вихідні в робочому чаті менеджерів. Асистент читає той файл, який йому завантажили місяць тому, і впевнено пише клієнту позаминулу ціну або обіцяє товар, якого вже два тижні немає на полиці. Клієнт робить скріншот і приходить з ним до менеджера: у вас тут написано інакше. Далі в компанії шукають винного, хтось пропонує поміняти модель, хтось вимкнути бота зовсім. Лікувати при цьому треба інше: набір джерел, з яких асистент бере відповіді, і імена людей, які за ці джерела відповідають.

Коротко

• База знань для асистента складається з 5-7 джерел істини, по одному на тему, і в кожного є власник оновлення з конкретним іменем.
• Асистент повторює стару ціну, бо читає те, що йому дали, і дату файлу сам собою під сумнів бере рідко.
• Найчастіше бреше файл залишків, на другому місці прайс, і саме з них варто починати перевірку.
• Поки файл у ремонті, бот переводить питання про ціну й наявність на менеджера і сам цифру клієнту не називає.
• Файли розкладаються по папках за темами, у текстових форматах, з однією актуальною версією, а архів живе окремо.

Чому асистент упевнено називає стару ціну

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

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

Сім джерел істини і хто за кожне відповідає

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

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

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

FAQ старіє непомітно. Його складають один раз під запуск бота, потім змінюються умови доставки, зʼявляється новий спосіб оплати, а відповідь у FAQ лишається торішньою. У багатьох компаніях FAQ живе довше за правила, які в ньому описані. Власник оновлення FAQ має переглядати його щоразу, коли змінюється оферта або ключовий процес, і ця звʼязка між файлами повинна бути записана прямо в описі бази.

Який файл бреше найчастіше

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

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

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

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

Поки файл у ремонті, асистент мовчить про ціну

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

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

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

Як розкласти файли, щоб асистент знаходив потрібне

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

Файли лежать у папках за темами: ціни окремо, склад окремо, юридичні документи окремо, процеси окремо. Формати текстові, тобто PDF з текстовим шаром, DOCX, TXT або MD. Скан договору у вигляді картинки асистент прочитає гірше, а таблицю з обʼєднаними клітинками може зрозуміти зовсім інакше, ніж задумував автор. Інструкції для асистента пишуться вже після того, як файли розкладені, і в них прямо сказано, з якої папки брати відповіді на які питання.

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

Що робити далі

1. Випишіть 5-7 джерел істини для вашого бізнесу: прайс, залишки, оферта з шаблоном договору, ключовий процес, FAQ, правила знижок, заборони для бота.
2. Біля кожного джерела поставте імʼя власника оновлення і день, коли він оновлює файл, і надішліть цей список команді.
3. Зробіть вибіркову перевірку двадцяти позицій і знайдіть файл, який бреше найчастіше, найімовірніше це будуть залишки або прайс.
4. Першим рядком у заборонах для бота запишіть правило: поки прайс або залишки в ремонті, асистент ціну й наявність не називає і передає питання менеджеру.
5. Приберіть з бази все, крім актуальних версій, розкладіть файли по тематичних папках у текстових форматах і лише після цього переписуйте інструкції асистента.

Про цей матеріал

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