Розробка Question Answering (відповіді на питання за документами)
Клієнт скаржиться: «У нас 10 000 документів в Confluence, але знайти відповідь — лотерея». Типова ситуація: співробітники витрачають до 30% робочого часу на пошук інформації. Ми вирішуємо це за допомогою питально-відповідної системи на базі RAG (Retrieval-Augmented Generation) — підходу, що поєднує ретрівл і генерацію. Вона дозволяє задавати питання природною мовою та отримувати точні відповіді з цитуванням джерел. За 5+ років ми реалізували понад 50 NLP-проєктів, і RAG — основний інструмент для корпоративних баз знань та інтелектуального пошуку. Згідно з Question Answering, задача QA полягає у вилученні або синтезі відповіді з набору документів.
RAG перевершує extractive QA в задачах узагальнення — точність на 15% вища, а галюцинації знижені вдвічі. Для юридичної компанії з 5000+ договорів ми досягли F1 82% та часу пошуку 30 секунд. RAG також дешевший за Long-context LLM в 10 разів при порівнянній якості.
Чому RAG — найкращий підхід для Question Answering?
Extractive QA (моделі deepset/roberta-base-squad2, sberbank-ai/rubert-base-cased-qa) гарна, коли відповідь — точна цитата. Але якщо питання вимагає узагальнення або інформації з кількох документів — extractive не справляється. Long-context LLM (Claude 3.5, 200K токенів) простіше, але дорого та не масштабується понад 500 сторінок. RAG — золота середина: дешевий пошук за векторними індексами + синтез відповіді LLM. Ми використовуємо його в 90% проєктів.
| Підхід | Точність | Галюцинації | Вартість | Масштабованість |
|---|---|---|---|---|
| Extractive | Висока (EM ~80%) | Мінімум | Низька | Висока |
| RAG | Середня (F1 ~75%) | Помірні | Середня | Дуже висока |
| Long-context | Висока | Є | Висока | Низька |
Які проблеми вирішуємо?
На типовому проєкті клієнти стикаються з трьома проблемами:
- Дані в різних системах. Confluence, SharePoint, Google Drive, 1С — документи розрізнені. Ми будуємо єдиний індексатор через Airbyte або кастомні ETL-пайплайни.
- Таблиці та скани. LLM погано розуміє складні таблиці. Використовуємо Text2SQL або serialization в Markdown. Для сканів — Tesseract + layout-parser, що забезпечує якісне розпізнавання документів.
- Висока latency. Користувачі не хочуть чекати >5 секунд. Оптимізуємо: кешування ембедінгів, batch-інференс, vLLM для GPU.
Як ми це робимо: кейс юридичної компанії
Для однієї юридичної компанії (5000+ договорів у PDF) ми запустили RAG-систему за 3 тижні. Стек: LangChain + Qdrant + GPT-4o-mini. Результат: час пошуку скоротився з 15 хвилин до 30 секунд, точність відповідей — 82% (F1). Ключове — додали Faithfulness check: окремий промпт перевіряє, що кожен факт у відповіді підтверджується хоча б одним документом. Якщо ні — система пише «В документах немає інформації».
Параметри chunking підбирали експериментально:
| Розмір чанка | Перекриття | F1 на тестовому сеті |
|---|---|---|
| 256 токенів | 32 | 78% |
| 512 токенів | 64 | 82% |
| 1024 токенів | 128 | 80% |
Для підвищення точності використовуємо гібридний пошук: dense embeddings (OpenAI text-embedding-3-small) комбінуються з BM25, а потім re-ranking через Cohere rerank v3. Це дає приріст F1 ще на 3-5 процентних пунктів.
Як ми оцінюємо якість відповідей?
Ми створюємо тестовий датасет зі 100+ питань, що покривають типові сценарії. Метрики: F1, EM (exact match), faithfulness (частка відповідей без галюцинацій), latency p95. Цільовий поріг — F1 ≥ 75% та faithfulness ≥ 95%. При необхідності доналаштовуємо retriever (налаштування k, вибір моделі ембедінгів) або LLM (few-shot промпти).
Приклад конфігурації індексатора
from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain_community.vectorstores import Qdrant from langchain.chains import RetrievalQA embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = Qdrant.from_existing_collection( embeddings=embeddings, url="http://localhost:6333", collection_name="docs" ) llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 5}), return_source_documents=True, ) result = qa_chain.invoke({"query": "Який порядок розірвання договору?"}) Скільки коштує впровадження QA-системи?
Базовий проєкт (до 10 000 сторінок, 1 джерело) — від 3 до 5 тижнів. Складний (множинні джерела, таблиці, скани) — від 6 до 10 тижнів. Точну вартість називаємо після аудиту даних — пишіть, оцінимо ваш кейс безкоштовно. Типовий проєкт окупається за 3-6 місяців завдяки скороченню часу пошуку.
Процес роботи
- Аналітика: аудит джерел даних, типів документів, обсягів, частоти запитів.
- Проєктування: вибір архітектури (RAG / hybrid / multi-agent), визначення пайплайну chunking, embedding, retrieval.
- Реалізація: індексація даних, налаштування LLM, інтеграція з корпоративними системами (Confluence, SharePoint, Telegram bot).
- Тестування: створення тестового датасету зі 100+ питань, оцінка метрик (F1, EM, faithfulness, latency).
- Деплой та моніторинг: розгортання на Kubernetes або Managed ML (SageMaker, Vertex AI), логування відповідей, A/B тестування.
Що входить в deliverables
- Індексатор документів з підтримкою інкрементального оновлення
- REST API для питань (Swagger-документація)
- Веб-інтерфейс (simple chat UI)
- Інтеграція з месенджерами (Telegram, Slack) — опціонально
- Дашборд метрик (кількість запитів, latency p95, відсоток відмов)
- Документація з експлуатації
- Навчання команди (2-3 години)
- Гарантія 3 місяці на баги
Наші інженери сертифіковані за AWS та GCP, гарантуємо точність не нижче 75% F1 на ваших даних. Замовте аудит — ми оцінимо обсяг, типи документів та терміни впровадження. Отримайте консультацію та комерційну пропозицію за 1-2 дні.