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

Гість пише о 22:40: «Ми прилітаємо після опівночі з дитиною і собакою. Чи зможемо заселитися, де залишити авто і чи буде кухня ще відкрита?»

На сайті готелю вказано заселення до 23:00. У старому файлі для рецепції — цілодобово за попереднім запитом. На сторінці онлайн-агентства тварини заборонені, але менеджер уже пів року погоджує їх у двох категоріях номерів за доплату. Google показує минулорічний графік ресторану.

Штучний інтелект не виправить ці суперечності. Він лише швидко складе з них переконливу відповідь — і саме тому може швидше поширити помилку.

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

Не «один документ для всього», а визначене джерело для кожного факту

Фраза «єдине джерело правди» звучить привабливо, але в готелі буквально одного джерела бути не може. Актуальна наявність і ціна живуть у системі бронювання або центральній системі резервування. Умови вже придбаного тарифу — у записі конкретного бронювання. Графік сніданків затверджує ресторан. Дані про ширину дверей і безбар’єрний маршрут мають походити з перевіреного опису об’єкта, а не з рекламного тексту.

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

NIST AI RMF 1.0 радить документувати межі знань, людський нагляд і відповідальність та тестувати систему до і після запуску [1]. Профіль NIST для генеративного ШІ додає походження даних, перевірку джерел, обґрунтованість пошуку й безпечну відмову за межами знань [2]. Це добровільні міжгалузеві рекомендації, а не правила для готелів.

Спочатку проведіть межу бази знань

База знань повинна містити перевірені операційні твердження й правила відповіді. Вона не має ставати копією всіх систем готелю.

«Стабільне» не означає «вічне»: вхід може переміститися під час ремонту, а планування номера — змінитися після нього. Частота перегляду має залежати від мінливості й наслідків помилки, а не від одного календаря для всіх записів.

Паспорт одного твердження

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

Мінімальний паспорт такого запису:

• унікальний ідентифікатор і коротка назва;

• саме твердження та дозволене формулювання для гостя;

• об’єкт, категорія номера, послуга, канал, мова й аудиторія, до яких воно належить;

• первинне джерело або запис у системі, з якого його отримано;

• власник змісту й особа, яка затвердила публікацію;

• номер версії, дата затвердження, чинне з, чинне до або дата наступної перевірки;

• клас мінливості та допустима давність даних;

• рівень доступу: публічний, для підтвердженого гостя, для персоналу, обмежений;

• пов’язані твердження й правило переваги в разі конфлікту;

• умова, за якої відповідь заборонена без перевірки людиною.

Складна онтологія не обов’язкова, але походження слід зберігати. W3C PROV-O описує корисні зв’язки: відповідального агента, первинне джерело, перегляд версії, час створення та втрати чинності [3]. Готель може застосувати цю дисципліну без буквального впровадження стандарту.

У знання має бути власник, а в зміни — маршрут

«Маркетинг оновлює базу» — не модель відповідальності. Маркетинг може редагувати текст, але не повинен сам вирішувати, чи можна повернути депозит або гарантувати суміжні номери.

Розподіліть відповідальність за доменами:

• служба розміщення — порядок заїзду, виїзду й операційні винятки;

• дохід і бронювання — тарифи, обмеження, умови зміни та скасування;

• ресторан і оздоровчий підрозділ — графіки, склад послуг, бронювання;

• номерний фонд та інженерна команда — фізичні характеристики, обладнання, доступність;

• безпека й керівник об’єкта — надзвичайні сценарії та межі публічної інформації;

• юридична або відповідальна за приватність функція — персональні дані, строки зберігання й права доступу.

Зміна має пройти видимий шлях: пропозиція → перевірка → затвердження → дата чинності → публікація → тест. Контроль CM-3 у NIST SP 800-53 Rev. 5 так само передбачає схвалення, тестування та історію змін [4]. Невеликому готелю достатньо форми й журналу, а не комітету.

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

Пошук має спершу відсіяти неможливе, а вже потім шукати схоже

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

Перед ранжуванням за змістом система має відфільтрувати записи за:

1. конкретним готелем і послугою;

2. мовою та аудиторією;

3. рівнем доступу користувача;

4. датою чинності й датою проживання;

5. тарифом, каналом або категорією, якщо вони змінюють правило;

6. статусом затвердження та допустимою давністю.

OWASP окремо попереджає про витоки між контекстами, суперечності об’єднаних джерел і отруєння баз пошуку. Його рекомендації включають дрібнозернистий контроль доступу, логічне розділення наборів, приймання даних із перевірених джерел, класифікацію записів та журналювання пошуку [5]. Це особливо важливо для платформи, що обслуговує кілька готелів: дані одного об’єкта не можуть потрапити до відповіді іншого.

Правило розв’язання конфліктів

Корисний порядок такий:

