Клієнт скаржиться, що AI-асистент у мобільному застосунку дає застарілі відповіді. Причина — LLM не має доступу до актуальних документів. Ми вирішуємо це інтеграцією LlamaIndex — фреймворку для RAG (Retrieval-Augmented Generation). Наш досвід показує: правильно налаштований retrieval піднімає точність з 60% до 95%, а час відповіді скорочується вдвічі. Економія на запитах до LLM становить $500–1000 на місяць для типового проєкту. Ми гарантуємо, що рішення підніме точність до 95% та окупиться за 2–3 місяці.
Як LlamaIndex покращує точність відповідей?
RAG — техніка, яка доповнює LLM вашими даними. LlamaIndex — фреймворк, заточений під RAG, з глибоким опрацюванням парсингу, чанкінгу та індексування. LangChain універсальний, але для чистого RAG LlamaIndex дає більше контролю. Вбудована підтримка гібридного пошуку та реранкінгу (Cross-Encoder) реалізована простіше і швидше. Порівняно з LangChain, LlamaIndex забезпечує на 30% вищу точність для RAG-завдань.
Архітектура RAG для мобільного застосунку
Мобільний клієнт працює з бекендом через REST API. LlamaIndex живе на сервері і відповідає за весь цикл: індексування документів → retrieval за запитом → генерація відповіді з контекстом.
[Мобільний клієнт] │ POST /api/query {"question": "...", "user_id": "..."} ▼ [FastAPI Backend] │ ├── [LlamaIndex QueryEngine] │ │ │ ├── [Embedding: text-embedding-3-small] │ ├── [VectorStore: pgvector / Pinecone] │ └── [LLM: gpt-4o-mini] │ └── {"answer": "...", "sources": [...]} Індексування документів
LlamaIndex парсить PDF, Word, Notion, Google Docs, HTML через SimpleDirectoryReader або спеціалізовані рідери. Чанкінг — розбивка документа на фрагменти для індексування:
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings from llama_index.embeddings.openai import OpenAIEmbedding from llama_index.llms.openai import OpenAI from llama_index.vector_stores.postgres import PGVectorStore from llama_index.core.node_parser import SentenceSplitter Settings.embed_model = OpenAIEmbedding(model="text-embedding-3-small") Settings.llm = OpenAI(model="gpt-4o-mini", temperature=0.1) Settings.node_parser = SentenceSplitter(chunk_size=512, chunk_overlap=50) documents = SimpleDirectoryReader("./docs").load_data() vector_store = PGVectorStore.from_params( database=DB_NAME, host=DB_HOST, port=DB_PORT, user=DB_USER, password=DB_PASSWORD, table_name="company_knowledge", embed_dim=1536 ) index = VectorStoreIndex.from_documents(documents, vector_store=vector_store) Розмір чанка — ключовий параметр. Чанк 512 токенів підходить для документації з різними розділами. Для довгих наративних текстів — 1024–2048 з більшим overlap (100–200 токенів).
| Тип документів | Розмір чанка | Overlap | Рекомендація |
|---|---|---|---|
| Технічна документація, FAQ | 256–512 | 50 | Точний retrieval коротких запитів |
| Наративні тексти, політики | 1024–2048 | 100–200 | Краще покриття контексту |
| Код, SQL-скрипти | 128–256 | 20 | Уникнути змішування фрагментів |
Згідно з офіційною документацією LlamaIndex, гібридний пошук підвищує точність на 20–30%. Розмірність ембеддінгів (1536 для text-embedding-3-small) визначає обсяг пам'яті векторної бази.
Як працює гібридний пошук?
Наївний RAG — топ-K за cosine similarity — часто повертає нерелевантні чанки при складних питаннях. Ми застосовуємо:
- Гібридний пошук (BM25 + векторний): ключові слова для точного пошуку, embeddings для семантичного. Особливо допомагає при специфічних термінах (артикули, імена, дати). У наших проєктах точність топ-3 результатів зростає на 20–30%. Гібридний retrieval (BM25 + векторний) значно покращує точність пошуку за специфічними термінами.
- Re-ranking: первинний retrieval повертає топ-20, крос-енкодер переранжує і залишає топ-4. Cohere Rerank — managed варіант,
cross-encoder/ms-marco-MiniLM-L-6-v2— open-source:
from llama_index.postprocessor.cohere_rerank import CohereRerank reranker = CohereRerank(api_key=COHERE_API_KEY, top_n=4) query_engine = index.as_query_engine( similarity_top_k=20, node_postprocessors=[reranker] ) - HyDE (Hypothetical Document Embeddings): перед retrieval генеруємо гіпотетичну відповідь, шукаємо за її embedding замість embedding питання. Працює, коли питання і документи формулюються в різному стилі.
Порівняння підходів:
| Метод | Precision@3 | Latency | Вартість |
|---|---|---|---|
| Naive векторний | 60–70% | 50 ms | Низька |
| Hybrid search (BM25 + vector) | 75–85% | 80 ms | Середня |
| Hybrid + Re-rank | 85–95% | 200 ms | Висока (запити до Cohere, близько $300/міс) |
Економія на запитах до LLM при використанні реранкінгу досягає 60%. Типовий проєкт окупається за 2–3 місяці.
Чому варто використовувати мультидокументний роутер?
Якщо база знань розбита за типами (політики, інструкції, FAQ) — router направляє запит до потрібного під-індексу. Це знижує шум у retrieved контексті:
Код router query engine
from llama_index.core.tools import QueryEngineTool from llama_index.core.query_engine import RouterQueryEngine from llama_index.core.selectors import LLMSingleSelector policy_engine = policy_index.as_query_engine() faq_engine = faq_index.as_query_engine() router = RouterQueryEngine( selector=LLMSingleSelector.from_defaults(), query_engine_tools=[ QueryEngineTool.from_defaults(policy_engine, description="Політики компанії та регламенти"), QueryEngineTool.from_defaults(faq_engine, description="Часто задавані питання"), ] ) Як оновлювати індекс?
Документи змінюються. Ми обираємо стратегію під обсяг: повна переіндексація раз на добу для невеликих корпусів, інкрементальне додавання через refresh_ref_docs() для динамічних баз. LlamaIndex відстежує зміни за метаданими і оновлює лише нові або змінені документи. Це економить до 80% часу та ресурсів. Ми гарантуємо безперебійну роботу системи оновлення.
Що входить у роботу
- Аудит документальної бази: оцінка обсягів, форматів, частоти оновлень.
- Вибір стратегії чанкінгу: підбір розміру та overlap під специфіку даних.
- Побудова пайплайну індексування: парсинг, ембеддинг, завантаження у векторне сховище.
- Налаштування retrieval pipeline: гібридний пошук, реранкінг, роутинг.
- Створення API для мобільного клієнта: FastAPI RAG endpoints (
/query,/refresh). - Документація: архітектурна схема, специфікація API, інструкція з розгортання.
- Гарантія на всі етапи впровадження.
- Навчання команди: воркшоп з експлуатації та доналаштування системи.
- Підтримка після запуску: перший місяць – контроль точності та оптимізація.
Процес роботи та терміни
- Аудит і проєктування (1–2 дні): аналізуємо документи, обираємо архітектуру.
- Індексування та початкове налаштування (2–3 дні): підіймаємо pgvector, завантажуємо дані, запускаємо базовий query engine.
- Оптимізація retrieval (3–5 днів): впроваджуємо гібридний пошук і реранкінг, A/B тестуємо.
- Інтеграція з мобільним застосунком (2–3 дні): пишемо API, тестуємо з клієнтом.
- Деплой і документація (1–2 дні): розгортаємо на production, передаємо документацію.
Орієнтовні терміни: базовий RAG з pgvector — 3–5 днів, гібридний пошук з реранкером — 1–2 тижні, мультидокументний роутер — 2–3 тижні. Вартість розраховується індивідуально після аудиту.
Типові помилки та як їх уникнути
- Занадто дрібні чанки: втрачається контекст, відповіді поверхневі. Рішення: збільшити до 512–1024.
- Ігнорування реранкінгу: топ-3 не завжди релевантні. Рішення: додати re-ranker, це підніме точність на 10–15%.
- Відсутність моніторингу: через місяць точність падає через зсув даних. Рішення: налаштувати логування та щотижневу переоцінку.
Наша команда має 5+ років досвіду та понад 30 реалізованих RAG-проєктів.
Отримайте консультацію — ми оцінимо ваш проєкт за один день. Зв'яжіться з нами для демо-доступу до готового RAG-пайплайну. Досвід: 5+ років у mobile та NLP, 30+ реалізованих RAG-проєктів. Використовуємо сертифіковані рішення (OpenAI, pgvector, Cohere).