Агентство недвижимости: ИИ-обработка заявок на своём сервере

MAATRIX

У агентства с потоком в полсотни заявок в день менеджер тратит первые пять минут на каждую не на продажу, а на разбор: перечитать сообщение с Авито, понять бюджет и район, открыть базу объектов, вручную сопоставить, написать ответ. При сотне заявок это восемь часов чистого времени, которое не приносит сделок. Решение не в замене менеджера ботом, а в том, чтобы снять с него рутину: извлечь параметры автоматически, подобрать объекты через RAG-поиск по своей базе и подготовить черновик ответа — который менеджер проверяет и отправляет сам, а не ИИ.

Какую задачу решает ИИ в потоке заявок

Заявка приходит с разных каналов — форма на сайте, Telegram-бот, WhatsApp, звонок с расшифровкой — и везде текст свободной формы: «ищем трёшку у метро, до 12 млн, можно вторичку». Дальше цепочка из четырёх шагов, и ни один не должен требовать нового обучения модели — только промпты и работающий RAG:

1. Извлечение параметров — из текста достаются бюджет, район, тип объекта, число комнат, срочность.
2. RAG-поиск по базе объектов — параметры превращаются в запрос к AnythingLLM, который ищет подходящие листинги в своей базе.
3. Сборка черновика — модель формирует человекочитаемое сообщение с 3–5 вариантами.
4. Проверка менеджером — черновик уходит не клиенту, а в интерфейс менеджера (Telegram-бот, CRM-карточка), где его правят и отправляют вручную или одной кнопкой.

Оркестрацию удобно собрать на n8n: вебхук принимает заявку, дергает LLM для извлечения, стучится в API AnythingLLM за подбором, склеивает черновик и кладёт его в очередь на согласование.

Извлечение параметров из свободного текста

Для этого шага не нужна топовая модель — задача узкая, структурированная, достаточно локальной модели среднего размера через Ollama или vLLM, либо недорогого облачного API за прокси. Промпт строится вокруг фиксированной JSON-схемы, а не свободного пересказа:

{
  "budget_from": null,
  "budget_to": 12000000,
  "district": ["Автово", "Кировский район"],
  "property_type": "apartment",
  "rooms": 3,
  "market": "secondary",
  "urgency": "normal",
  "raw_notes": "хотят рядом с метро, готовы смотреть на этой неделе"
}

Системный промпт фиксирует правила нормализации: «возле метро Автово» → район «Автово», «трёшка» → rooms: 3, «до 12 млн» → budget_to: 12000000 при budget_from: null. Без этого модель то возвращает диапазон, то точную цифру, и сопоставление с базой ломается. Дайте модели 5–8 примеров реальных заявок с эталонным JSON прямо в системном промпте — это сильно снижает разброс на пограничных формулировках («не дороже 15», «в пределах 10-13»).

Пример вызова через локальный API-шлюз — модель для извлечения параметров лёгкая, гнаться за GPU-мощностями здесь не нужно:

curl -s http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "extractor-7b",
    "response_format": {"type": "json_object"},
    "messages": [
      {"role": "system", "content": "<промпт с правилами и примерами>"},
      {"role": "user", "content": "Ищем трёшку у метро, до 12 млн, можно вторичку"}
    ]
  }'

Проверяйте вернувшийся JSON схемой (например, через pydantic или zod на стороне n8n-скрипта) и при невалидном ответе — повторный запрос с более строгим промптом, а не падение всего сценария.

База объектов как источник для RAG-поиска в AnythingLLM

RAG работает не по «базе данных» в смысле SQL-таблицы, а по документам в рабочем пространстве AnythingLLM. Значит, каждый объект нужно превратить в короткий текстовый документ — по одному на листинг, а не одним файлом на всю базу, иначе чанкинг порежет объекты пополам и подбор станет случайным:

### Объект #4521
Тип: квартира, вторичный рынок
Район: Автово, ул. Стачек 45
Комнаты: 3, площадь 68 м², этаж 4/9
Цена: 11 800 000 ₽
Особенности: рядом метро (7 мин пешком), школа во дворе, свежий ремонт
Статус: в продаже, эксклюзив агентства
Обновлено: 2026-08-20