1. відкинути записи не для того об’єкта, гостя, дати, тарифу або рівня доступу;

2. для ціни й наявності використати визначену живу транзакційну систему;

3. для конкретного бронювання надати перевагу збереженим умовам цієї покупки;

4. для політики використати затверджений чинний реєстр, а не його копію на сайті;

5. новішу версію автоматично обирати лише в межах тієї самої підтвердженої лінії версій;

6. якщо два рівноправні джерела суперечать одне одному — не вгадувати, а створити інцидент знань і передати питання власнику.

«Останній змінений файл» не є безпечним універсальним правилом: його могла випадково відредагувати неуповноважена людина.

Впевненість — це достатність доказів, а не красиве число

Число, яке модель називає «впевненістю», саме по собі не доводить правильність. Для гостьової відповіді корисніше перевіряти чотири умови:

• знайдено щонайменше одне авторитетне джерело, придатне для цього контексту;

• воно чинне й достатньо свіже для потрібної точності;

• немає невирішеного конфлікту;

• відповідь не виходить за межі дозволеного доступу й самого джерела.

Якщо всі умови виконані, система може відповісти. Якщо відомий лише загальний факт, вона повинна позначити межу: «Зазвичай заселення можливе до 23:00; прибуття о 00:40 потребує підтвердження чергової команди». Якщо немає актуальної ціни, гарантії доступності, дозволу на виняток або джерела конфліктують, правильна дія — відмова від припущення й передавання людині.

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

NIST GenAI Profile рекомендує документувати залежність від джерел, порівнювати результати з відомою правильною відповіддю, перевіряти джерела під час тестування й експлуатації та будувати систему так, щоб вона могла безпечно працювати за межами знань [2]. OWASP також радить поєднувати перевірені зовнішні дані, автоматичну валідацію, людський нагляд і чітке повідомлення про межі надійності [7].

Не змішуйте знання готелю з історією кожного гостя

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

Для організацій у сфері дії GDPR статті 5, 25 і 32 закріплюють, зокрема, обмеження мети, мінімізацію, точність, обмеження зберігання, захист за задумом і належну безпеку [8]. EDPB у висновку 28/2024 щодо моделей ШІ підкреслює необхідність визначити ролі сторін до обробки й використовувати лише адекватні, релевантні та необхідні персональні дані [9]. Застосовність і правова підстава залежать від конкретної архітектури та юрисдикції; це слід перевіряти окремо.

Практичні правила:

• за замовчуванням не завантажувати до бази повні чати, скани документів, платіжні дані або списки гостей;

• перед використанням діалогів для тестів вилучати або замінювати ідентифікатори й перевіряти правову підставу;

• розділяти публічні, гостьові й службові колекції;

• надавати системі й працівникам мінімально необхідні права;

• не покладатися лише на інструкцію моделі: OWASP зазначає, що підказки не гарантують захисту від витоку або ін’єкції [6];

• журналювати достатньо для розслідування, але не копіювати зайві персональні дані до журналів. NIST прямо застерігає, що аудиторські записи самі можуть створювати ризик приватності [4].

Якщо готель працює з гостями в ЄС, варто також перевірити ролі постачальника й готелю за Актом ЄС про ШІ. З 2 серпня 2026 року застосовуються передбачені статтею 50 вимоги прозорості до певних систем, які безпосередньо взаємодіють із людьми; Європейська комісія пояснює, що користувача чатбота слід повідомляти про взаємодію з ШІ, якщо це не є очевидним, з урахуванням сфери дії та винятків [10][11].

Тестувати потрібно не красу тексту, а правильність рішення

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

Обов’язкові групи тестів:

• правильний факт і правильна версія на задану дату;

• ціна або наявність без доступу до живої системи;

• два суперечливі джерела;

• правило іншого готелю тієї самої мережі;

• майбутня політика та старе бронювання;

• службова інформація, яку просить гість;

• запит на виняток, гарантію або небезпечну дію;

• непряма інструкція всередині завантаженого документа та пряме «ігноруй правила»;

• правильна передача людині без втрати контексту;

• природна відповідь кожною підтримуваною мовою.

Для кожного сценарію зафіксуйте очікуваний режим: відповісти, відповісти умовно або передати. NIST радить документувати тестові набори й показники, оцінювати в умовах, схожих на реальне використання, та продовжувати моніторинг після запуску [1][2].

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

Практичний запуск за 30 днів

Дні 1–3 — визначити межі. Оберіть один готель, дві мови й 5–7 найцінніших намірів: заїзд, правила проживання, послуги, номер, доступність, зміна бронювання. Забороніть автоматичні обіцянки щодо винятків, повернень, безпеки й неперевірених спеціальних запитів.

