RAG-ассистент для торгового центра: полностью локально

Недавно разбирал концепцию локальной информационно-справочной системы для торгового центра. Задача звучит просто: посетитель спрашивает «где купить беговые кроссовки со скидкой?» — и получает нормальный ответ на человеческом языке, а не голый список этажей.

Что за система

Подход — RAG (Retrieval-Augmented Generation). Грубо говоря: система ищет релевантные данные в базе ТЦ, передаёт их языковой модели, та формирует готовый ответ. Никакого облака — всё на локальном сервере.

Три языка: русский, английский, китайский. Один индекс, пользователь пишет на любом — отвечает на том же.

Точки доступа: сайт, мобилка, киоски внутри ТЦ (им нужен только браузер, вся нагрузка на центральный сервер).

Откуда берутся данные

Источник — уже существующая БД MySQL. Из неё генерируются текстовые карточки:

Магазин: SportLand
Этаж: 2
Категория: спорттовары
Акция: скидка 20%

Карточка → embedding → векторная база → привязка к исходной записи MySQL.

Стек

• Векторная БД: Qdrant (или PostgreSQL + pgvector)
• LLM: Qwen 14B / 32B Instruct
• Embeddings: bge-m3 или Qwen Embedding
• Backend: Python FastAPI
• Frontend: Vue/Nuxt или React/Next.js

Почему Qwen, а не DeepSeek

Сравнивали два варианта. Для RAG-задач Qwen выигрывает: лучше держится за контекст, меньше галлюцинаций, стабильнее мультиязычность и особенно китайский. DeepSeek сильнее в reasoning и аналитике — но это не наш кейс.

Железо

Для рабочего сервера ТЦ оптимально:

• CPU: 16–24 ядра
• RAM: 64–128 GB
• GPU: RTX 4090 (24 GB)
• NVMe SSD 2 TB + UPS + Docker

Роадмап MVP

Этап 1: магазины, товары, акции, режим работы.
Этап 2: мероприятия, детские зоны, маршруты.
Этап 3: голосовой ввод, аналитика запросов, персонализация.

Итог

Архитектура MySQL + Qdrant + Qwen + FastAPI + Web UI — реалистичная и самодостаточная. Никакой зависимости от облака, полный контроль над данными внутри ТЦ.