Вбудовуємо пошук, рекомендації та обробку документів у системи, з якими працює ваша команда. До розробки визначаємо джерела даних, права доступу й критерії приймання.
Обговорити завдання для ШІ →Сервіси ШІ на одній робочій панелі.
Панель «AI флот» у GBA показує доступність сервісів, перебіг обробки та актуальність даних. Команда бачить, що вже завершено, а що потребує уваги, у своїй робочій системі.
Асистент може перетворити бізнес-запитання на запит до бази даних. Для цього визначаємо показник, обмежуємо доступні дані й перевіряємо запит до виконання. Нижче показано, які кроки потрібно контролювати.
SELECT p.name, SUM(o.order_value) AS total
FROM products p
JOIN orders o ON p.id = o.product_id
WHERE o.region = 'EU'
AND o.date >= '2025-10-01'
AND o.date < '2026-01-01'
GROUP BY p.name
ORDER BY total DESC
LIMIT 3;Widget Pro (2,4 млн євро), Sensor X (1,8 млн євро), Module Z (1,2 млн євро). Перш ніж використовувати відповідь, перевірте визначення показника та вихідні замовлення.
Покажіть 3 товари з найбільшою зафіксованою вартістю замовлень у ЄС за IV квартал 2025 року
Результат за записами замовлень у ЄС за IV квартал 2025 року:
| # | Продукт | Вартість замовлення |
|---|---|---|
| 1 | Widget Pro | €2.4M |
| 2 | Sensor X | €1.8M |
| 3 | Module Z | €1.2M |
Перетворювати погоджені бізнес-запитання на запити до бази даних, які можна перевірити
Пов’язувати бізнес-терміни зі структурою даних і визначеннями показників у звітах
Перевіряти згенеровані запити перед виконанням на дозволених даних
Дотримуватися прав доступу користувача та зберігати історію запитів для перевірки
Оцінювати можливості бази даних та інтеграції у вашому середовищі
Користувач формує запит природною мовою.
Модель формує запит на основі погодженого опису структури даних.
Перевірений запит виконується в межах прав доступу користувача.
Результат містить контекст для перевірки джерела даних і визначення показника.
Оберіть повторюване завдання й зафіксуйте витрати часу, помилки або пропущені рішення. Оцінюємо доступні дані та порівнюємо підхід із ШІ з пошуком, звітністю чи правилами, які вже може використовувати команда.
Інформація розпорошена між системами й документами, а джерело для перевірки відповіді незрозуміле.
Перш ніж ухвалити рішення, команда вручну збирає та звіряє записи.
Рекомендаціям складно довіряти, якщо невідомі дані, правила чи обґрунтування, на яких вони базуються.
Закупівлі та чисельність команди планують за оцінками, які не звіряють із фактичними результатами.
Працівникам і клієнтам складно знайти потрібний запис, документ або товар.
Для кожної функції визначаємо вхідні дані, корисний результат і спосіб його перевірки. Ці сценарії можемо оцінити разом із вашою командою.
Рекомендувати товари з каталогу на основі дозволених даних про клієнтів. Порівнювати результат із наявним пошуком і правилами представлення товарів.
Формуйте відповіді на основі погоджених документів за допомогою RAG — генерації з пошуком у джерелах. Відбирайте лише доступні користувачу уривки та додавайте посилання для перевірки відповіді.
Оцінювати попит або продажі за історичними даними. Порівнювати похибку з базовим прогнозом і визначати, за яких умов результат ненадійний.
Знаходити ймовірні відповідності в каталозі за зображенням і давати користувачу змогу перевірити та виправити результат.
Визначати, коли потрібно поповнити запаси, з огляду на залишки, строки постачання та попит. Рішення про закупівлю затверджує людина.
Готувати чернетки відповідей або класифікувати звернення за погодженою базою знань. Неоднозначні чи чутливі питання передавати відповідальному фахівцю.
Видобувати поля з документів для перевірки, зберігати посилання на джерело та вимірювати помилки на репрезентативній вибірці.
Перевіряти запропоновані маршрути й способи доставки на відповідність доступним потужностям, строкам та умовам обслуговування перед застосуванням у роботі.
Почніть із внутрішньої служби підтримки та однієї погодженої бібліотеки правил. Пілот має працювати в режимі читання, посилатися на доступні уривки й передавати нерозв’язані запитання відповідальному колезі.
Визначте відповідального за джерело, користувачів із доступом, дозволені запитання та графік оновлення. Система має враховувати зміни прав і видалення матеріалів. Якщо джерело відсутнє, застаріле або суперечливе, потрібно показати це обмеження й передати запитання відповідальній людині.
Фахівець предметної області готує типові запитання, на які є відповіді, а також випадки з обмеженим доступом, браком даних, застарілими чи суперечливими джерелами. Залиште окрему вибірку для оцінювання. До тестування зафіксуйте очікувані уривки-підтвердження та умови, за яких система має відмовитися від відповіді.
Використовуйте однакові запитання для ручного пошуку й пілота. Вимірюйте частку відповідей, підтверджених джерелами, коректні відмови, порушення доступу, час перевірки та вартість завершеного завдання. Швидкість і переконливе формулювання не компенсують неможливості перевірити відповідь.
До тестування погодьте критерії приймання з відповідальними за процес і безпеку. Зафіксуйте якість відповідей, порушення доступу та недоліки роботи на контрольній вибірці. За результатами оберіть обмежений запуск, доопрацювання або зупинку; критичні порушення доступу усуньте до розширення.
Візьміть ці приклади за основу, щоб оцінити використання й час перевірки перед узгодженням місячного бюджету.
| Стаття витрат | Приклад для розрахунку | Як перевірити |
|---|---|---|
| Завантаження та оновлення даних | Одне джерело, 1 000 документів, щоденна перевірка оновлень | Окремо виміряйте витрати на розбір документів, обробку змін, індексування та роботу конектора. |
| Пошук і виклики моделі | 20 користувачів × 10 запитань × 22 робочі дні = 4 400 запитань на місяць | Виміряйте фактичну кількість викликів, токенів, повторних спроб і пошуків для кожного запитання. Застосуйте тарифи обраного постачальника. |
| Хостинг і моніторинг | Одне пілотне середовище та погоджений строк зберігання журналів | Розділіть фіксовану плату за потужності та витрати на зберігання й використання ресурсів. Перевірте погоджене розташування даних і правила доступу. |
| Перевірка фахівцями та підтримка | Кількість прикладів у вибірці × хвилини на перевірку, плюс час на обслуговування | Врахуйте вартість роботи відповідальних фахівців, перевірки оновлень, опрацювання інцидентів і повторного оцінювання після змін. |
До запуску погодьте ліміт витрат, одержувачів сповіщень і дії після його досягнення. Визначте відповідальних за платну підтримку та повторюйте погоджену перевірку після зміни джерел, інструкцій або моделей.
Визначаємо завдання, тестуємо на репрезентативних даних і погоджуємо, коли результат має перевіряти людина.
Опишіть процес, доступні дані та рішення, яке хочете покращити. Визначимо, як перевірити користь ШІ на практиці.
Обговорити ШІ-проєкт