RAG у Xcellerate OPS: AI, який шукає за змістом

Коротко: Xcellerate OPS тепер застосовує генерацію з доповненим пошуком (RAG) поверх векторного індексу ваших власних знань. Ваша база знань, плейбуки, документація клієнтів, каталог продуктів, перевірені рішення та категорії тікетів перетворюються на ембединги за допомогою моделі ембедингів від Mistral і зберігаються у власній базі даних вашого робочого простору. Коли AI-колега шукає інформацію, OPS поєднує класичний пошук за ключовими словами з пошуком за змістом, тож знаходить статтю, яка відповідає на запитання, навіть якщо в тікеті вжито зовсім інші слова. Текст очищується від чутливих даних ще до створення ембедингів, документація конкретного клієнта показується лише для цього клієнта, а пошук за ключовими словами продовжує працювати, якщо у векторному шляху щось дає збій.

Що таке RAG?

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

Генерація з доповненим пошуком (RAG, retrieval-augmented generation) розв'язує це, розділяючи роботу на два кроки:

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

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

Що таке ембединги й векторна база даних?

Найскладніше в RAG — перший крок: знайти потрібний фрагмент. Класичний пошук зіставляє слова. Тікет «на другому поверсі ніхто не може друкувати» не знайде статтю бази знань під назвою «Служба друку зависає після оновлення драйвера», хоча саме вона містить розв'язання.

Цю проблему розв'язують ембединги. Модель ембедингів читає фрагмент тексту й перетворює його на довгий список чисел — вектор, який передає зміст тексту, а не те, які слова в ньому вжито. Тексти про одне й те саме опиняються поруч у цьому просторі, навіть якщо не мають жодного спільного слова. «Не можу друкувати», «принтер офлайн для всіх» і «служба друку зависла» лежать близько одне до одного; «прострочений рахунок» — далеко.

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

Чому це важливо для служби підтримки

• Люди описують проблеми своїми словами. Клієнти пишуть симптоми, техніки — розв'язання. Пошук за змістом поєднує одне з іншим.
• Ваші знання розпорошені. Статті бази знань, плейбуки, документація для кожного клієнта, нотатки про продукти та рішення, які ваша команда вже знайшла. RAG дає змогу AI-колезі прочитати все це саме тоді, коли це потрібно.
• Обґрунтовані відповіді можна перевірити. Коли відповідь побудовано на конкретній статті чи плейбуку, технік може відкрити джерело й переконатися сам. У цьому різниця між асистентом, якому можна довіряти, і тим, чию роботу доводиться перевіряти з нуля.
• Менше здогадок, менше повторюваних запитань. Коли AI знаходить попереднє рішення, старшого техніка не питають про те саме втретє за місяць.

Що ми вбудували в Xcellerate OPS

Один семантичний індекс на робочий простір

OPS веде семантичний індекс шести видів вмісту:

• Статті бази знань (папки пропускаються);
• Плейбуки, зокрема їхня примітка «застосовується, коли» та сама процедура;
• Документація, яку ви ведете для кожного клієнта;
• Продукти з вашого каталогу, з описом та інструкціями для AI;
• Рішення, виокремлені з вирішених тікетів (рішення, яке керівник команди позначив як хибне, не враховується);
• Категорії тікетів і підказки для AI, які ви для них написали.

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

Ембединги від Mistral

Вектори створює модель ембедингів від Mistral — mistral-embed, яка генерує 1 024-вимірні вектори. Тут важливі два запобіжники:

• Спершу очищення. Кожен текст, перш ніж залишити платформу, проходить той самий етап вилучення чутливих даних, що й будь-який інший виклик AI в OPS. Персональні дані, наприклад адреси електронної пошти, замінюються заповнювачами.
• Одна модель — один простір. Вектори від двох різних моделей неможливо порівнювати. Якщо колись знадобиться резервний постачальник, OPS перемкнеться лише на того, хто надає ту саму модель, тож індекс ніколи не змішується.

Гібридний пошук: ключові слова та зміст разом

OPS ніколи не покладається лише на вектори. Кожен пошук іде двома шляхами:

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

Два списки результатів об'єднуються методом reciprocal rank fusion (злиття за оберненим рангом): елемент, який має високе місце в будь-якому зі списків, піднімається вгору, а той, що високо в обох, — найвище. Надто слабкі векторні збіги (косинусна подібність нижче 0,2) відкидаються як шум, і кожен документ з'являється один раз — у вигляді свого найкращого фрагмента. Код продукту чи номер помилки, які ловить лише пошук за ключовими словами, ніколи не губляться, а перефразований симптом, який розпізнає лише пошук за змістом, теж знаходиться.

Нативний векторний пошук зі страховкою

Там, де база даних підтримує нативний векторний пошук, OPS використовує його (косинусна відстань у SQL). Там, де ні, вбудований механізм обчислює подібність самостійно. Якщо нативний шлях із будь-якої причини дає збій, пошук для цього запиту переходить на вбудований механізм. Векторний шар ніколи не ламає пошук.

Завжди актуально, без подвійної оплати

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

Де це помітить ваша команда

• AI-колеги шукають краще. Під час пошуку в базі знань, плейбуках, документації та продуктах вони ставлять семантичні збіги на перше місце, а збіги за ключовими словами — одразу за ними.
• Пов'язаний вміст у тікеті. Для категорії тікета AI-колега отримує вміст, який ви з нею пов'язали, рішення, що раніше закрили схожі тікети, і документи, найближчі за змістом до назви тікета.
• Чистіша пам'ять рішень. Нове рішення, майже ідентичне (косинусна подібність 0,92 або більше) вже збереженому для тієї самої категорії, вважається тим самим рішенням, тож ваш список не заповнюється дублікатами.

Справжній знімок екрана з нашого демо-середовища з вигаданими даними.

Конфіденційність і контроль

• Текст очищується від чутливих даних перед створенням ембедингів, а збережені рішення зберігають заповнювачі.
• Індекс розміщено у власній базі даних вашого робочого простору; документація клієнта доступна лише в межах цього клієнта.
• Керівник команди може позначити рішення як хибне (воно вилучається з індексу) або видалити його; видалення будь-якого проіндексованого елемента прибирає його вектори.
• Аварійний вимикач AI зупиняє створення ембедингів разом з усіма іншими викликами AI.
• Центр прозорості AI (AI Transparency Center) зазначає AI-пам'ять у вашому реєстрі AI Act («зберігається до стирання або видалення; зберігається без чутливих даних»), а Налаштування → AI-пам'ять показує, що містить пам'ять. Докладніше про реєстр — на сторінці про керування AI.

Справжній знімок екрана з нашого демо-середовища; одну колонку розмито.

Скільки це коштує

Створення ембедингів використовує AI-кредити в категорії AI-пам'яті, і кожен виклик фіксується в журналі, як і будь-яка інша дія AI. Оскільки для незмінених фрагментів і повторюваних запитань ембединги ніколи не створюються двічі, витрати залежать від того, наскільки змінюються ваші знання, а не від того, як часто шукає ваша команда. Сторінка Oversight у Центрі прозорості AI показує, скільки заощадило повторне використання.

Як почати

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

Якщо ви тільки знайомитеся з Xcellerate OPS, сторінка про AI-колег пояснює, що вони роблять, а наша стаття про те, як кожен закритий тікет робить наступний дешевшим, розповідає про AI-пам'ять, частиною якої є цей індекс.

Почніть безкоштовно