Построение сложного RAG для работы с технической документацией

Можно ли взять любой RAG засунуть туда документацию и получить крутой ответ?
Спойлер: НЕТ

На этой неделе я исследовал возможности построения RAG-системы
для работы со сложными многосоставными 2-3-4 задания в одном запросе к технической документации
Хочу поделиться интересными находками и подходом, который дал хорошие результаты

Тестовый кейс документация Manticore Search

Для тестирования подхода я взял документацию Manticore Search - высокопроизводительной базы данных для поиска и аналитики
Она отлично подходит для скачивания есть на GitHub в формате md
- Множество взаимосвязанных концепций
- Комбинация SQL и HTTP API
- Специфичные форматы данных (векторы, JSON)
- Различные режимы работы (RT, Plain)

А теперь к проблеме

Классический подход к RAG (просто разбить документацию на чанки и искать по ним) не работает для сложных технических запросов
Например, запрос

"Покажи как оформить json чтобы делать replace в knn колонках 
RT индекса поле называется embedding и пришли пример python запроса"

Кстати предлагаю вам попробовать самим проверить свой RAG сможете ли добиться такого же ответа как у меня (в комментариях)

Такой запрос требует
- Понимания контекста (что такое RT индекс, KNN колонки)
- Объединения информации из разных частей документации
- Генерации корректных примеров кода
- Проверки технической точности

Архитектура эксперимента

- Qwen 7B (16 FP) на RTX 4090
- Multilingual E5 Large для эмбеддингов
- Собственный механизм Chain of Thought

Структура данных в Milvus:

Collection: documentation
Fields:
  - id: primary key
  - filename: string (для формирования ссылок в ответе)
  - chunk_text: string (текст чанка)
  - embeddings: float_vector[1024] (векторы от e5-large)
  - category: string (раздел документации)
  - subcategory: string (подраздел)
  - full_text: string (полный текст документа)

После поиска, объединяем найденные чанки по иерархии документации, получая ~30K токенов контекста для LLM. Ответ в формате Markdown будет содержать
- Уровень анализа запроса
- Найденные документы с их URL
- Готовые примеры кода
- Полный текст документации

Процесс обработки запроса

Query Expansion
- Используем LLM для генерации 3-5 альтернативных запросов
- Учитываем технический контекст
- Переводим на язык документации (английский)

Векторный поиск
- Для каждого расширенного запроса ищем топ-3 результата
- Получаем ~9 релевантных чанков
- Используем иерархию документации для контекста

Объединение + ответ
- Делюсь с вами своей схемой SO + CoT + Outlines + vLLM (В комментариях) + ответ модели на такой запрос

Так и по классике выводы

Что особенного и можно ли повторит?
0) Да самое важное уделить время на разработку стратегии разметки и поиска
(ой маркетинг где RAG работает с любой докой не правда? Как так? =))
1) Статический Chain of Thought
2) Оптимизация контекста по иерархии
3) Локальное развертывание
4) Понимание работы Structured Output

P.S
Решение субъективно и основано на конкретном опыте
Требуется дальнейшее тестирование на разных типах документации
Возможны ошибки при очень специфических запросах
Считаю что нужен агент планировщик поиска по документации

P.S.S Все примеры и код основаны на реальном опыте работы с технической документацией Manticore Search