Как построить RAG‑систему для вопросов о нарушениях в гражданской авиации

Постановка задачи

Набор данных «Global Civil Aviation Disruption 2026», размещённый на Kaggle, содержит шесть CSV‑файлов с более чем 200 записями о финансовых потерях авиакомпаний, закрытых аэропортах, отменённых рейсах и событиях конфликта между Ираном и США. В чистом виде такие таблицы неудобны для конечного пользователя: чтобы выяснить, какая авиакомпания понесла наибольшие убытки или какие аэропорты в Иране закрыты, приходится вручную просматривать строки. Цель проекта – превратить эти табличные данные в разговорный интерфейс, где любой запрос на естественном языке будет мгновенно отвечен с указанием источника.

Что такое Retrieval‑Augmented Generation (RAG)

RAG‑подход объединяет два этапа:

1. Retrieval (поиск) – из большого корпуса данных выбираются наиболее релевантные фрагменты, которые могут помочь ответить на запрос.
2. Generation (генерация) – выбранные фрагменты передаются в большую языковую модель (LLM), которая формирует человекочитаемый ответ.

Главное преимущество: нет необходимости дообучать модель на специфических данных. Вместо этого LLM получает нужный контекст в момент запроса, что существенно экономит ресурсы и ускоряет вывод.

Архитектура решения

Система построена из следующих компонентов:

Подготовка и индексация данных

1. Парсинг CSV – скрипт последовательно читает файлы, преобразуя каждую запись в короткий абзац. При этом сохраняется мета‑информация (название таблицы, идентификатор строки) для последующего указания источника.
2. Создание эмбеддингов – полученный текст передаётся в модель all-MiniLM-L6-v2, которая генерирует 384‑мерный вектор. Векторы сразу записываются в ChromaDB вместе с метаданными.
3. Тестирование качества поиска – несколько типовых запросов («Какие рейсы отменил аэропорт Тегеран в июле?») проверяются на релевантность возвращаемых чанков. При необходимости корректируются параметры top_k и score_threshold.

Обработка запросов через LangChain

LangChain выступает «проводником» между пользовательским запросом и LLM:

1. Retriever – из ChromaDB выбирает k=5 наиболее похожих векторов.
2. PromptTemplate – формирует шаблон, где в начало помещается системное сообщение о том, что модель должна отвечать, используя только предоставленные чанки, и в конце – список найденных фрагментов.
3. LLM – в качестве генератора используется gpt‑3.5‑turbo (через OpenAI API). Благодаря строгому шаблону модель ограничена только тем контекстом, который ей передали.
4. Post‑processing – из ответа вытаскиваются ссылки на оригинальные строки CSV, которые отображаются в UI.

API и пользовательский интерфейс

FastAPI предоставляет единственный эндпоинт /query, принимающий JSON‑объект { "question": "..." }. Ответ содержит:

• answer – сформированный текстовый ответ.
• sources – массив объектов { "table": "...", "row_id": "...", "snippet": "..." }.

Angular‑приложение реализует чат‑виджет: пользователь вводит запрос, получает ответ и список источников в виде кликабельных ссылок, открывающих соответствующую строку в таблице. Компонент также показывает индикатор загрузки, позволяя понять, когда система обрабатывает запрос.

Развёртывание и эксплуатация

Контейнер Docker собирает образ со всеми зависимостями (Python‑скрипт, FastAPI, ChromaDB). На Hugging Face Spaces образ автоматически запускается в окружении с поддержкой GPU, однако для текущей модели all-MiniLM-L6-v2 и gpt‑3.5‑turbo GPU не требуется. В продакшн‑режиме система обслуживает несколько запросов в секунду, а кеширование популярных запросов в памяти уменьшает нагрузку на LLM.

Практические выводы

• Эмбеддинги CPU‑ориентированных моделей позволяют построить полностью локальное решение без дорогостоящих GPU‑ресурсов. Для небольших наборов данных (до нескольких тысяч записей) такой подход более чем достаточен.
• LangChain упрощает интеграцию компонентов: от поиска до формирования запросов к LLM. Это особенно ценно, когда требуется быстро экспериментировать с разными векторными хранилищами или LLM‑провайдерами.
• Метаданные в векторном хранилище критичны для прозрачности: пользователи видят, откуда именно получена информация, что повышает доверие к системе.
• Разделение на микросервисы (API + фронтенд) облегчает масштабирование. При росте количества записей можно вынести ChromaDB в отдельный сервер, а FastAPI оставить как лёгкий шлюз запросов.
• Ограничение контекста через шаблоны запросов к LLM предотвращает «галлюцинацию» модели и гарантирует, что ответы опираются только на проверенные данные.

Эта RAG‑система демонстрирует, как из простого CSV‑набора получить интерактивный, источник‑подкреплённый вопрос‑ответный сервис, пригодный как для аналитиков, так и для широкой аудитории, интересующейся влиянием геополитических конфликтов на гражданскую авиацию.