Синхронизацию с CRM или 1С делайте по расписанию, а не вручную: скрипт выгружает активные объекты, генерирует такие карточки и заливает их через API AnythingLLM, снятые с продажи — удаляет из workspace, иначе модель будет предлагать клиентам проданные квартиры. Про саму установку и настройку эмбеддера — в статье как установить и настроить AnythingLLM на VPS, а общие принципы RAG по своим документам — в материале про RAG по документам на сервере.

# псевдокод синхронизации, вызывается по cron раз в 15-30 минут
python3 sync_listings.py \
  --crm-api https://crm.internal/api/objects \
  --anythingllm-api http://localhost:3001/api/v1 \
  --workspace real-estate-listings \
  --remove-stale

Держите объекты в отдельном workspace, а не в общем с другими данными агентства (договоры, регламенты) — так проще выставить порог схожести под конкретную задачу и не тащить в подбор лишний контекст.

Подбор объектов и черновик ответа менеджеру

Когда параметры извлечены, запрос к AnythingLLM формулируется не как пересказ письма клиента, а как структурированный вопрос к workspace:

Найди до 5 объектов: тип "квартира", вторичный рынок,
бюджет до 12 000 000 ₽, район Автово или Кировский район,
3 комнаты. Для каждого укажи адрес, цену, площадь, этаж.
Если точных совпадений нет — покажи ближайшие по бюджету с пометкой отклонения.

Системный промпт workspace задаёт формат ответа и жёсткое правило: не придумывать характеристики, которых нет в документах, и явно писать «в базе нет точных совпадений», если порог схожести не пройден. Ответ модели — это ещё не сообщение клиенту, а сырой список; отдельным шагом (тем же вызовом LLM или следующим узлом в n8n) он оборачивается в дружелюбный черновик:

> Добрый день! По вашему запросу (трёшка, до 12 млн, район Автово) нашли 3 варианта: ул. Стачек 45 — 11.8 млн, 68 м², 4/9 этаж, 7 минут до метро...

Черновик уходит в интерфейс менеджера с пометкой источника (номера объектов, использованный запрос) — это важно для следующего шага.

Почему черновик, а не автоответ клиенту напрямую

Соблазн — замкнуть цепочку и отправлять сообщение клиенту сразу после генерации. Не делайте так, и вот почему:

• Модель может ошибиться в цифрах. Даже при RAG по своей базе LLM иногда домысливает деталь, которой нет в документе, особенно если объектов найдено мало и она «дотягивает» ответ до нужного объёма.
• Юридические нюансы видит только человек. Эксклюзивность, статус задатка, договорённости с продавцом по показам — это контекст, которого нет в карточке объекта и который менеджер держит в голове.
• Репутационный риск асимметричен. Неверная цена или адрес в письме клиенту стоит дороже, чем несколько минут менеджера на проверку черновика.
• Аудируемость. Черновик с пометкой «сгенерировано ИИ, объекты #4521, #4530» позволяет разобрать, почему клиенту предложили именно это, если возникнет спор.

Практическая реализация — Telegram-бот для менеджера с инлайн-кнопками «Отправить как есть» / «Править» / «Отклонить», а не прямая интеграция черновика в канал клиента. Кнопка «Отправить» вызывает уже проверенный человеком текст.

Почему свой сервер, а не облачный SaaS

Для агентства недвижимости данные в этом сценарии — не абстрактный «текст», а два чувствительных пласта: персональные данные обратившихся (телефон, имя, иногда паспортные детали при просмотре) и коммерчески значимая база объектов, часто с эксклюзивными листингами, которые конкуренты были бы рады получить.

Технически это не требует GPU-фермы: извлечение параметров и сборка черновика — лёгкие задачи, для которых достаточно CPU-сервера с локальной моделью среднего размера или единого шлюза к внешним API через LiteLLM (сравнение развёрнуто в статье единый шлюз к OpenAI, Claude и Gemini на своём сервере) — тогда сами тексты заявок физически проходят через ваш прокси, логируются и фильтруются перед отправкой во внешний API, а не улетают напрямую в стороннее SaaS-приложение с чужими условиями обработки данных. Про ограничение доступа к такой инсталляции — в материале как защитить локальную LLM от посторонних.

Частые вопросы