Дні 4–7 — скласти карту джерел. Для кожного класу фактів запишіть систему, власника, чинність, допустиму давність, доступ і запасний сценарій. Позначте суперечності між сайтом, PMS, файлами та майданчиками; не імпортуйте їх як рівноправні.

Дні 8–12 — створити перші записи. Перетворіть 40–60 пріоритетних запитань на атомарні твердження з паспортами. Не намагайтеся за місяць оцифрувати весь готель.

Дні 13–16 — налаштувати зміни й доступ. Призначте власників, затвердження, дати чинності, рівні доступу й журнал версій. Вилучіть персональні, платіжні та зайві службові дані.

Дні 17–20 — побудувати пошук і правила конфліктів. Спочатку застосовуйте фільтри контексту та прав, потім змістове ранжування. Підключіть живі системи лише для тих фактів, які справді потребують поточного запиту.

Дні 21–24 — провести випробування. Запустіть контрольний набір, атаки на доступ і сценарії застарілих даних. Перевірте не тільки правильні відповіді, а й правильні відмови.

Дні 25–27 — робота в тіньовому режимі. Нехай система готує відповідь, але працівник її приймає, виправляє або відхиляє. Кожне виправлення повинно вести до конкретного джерела чи правила, а не лише до «кращого промпту».

Дні 28–30 — обмежений запуск. Відкрийте лише перевірені наміри, залиште видимий шлях до людини, призначте щоденний перегляд інцидентів першого тижня й критерії зупинки. Результатом місяця має бути не «бот знає все», а невеликий керований контур, який можна безпечно розширювати.

Де тут Greetio

Greetio не повинен вигадувати політику, визначати силу джерел або перетворювати старий PDF на істину. За це відповідає готель.

Роль Greetio — отримати керовані записи з дозволених джерел, зберегти контекст, версію та строк чинності й відповісти лише в межах доказів. За недостатньої опори система має назвати невизначеність і передати запит людині. Логи пошуку, відмов і виправлень покажуть, де потрібно змінити не «ШІ», а операційну правду готелю.

Висновок

База знань для відповідей гостям починається не з моделі й не з кнопки «завантажити всі документи». Вона починається з незручних, але конкретних рішень: хто володіє правилом, де його первинне джерело, для кого й коли воно чинне, що має перевагу в разі конфлікту та де система зобов’язана зупинитися.

Коли ці рішення видимі, ШІ може скоротити шлях від запитання до перевіреної відповіді. Коли їх немає, він лише надає безладу впевнений тон.

Поширені запитання

1. Чи потрібно спочатку довести всі дані готелю до ідеалу?

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

2. Чи можна просто завантажити сайт, FAQ і PDF?

Можна використати їх як сировину, але не як автоматично рівноправні джерела. Спершу потрібно визначити, що є первинним, хто затвердив зміст, коли він чинний і що робити із суперечностями. Зовнішній документ також може містити шкідливі інструкції для моделі, тому імпорт потребує перевірки.

3. Як часто оновлювати базу знань?

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

4. Чи потрібне одне «джерело правди» для всього готелю?

Ні. Потрібне одне визначене авторитетне джерело для кожного класу фактів і явний порядок переваги. Транзакційні дані, політики, операційні графіки й характеристики номерів природно живуть у різних системах.

5. Чи можна додати до бази всі переписки з гостями?

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

6. Що має робити ШІ, якщо джерела конфліктують або відповіді немає?

Не обирати найзручнішу версію й не домислювати. Система повинна позначити невирішене питання, зберегти джерела й контекст, створити завдання відповідальному власнику та передати гостя людині з очікуваним строком відповіді.

7. Чи потрібно повідомляти гостя, що відповідає ШІ?

Це залежить від юрисдикції та ролей сторін. Для систем у сфері дії Акта ЄС про ШІ стаття 50, що застосовується з 2 серпня 2026 року, передбачає повідомлення людей про пряму взаємодію із системою ШІ, якщо це не є очевидним, з урахуванням визначень і винятків. Навіть поза цією сферою прозоре коротке повідомлення та простий перехід до людини є здоровою практикою довіри.

Джерела

1. NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (2023).

2. NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 (2024).

3. W3C — PROV-O: The PROV Ontology, W3C Recommendation (2013).

4. NIST — Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5.

5. OWASP GenAI Security Project — LLM08:2025 Vector and Embedding Weaknesses.

6. OWASP GenAI Security Project — LLM01:2025 Prompt Injection.

7. OWASP GenAI Security Project — LLM09:2025 Misinformation.

8. European Union — Regulation (EU) 2016/679, General Data Protection Regulation.

9. European Data Protection Board — Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models (17 December 2024).

10. European Union — Regulation (EU) 2024/1689, Artificial Intelligence Act, Article 50 and Article 113.

11. European Commission — Transparency obligations under Article 50 of the AI Act (official Q&A, updated July 2026).

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