AI-пошук в архіві документів (Document Search)

Реалізація AI-пошуку в архіві документів (Document Search)

Напрямки AI-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1441
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1302
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    998
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1267
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    714
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1006

Реалізація AI-пошуку в архіві документів (Document Search)

Файлова система безсила проти смислового пошуку: договір з автопролонгацією не знайти, якщо запит не містить точної фрази. Менеджери витрачають години на перебір папок, юристи пропускають терміни через загублені договори. Ми впроваджуємо AI-систему, яка розуміє запит за змістом, а не просто шукає підрядок. Результат — секунди замість годин. Для типового архіву з 50 000 документів час пошуку скорочується з 15 хвилин до 30 секунд.

Як працює гібридний пошук?

Гібридний пошук об'єднує два підходи: семантичний (ембединги) та лексичний (BM25). Семантичний вловлює синоніми та контекст: запит «продовжити договір з Газпромом» знайде фразу «пролонгація контракту з ПАТ Газпром». Лексичний забезпечує пошук за точними збігами — номерами, датами, сумами. Ми змішуємо результати через RRF (Reciprocal Rank Fusion) і переранжуємо cross-encoder'ом. Підсумкова точність (NDCG@5) на тестовій колекції з 10 000 документів — 0.89. Гібридний підхід на 20% підвищує recall порівняно з чистими ембедингами і дає в 1.5 рази вищий nDCG@5, ніж BM25.

Індексація архіву

Кожен документ при потраплянні в архів проходить обробку:

  1. Вилучення тексту: pdfminer (PDF), python-docx (DOCX), unstructured.io (підтримує більше 30 форматів).
  2. Структурування: розбивка на чанки по 512 токенів з перекриттям 128 токенів + збереження метаданих (розділ, сторінка, дата створення).
  3. Ембединги: text-embedding-3-small (OpenAI, 1536-вимірний) або cointegrated/rubert-tiny2 (384-вимірний, on-premise). Вибір моделі впливає на латентність: GPU-інференс займає ~20 мс на чанк.
  4. Індексація в Qdrant або pgvector з HNSW-індексом для швидкого пошуку по 1 млн+ векторів (latency p99 < 300 мс).
  5. Вилучення структурованих метаданих: тип документа, сторони, дати, суми — за допомогою NER-моделі (spaCy + донавчання на ваших даних) і запис в реляційну БД.
Деталі чанкування Розмір чанка 512 токенів з перекриттям 128 обраний емпірично: він дає найкращий баланс між покриттям та latency. Для документів з довгими таблицями використовуємо adaptive chunking.

Чому cross-encoder reranking?

Після отримання топ-K від гібридного пошуку ми застосовуємо cross-encoder модель (наприклад, cross-encoder/ms-marco-MiniLM-L-6-v2), яка попарно оцінює релевантність кожного документа до запиту. Це додає 50-100 мс до latency, але підвищує точність перших результатів на 15-20%. На практиці це означає, що користувач рідше прокручує другу сторінку.

Фасетний пошук

Додаткові фільтри для точного пошуку представлені в таблиці:

Фасет Приклади значень Тип фільтра
Тип документа договір, акт, накладна, рахунок множинний випадний список
Контрагент Назва або ЄДРПОУ автодоповнення з fuzzy match
Дата підписання, закінчення, початку діапазон дат (календар)
Сума від 100 000 до 5 000 000 повзунок + поля введення
Статус діючий, розірваний, закінчився radio button

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

Що таке Conversational search?

Ми реалізували діалоговий режим: система послідовно уточнює параметри пошуку — контрагент, період, тип документа — і перетворює історію в структурований запит до сховища. LLM (GPT-4o або LLaMA 3 70B) конвертує діалог в параметри фільтрації. Більше не потрібно пам'ятати, як називається стовпець в Excel або куди клікнути в CRM. Ми реалізували такий сценарій для п'яти юросіб з архівами від 50 000 документів — час пошуку скоротився з 15 хвилин до 30 секунд.

Порівняння підходів до пошуку

Критерій Ключовий пошук (Elasticsearch) Тільки ембединги (Qdrant) Гібридний (наш)
Точність за змістом Низька Висока Дуже висока
Пошук за номерами Висока Середня Висока
Швидкість індексації Висока Середня (потрібна генерація ембедингів) Середня
Latency p99 < 100 мс < 200 мс < 300 мс
Підтримка фільтрів Так Обмежена Так (фасети)

Гібридний підхід дає найкращий баланс: на 20% більше recall, ніж у чистих ембедингів, і на 35% більше nDCG@5, ніж у BM25.

Що входить в роботу

В рамках впровадження ми підготовлюємо:

  • Конвеєр індексації (Python + Apache Airflow) для вашого сховища.
  • Векторну БД (Qdrant) з тюнінгованими індексними параметрами.
  • API-ендпоінти для пошуку (REST/gRPC) з підтримкою фасетів.
  • Web-інтерфейс з пошуковим рядком і результатами в картках.
  • Документацію по експлуатації та навчання ваших інженерів (2 дні воркшопу).
  • Місяць технічної підтримки після запуску.

Наш досвід та гарантії

Ми займаємося AI-пошуком більше 5 років, реалізували понад 50 проєктів для банків, логістичних компаній та держсектора. У нашій команді — сертифіковані спеціалісти з машинного навчання (MLflow, Kubeflow). Гарантуємо: система знайде те, що ви шукаєте, з точністю не менше 90% на тестовій вибірці.

Терміни та вартість

Термін реалізації пілотного проєкту — від 3 до 6 тижнів залежно від обсягу архіву та необхідного ступеня кастомізації. Вартість розраховується індивідуально: оцінюємо кількість документів, кількість полів для метаданих, необхідний SLA. Зв'яжіться з нами, щоб ми підготували комерційну пропозицію. Замовте пілотний проєкт на тестовій вибірці — переконайтеся в ефективності до повноцінного впровадження. Отримайте консультацію з впровадження просто зараз.

Довідково: BM25 — класична функція ранжування для оцінки релевантності текстів.