Клиент жалуется, что AI-ассистент в мобильном приложении даёт устаревшие ответы. Причина — LLM не имеет доступа к актуальным документам. Мы решаем это интеграцией LlamaIndex — фреймворка для RAG (Retrieval-Augmented Generation). Наш опыт показывает: правильно настроенный retrieval поднимает точность с 60% до 95%, а время ответа сокращается в 2 раза. Экономия на запросах к LLM составляет $500–1000 в месяц для типового проекта.
Как LlamaIndex улучшает точность ответов?
RAG — техника, которая дополняет LLM вашими данными. LlamaIndex — фреймворк, заточенный под RAG, с глубокой проработкой парсинга, чанкинга и индексирования. LangChain универсален, но для чистого RAG LlamaIndex даёт больше контроля. Встроенная поддержка гибридного поиска и реранкинга (Cross-Encoder) реализована проще и быстрее.
Архитектура 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%.
Как работает гибридный поиск?
Наивный RAG — топ-K по cosine similarity — часто возвращает нерелевантные чанки при сложных вопросах. Мы применяем:
- Гибридный поиск (BM25 + векторный): ключевые слова для точного поиска, embeddings для семантического. Особенно помогает при специфических терминах (артикулы, имена, даты). В наших проектах точность топ-3 результатов вырастает на 20–30%.
- 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 с эндпоинтами
/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%.
- Отсутствие мониторинга: через месяц точность падает из-за сдвига данных. Решение: настроить логирование и еженедельную переоценку.
Получите консультацию — мы оценим ваш проект за один день. Свяжитесь с нами для демо-доступа к готовому RAG-пайплайну. Опыт: 5+ лет в mobile и NLP, 30+ реализованных RAG-проектов. Используем сертифицированные решения (OpenAI, pgvector, Cohere).