Як підготувати корпоративні дані для AI та RAG

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

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

Наслідок прямий: якщо в індексі є суперечлива інформація (наприклад, дві версії тієї ж процедури, одна з яких застаріла), модель може процитувати будь-яку з них залежно від того, який фрагмент опиниться вище в рейтингу. Якщо документ — це відсканований PDF без текстового шару, модель його взагалі не побачить. Якщо таблиці з цінами містяться в Excel-файлах, не перетворених на текст, асистент не зможе надати значення з цих таблиць.

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

Перш ніж очищувати, потрібно знати, що у вас є. Типовий аудит даних для AI відповідає на п’ять питань:

1. Які формати? DOCX, PDF, таблиці Excel/Sheets, сторінки в Confluence/Notion, електронні листи, записи розмов з CRM, база FAQ. Кожен формат потребує окремого парсера.
2. Яка актуальність? Документи старші за 12–18 місяців потребують перевірки. Застарілі процедури в індексі — джерело помилкових відповідей.
3. Який обсяг доступу? Деякі документи є конфіденційними (договори, дані HR). Вони не повинні потрапляти до індексу, доступного всім користувачам, — або мають індексуватися в окремій колекції з контролем доступу.
4. Чи є дублікати? Той самий регламент у п’яти версіях, з яких три застарілі, — це не база знань, а шум.
5. Чи містяться персональні дані? Документи з PII потребують або анонімізації перед індексацією, або виключно локального хостингу з відповідною правовою підставою згідно з RODO.

Результатом аудиту є перелік джерел з оцінкою: індексувати / індексувати після очищення / виключити / індексувати в окремій колекції з ACL.

Движку RAG потрібен чистий текст. Не PDF-файл, не зображення — текст. Парсинг — це перетворення кожного вихідного формату на плоский або ієрархічний текст з метаданими.

Типові виклики:

• Скановані PDF без OCR — без текстового шару це зображення. Потребують OCR перед індексацією. Якість OCR безпосередньо впливає на якість пошуку.
• PDF з багатоколонковим макетом — наївний парсер читає колонки горизонтально замість вертикально, створюючи нерозбірливі послідовності слів. Потрібен парсер, що враховує макет (layout-aware).
• Таблиці в PDF або Word — більшість парсерів втрачає структуру таблиць. Таблиці з числовими даними (ціни, технічні параметри, графіки) потребують окремого шляху екстракції до Markdown або JSON.
• Таблиці Excel — кожен аркуш і діапазон даних — це окремий фрагмент. Контекст заголовків стовпців має зберігатися, інакше значення втрачають сенс.
• Сторінки Confluence/Notion через API — зазвичай повертають HTML або JSON з багатою структурою. Потрібно зберігати заголовки H2/H3 як сигнали ієрархії при chunking.

На виході кожен документ стає набором абзаців або розділів з метаданими: назва документа, дата, відділ, категорія, вихідний формат.

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

Основні принципи:

• Розмір фрагмента 256–512 токенів для більшості застосувань. Занадто короткі фрагменти (50 токенів) втрачають контекст. Занадто довгі (2000 токенів) заповнюють контекстне вікно моделі одним документом, не залишаючи місця для інших.
• Перекриття (overlap) 10–20% між сусідніми фрагментами зберігає семантичну цілісність на межі поділу. Без перекриття речення «продовжуючи попередній пункт» втрачає свій попередній пункт.
• Поважай семантичні межі — діли при заголовках H2/H3, абзацах, пунктах списку. Поділ посередині речення завжди дає гірший результат, ніж поділ при заголовку.
• Кожен фрагмент містить метадані — назва документа, заголовок розділу, дата, категорія. У гібридному пошуку фільтри за метаданими дозволяють звузити результати до конкретного відділу або дати.

Особливий випадок: процедурні документи крок за кроком. Тут оптимальний chunk — це один крок з повним контекстом процедури в метаданих. Один крок без контексту, який повідомляє, що це крок 3 з 7 процедури повернення товару, марний у ізоляції.

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

Ключові рішення на цьому етапі:

Вибір моделі ембедінгів. Використовуємо BGE-M3, запущений локально через Ollama. Підтримує польську мову без перекладу, генерує 1024-вимірні вектори та працює на CPU корпоративного сервера. Жоден контент не залишає інфраструктури під час індексації. Для публічних даних без чутливої інформації прийнятні також хмарні моделі ембедінгів, якщо PII було попередньо замасковано.

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

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

Підготовка даних для AI — це одночасно вправа з захисту даних. Кожен етап пайплайну є потенційною точкою витоку.

Обов’язки щодо персональних даних:

• Правова підстава для обробки даних з метою AI має існувати до потрапляння даних до індексу. Згода або законний інтерес для конкретного застосування.
• Мінімізація — індексуйте лише дані, необхідні для мети асистента. Повна база CRM з історією клієнтів не повинна потрапляти до асистента, який відповідає на питання про внутрішні процедури.
• Маскування PII — перед відправкою фрагментів до зовнішньої генеративної моделі через наш маршрутизатор LLM автоматично виявляємо та маскуємо персональні дані: імена, номери телефонів, PESEL, адреси електронної пошти.
• Data residency та self-hosting — для даних, що підпадають під професійну таємницю (право, медицина, фінанси) або конфіденційних кадрових даних весь пайплайн (ембедінги, векторна база даних, генеративна модель) має працювати локально.
• Право на видалення — коли RODO вимагає видалення даних особи, її документи мають зникнути з індексу. Пайплайн має підтримувати селективне видалення фрагментів з векторної бази даних.

Для проєктів HR, оцінки працівників або фінансових, як сфер високого ризику згідно з AI Act, потрібна DPIA (оцінка впливу на захист даних) перед впровадженням. Деталі в статті AI Act та RODO 2026.

Підготовка даних — це не одноразовий проєкт. База знань живе: документи змінюються, процеси еволюціонують, нові продукти з’являються в асортименті.

Кращі практики підтримки:

• Версіонування документів з датою дії. Кожен chunk містить метадані з датою документа. Система може знижувати пріоритет фрагментів старших за X місяців або вимагати ручного підтвердження актуальності.
• Пайплайн автоматичного реіндексування. Зміна файлу в репозиторії знань (Confluence, SharePoint) запускає автоматичний перерахунок уражених фрагментів. Не раз на місяць — при кожній зміні.
• Моніторинг якості відповідей. Якщо асистент починає частіше відповідати «не знаю», це сигнал, що база потребує оновлення — а не те, що модель зіпсувалася.
• Тематичні прогалини. Інструменти observability відстежують питання, на які RAG не знайшов фрагмента. Це перелік тем для доповнення в базі знань.

Цикл: індексуй → збирай питання без відповідей → доповнюй базу → реіндексуй. Після кількох ітерацій асистент покриває переважну більшість реальних запитань від користувачів.

Час і вартість залежать насамперед від стану вхідних даних. Чисті, структуровані документи (Word, Confluence, добре відформатовані PDF) скорочують проєкт у кілька разів порівняно з базами, повними сканів та аркушів без порядку.

Вартість інфраструктури при локальному хостингу — це переважно сервер та час впровадження. Хмарні ембедінги коштують кілька центів за мільйон токенів. Оцініть свій проєкт у калькуляторі ROI або скористайтеся оцінкою готовності AI, яка оцінить, зокрема, стан вашої бази знань.

Повну кошторисну оцінку проєкту готуємо після аудиту даних. Напишіть через контактну форму.

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

Почніть з аудиту: перелічіть усі системи, де зберігаються корпоративні знання (SharePoint, Confluence, електронні листи, CRM, спільні диски), оцініть актуальність та формат кожного набору. Оберіть одну тематичну область з відносно чистими даними, наприклад, FAQ обслуговування клієнтів або процедури онбордингу працівників, і зробіть пілот на цьому фрагменті. Краще запустити асистента на 200 якісних документах, ніж на 2000 хаотичних. Детальніше про поетапний підхід у статті з чого почати впровадження AI.

Ні. При локальній моделі ембедінгів (наприклад, BGE-M3 через Ollama) та локальній векторній базі даних (Qdrant on-prem) весь пайплайн індексації працює у вашій інфраструктурі. До зовнішньої генеративної моделі потрапляє лише текст запиту та кілька вибраних фрагментів контексту після автоматичного маскування PII. Конфіденційні кадрові, юридичні та фінансові дані можемо обробити через self-hosting всієї генеративної моделі.

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

Залежить від того, як часто змінюється база знань. Для активно оновлюваних процедур оптимальним є інкрементальний пайплайн, що запускається зміною документа (webhook з Confluence або SharePoint до движка індексації). Для стабільніших баз достатньо регулярного щотижневого або щомісячного сканування з автоматичним виявленням змін за контрольною сумою файлу. Відсутність оновлення індексу при змінюваних документах — найчастіша причина погіршення якості асистента через кілька місяців роботи.

Так, в будь-якому сценарії. Навіть готові платформи RAG (SaaS) вимагають, щоб документи були машинозчитуваними, актуальними та логічно розділеними. Різниця полягає в тому, що готові SaaS-інструменти пропонують власний інтерфейс для завантаження та керування документами, але якість chunking та структури даних все одно залежить від вас. Для конфіденційних даних або великого обсягу власна інфраструктура дає повний контроль над тим, що і де обробляється. Порівняння підходів у статті власний асистент AI чи готовий.