ИИ-агенты на рынке недвижимости: эволюция

Всем привет! Меня зовут Алина. На связи снова компания Домклик. Сегодня мы обсудим очень горячую тему этого года — разработку ИИ-агентов. Недавно я выступила с докладом на конференции HighLoad++ 2025 ^[1], и, думаю, всем будет интересно узнать, как мы создавали ИИ-агентов для рынка недвижимости прошедшим летом. Несмотря на уже существовавшие Transformer-модели, массового интереса ^[2] вокруг агентов тогда не наблюдалось. Однако в этом году ситуация кардинально изменилась.

Эволюция чат-бота до агента-консультанта

Недавно мы, как и многие другие, начали развивать текстовый чат-бот в канале коммуникаций «Чат». Он имел следующий сценарий использования: клиент, желающий оформить ипотеку, купить или сдать недвижимость, задаёт вопрос и получает ответ либо от менеджера, либо от бота. То есть чат-бот выполнял роль первой линии поддержки. Его основные задачи:

• Распознавать намерение (интент) пользователя

• Вести диалог по заранее прописанным сценариям

• Выполнять действия в рамках этих сценариев (например, запись на сделку)

• При необходимости переключать диалог на оператора

Как это работало технически:

1. Пользователь отправлял запрос в чат

2. Запрос векторизовался, затем выполнялся поиск похожих вопросов в векторной базе знаний

3. Полученные кандидаты ранжировались с помощью языковой модели Gemma 2, выступающей в роли ранжировщика (re-ranker)

4. Пользователю предлагался список наиболее релевантных сценариев

5. После выбора сценария дальнейшим диалогом управлял сценарный движок 

Подробнее о выборе LLM и подходе к определению тематик можно узнать в статье «Как мы прикрутили RAG или трудности перевода на LLM‑ский ^[3]».

Параллельно был реализован поиск по сайту. Сценарий работы следующий: пользователь вводил текстовый запрос, например, «хочу подобрать недвижимость». Запрос векторизовался, и в векторном хранилище искались релевантные статьи. Эти статьи извлекались, обрабатывались языковой моделью GigaChat Max для суммаризации и ранжирования, после чего клиент получал структурированный ответ с полезными материалами.

В I квартале текущего года перед нами стояла задача разработки ИИ-агента. Для этого мы объединили две вышеописанные функции — чат-бот и умный поиск.

Архитектура решения включает в себя две цепочки RAG:

1. Сначала запрос проходит через RAG для классификации интентов

2. В случае отсутствия подходящего интента система выполняет поиск ответа по статьям в RAG

3. Если ответ не найден и на этом этапе, диалог перенаправляется на оператора

Почему это уже агент? Главное отличие от обычного чат-бота заключается в появлении у системы следующих характеристик, присущих агенту:

• Роль: ИИ больше не абстрактный бот, а интеллектуальный помощник Домклик, эксперт в сфере недвижимости

• Цепочка рассуждений: система сама определяет оптимальный путь для обработки запроса

• Предметная область: глубокая специализация в сфере недвижимости и ипотеки

• Автономность: способность самостоятельно выполнять многошаговые задачи

• Память ^[4]: в качестве памяти агента используется история переписки (последние 50 сообщений), что позволяет учитывать контекст диалога

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

В процессе разработки мы столкнулись с рядом трудностей:

1. Отсутствие готовых MCP-серверов (Model Context Protocol ^[5]) для корпоративных API. Подключение всех внутренних API для агентов оказалось сложной задачей, поэтому на старте мы обходились без MCP, постепенно интегрируя их.

2. Отсутствие подготовленной базы знаний. Сферы недвижимости и ипотечного кредитования очень объёмны. Изначально наша база знаний была минимальной, что потребовало проектирования отдельного сервиса для её управления и наполнения.

3. Необходимость анонимизации данных. Для использования облачной модели GigaChat Max нам пришлось реализовать механизм очистки запросов и ответов от персональных данных.

4. Доработка цензора. Стандартные фильтры не подходят для нашей предметной области, поэтому потребовалась их тонкая настройка

5. Недетерминированность ответов моделей. Эта проблема актуальна и сейчас. Для её решения мы применяем нестандартные методы, в частности, используем строгие инструкции в промптах: «никогда не упоминай любые имена и фамилии», «никогда не отказывайся отвечать» и «никогда не объясняй причин отказа».

Архитектура платформы для ИИ-агентов: ключевые компоненты

Мы подошли к фундаментальному вопросу: «как должна быть устроена платформа для создания и управления ИИ-агентами? Опираясь на наш опыт ^[6], мы выделили ряд ключевых технологических компонентов, которые составляют основу «агентности».

LLM как ядро системы: умный шлюз и маршрутизация

Первым и ключевым компонентом являются большие языковые модели (LLM). Как я уже упоминала, мы используем несколько моделей, включая Gemma 2 и GigaChat Max. Именно они отвечают за базовые способности агента: планирование, анализ, рассуждение и принятие решений.

Когда моделей несколько, возникает задача их эффективного управления. Для этого мы применяем паттерн LLM API Gateway, решающий ряд критически важных задач:

• Интеллектуальная маршрутизация: запросы могут направляться в конкретную LLM, исходя из их типа, сложности или других правил

• Бюджетирование и лимиты: шлюз обеспечивает контроль над потреблением ресурсов каждым агентом (например, можно установить ограничения на количество запросов или токенов в месяц)

• Мониторинг и аналитика: мы получаем полную картину использования моделей: кто, как часто и с какими ошибками обращается к ним

• Кеширование: возможность кешировать запросы для экономии ресурсов и ускорения времени отклика

В качестве основы для нашего шлюза мы выбрали open-source фреймворк LiteLLM ^[7]. Он написан на Python, что позволяет гибко его расширять и дорабатывать. Например, мы добавили поддержку function calling для специфичного контракта API GigaChat Max.

Инструменты (Tools): руки агента

Для взаимодействия с внешним миром — вызовами API, работой с базами данных, автоматизацией задач — агенту необходимы инструменты. Управление этими инструментами осуществляется с помощью усовершенствованного Model Context Protocol (MCP). В рамках его доработки были реализованы следующие улучшения:

• Добавлены приватные переменные, чтобы скрыть критичные данные от контекста модели

• Контекст вызова дополнен метаинформацией о том, какой агент, когда и зачем вызывает инструмент

• Реализована дополнительная обработка JSON-схем, чтобы убедиться, что модели корректно их понимают

Память: краткосрочная и долгосрочная

Память агента мы разделяем на несколько типов:

• Краткосрочная память: используется для хранения контекста текущей сессии. Для этого мы используем Redis.

• Долгосрочная память: подразделяется на два типа:

  1. Семантическая память: наш RAG-конвейер, отвечающий за знания компании. Подробнее об этом расскажу ниже.

  2. Эпизодическая память: содержит историю взаимодействий агента с клиентом. Каждое взаимодействие не только сохраняется, но и векторизуется, что позволяет осуществлять поиск по прошлым действиям, просматривать последние 50 диалогов или анализировать конкретные случаи. Эпизодическая память особенно важна в мультиагентных системах, где несколько агентов работают над одной большой задачей и нуждаются в общем контексте.

RAG (Retrieval-Augmented Generation): экспертиза в документах

Наш RAG-конвейер — это механизм, который векторизует и индексирует внутренние документы. Технический стек включает в себя:

• OpenSearch в качестве векторной базы данных

• Векторизатор E5 для создания эмбеддингов

• Сплиттер от LangChain для сегментации документов на чанки

Коммуникация и мультиагентность

Когда агентов становится много, они должны уметь общаться друг с другом. Мы рассмотрели два фреймворка для организации этого взаимодействия: Agent Communication Protocol от IBM и A2A (Agent-to-Agent) от Google. При выборе мы руководствовались поддержкой REST, возможностью использования карточек агентов и простотой реализации. К счастью, оба проекта были объединены под эгидой Linux Foundation, что избавило нас от необходимости миграции с нестабильного решения.

Мультиагентность требует оркестрации. Одним из популярных паттернов является наличие координирующего узла, управляющего группой узкоспециализированных агентов. Эту структуру можно рассматривать как единого агента верхнего уровня.

Для реализации мы выбрали графовый фреймворк NetworkX, предоставляющий следующие возможности:

• Позволяет создать кастомный конструктор агентов

• Гибкое управление состоянием системы

• Сохранение чекпоинтов в базе данных, что позволяет останавливать и возобновлять работу агента

Высокоуровневая архитектура платформы

В центре нашей системы находится компонент Agent Runtime. Это среда исполнения, где запускается множество агентов. Каждый агент работает в своём изолированном пространстве, что обеспечивает удобное масштабирование под любую нагрузку.

Agent Runtime взаимодействует со всеми остальными компонентами:

• LLM API Gateway: обеспечивает доступ к моделям

• MCP-серверы: предоставляют необходимые инструменты

• RAG-пайплайн: реализует память и базу знаний

Для синхронного взаимодействия с клиентом, несмотря на потенциально длительное время ответа LLM, применяется паттерн RPC over RabbitMQ. Это позволяет выдерживать заданные таймауты и возвращать ответы пользователю.

Выбор платформы для ИИ-агентов: обзор open source-решений и наш путь

Переходя от теории к практике, мы провели исследование рынка open source-решений для создания ИИ-агентов. В фокусе нашего внимания ^[8] оказались три популярных инструмента: n8n, Dify и Langflow. Основные различия между ними заключаются в подходах к интеграции и расширению функциональности. Каждый из них обладает собственной средой исполнения для работы агентов, требующей отдельного изучения, и может не соответствовать нашим конкретным требованиям. Важно отметить, что все платформы написаны на разных языках программирования, и это следует учитывать при планировании самостоятельной дорабатки.

n8n: инструмент для автоматизации процессов

Подход: n8n — это, в первую очередь, мощный конструктор для автоматизации любых бизнес-процессов с помощью нод (узлов).

Преимущества: позволяет создавать конвейеры любой сложности.

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

Dify: платформа, ориентированная на ИИ

Подход: Dify изначально разработан с упором на ИИ, и 80% его функциональности направлено на агентскую автоматизацию.

Преимущества: предлагает широкий набор готовых функций «из коробки»: версионирование промптов, унифицированный интерфейс для работы с различными провайдерами моделей, мониторинг потребления токенов и встроенные инструменты для построения RAG.

Недостатки: на начальных этапах разработки сложных прототипов многие его мощные возможности (например, создание множества чат-ботов или сложных конвейеров) могут оказаться избыточными. В корпоративной среде, где используются внутренние API и модели (например, наш GigaChat), стандартных интеграций может быть недостаточно. Потребуется доработка, что может нивелировать преимущество «всего из коробки».

Критерии выбора и наше решение. Как же сделать правильный выбор? Мы ориентировались на несколько ключевых вопросов:

• Как часто мы делаем прототипы?

• Кто будет менять логику ^[9] агентов: бизнес-специалисты или только инженеры?

• Насколько сложной будет логика и потребуются ли сложные вычисления и конвейеры обработки данных?

• Существует ли готовое решение, которое будет удобно как инженерам, так и бизнесу?

Проанализировав все «за» и «против», мы пришли к выводу, что ни одно из существующих решений не соответствует нашим требованиям в полной мере. Поэтому мы приняли стратегическое решение разработать собственную платформу.

К этому нас подтолкнули следующие причины:

1. Масштабируемость под нагрузку: нам нужна архитектура, где каждый агент может работать изолированно, не влияя на работу других

2. Поддержка протокола межагентских коммуникаций: важно чётко разделять пользовательский трафик и трафик между агентами для их последующего анализа

3. Внедрение Quality Gate: требуется механизм контроля качества, действующий на всех этапах (от прототипирования до релиза) для постоянной оценки эффективности агентов

4. Конструктор под наши задачи: мы стремимся создать гибкий инструмент, который легко адаптируется под уникальные бизнес-требования и предметные области, сочетая простоту для бизнес-пользователей и мощь для инженеров

Несмотря на то, что этот путь сложнее, чем использование готового решения, он позволит нам построить гибкую, производительную и идеально адаптированную под наши нужды платформу для ИИ-агентов.

Сценарий: мультиагент для автоматизации страховых вопросов в ипотеке

Рассмотрим конкретный пример реализации мультиагентной системы, разработанной для обработки страховых запросов, связанных с ипотекой.

Пользовательский сценарий: FAQ

Представим себе пользователя, уже имеющего ипотечный кредит. Он обращается с вопросами, касающимися страхования жизни или недвижимости. Запросы пользователя могут быть разными: от консультации «Какая страховка мне нужна?» и «Нужно ли мне продлевать страховку?» до практических действий, таких как продление полиса.

Для решения этой задачи мы разработали систему с агентом-координатором в центре. Его основная задача — классифицировать входящий запрос и направить его к специализированному агенту:

1. Агент по проблемам: обрабатывает жалобы, нестандартные ситуации и вопросы, например, связанные с начислением неустоек

2. Агент по консультациям: предоставляет ответы на общие вопросы о типах страховок, условиях продления и т.д.

3. Агент по работе с файлами: отвечает на вопросы, связанные с загрузкой документов — это интересный сценарий

Сценарий работы с документами: от загрузки до отправки в банк

После загрузки полиса наш агент выполняет многоэтапную проверку, чтобы убедиться в корректности и полноте заполнения документа. Алгоритм выглядит таким образом:

1. OCR-классификация: система определяет типы загруженных документов (полис, чек, квитанция и т.д.)

2. Извлечение данных: из каждого документа извлекается важная информация (сумма, ФИО, даты)

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

4. Интерактивное взаимодействие: при обнаружении недостающих документов агент запрашивает у пользователя их дозагрузку

5. Финальное действие: после успешной проверки и сбора полного пакета документов агент формирует его и отправляет в банк, завершая услугу

Технологический стек для обработки документов

В основе нашей системы лежит мощный конвейер, включающий следующие компоненты:

• OCR-классификация и VLM-фреймворк (Vision Language Model) для распознавания документов

• Модель Qwen 2.5 Vision 7B для анализа изображений и текста

• Фреймворк vLLM для инференса модели

Производительность решения:

• Объем обработки: обработка до 30 тыс. файлов в день, что эквивалентно примерно 60 RPM

• Время обработки: от трех до 30 секунд в зависимости от загрузки очереди

• Использование ресурсов: высокая загрузка GPU — до 95%

MVP-архитектура агента в двух сценариях

Мы разработали два основных сценария обработки запросов:

1. Текстовый запрос: пользователь → RAG → сценарный движок → соответствующий агент (консультант или специалист по проблемам)

2. Запрос с документом: пользователь → классификатор документов → сценарный движок → агент по работе с файлами

При этом агент по работе с файлами фиксирует все свои промежуточные действия и результаты в долгосрочной памяти. Это позволяет, например, агенту-консультанту информировать пользователя о статусе обработки документов, даже если она занимает длительное время.

Долгосрочная память: не Rock ‘n’ Science, а надёжный сервис

Наша система долгосрочной памяти — это не магия, а надёжный сервис хранения контекста, основанный на следующих принципах:

• Синхронный API для чтения данных

• Асинхронный API для их обновления

• Событийная модель для отслеживания всех действий

• Хранилище на основе PostgreSQL

• Индексирование данных по идентификатору клиента и идентификатору события, что обеспечивает полную отслеживаемость процессов

Один день из жизни страхового агента

Каждый день работы над агентом — это постоянная борьба с недетерминированностью моделей. Мы в шутку говорим, что он копит на Мальдивы: за каждую ошибку ^[10] или отклонение от строгих бизнес-правил его «штрафуют». Эта метафора хорошо иллюстрирует суть нашей задачи: создать не просто умного, а предельно дисциплинированного и надёжного помощника, который без ошибок выполняет критически важные для клиентов финансовые операции.

Критерии выбора языковой модели для корпоративных ИИ-агентов

После обсуждения архитектуры логично перейти к фундаментальному вопросу: как выбрать LLM для таких систем? Задача может показаться рутинной, но именно от этого выбора зависит вся эффективность нашего решения.

Мы определили для себя следующие ключевые критерии:

1. Поддержка языков и мультимодальность. Для российского рынка качественная поддержка русского языка — не опция, а необходимость. Машинный перевод запросов часто искажает смысл и неприемлем для бизнес-коммуникации. Мультимодальность также критична для задач классификации и анализа документов.

2. Технические метрики инференса. Скорость и стабильность генерации ответов напрямую влияют на пользовательский опыт.

3. Поддержка внешних инструментов. Это обязательное условие для любого агента, которому требуется взаимодействие с внешними API и базами данных.

4. Архитектурная гибкость. Модель должна позволять развёртывание в нужной инфраструктуре (локальный сервер или облако) и поддерживать дообучение (fine-tuning) для специфических задач.

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

6. Управляемость. Модель должна точно следовать инструкциям и заданным сценариям.

Выбор модели — это только половина дела. Не менее важно оценить, насколько эффективно готовый агент решает поставленные задачи. Для этого необходимы специализированные бенчмарки и метрики:

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

• Потребление токенов: прямой показатель стоимости эксплуатации

• Длительность ответа: критично для синхронного взаимодействия в чате

• Частота и точность использования инструментов: насколько корректно агент вызывает внешние сервисы

• Безопасность: контроль за тем, чтобы инструменты не использовались для несанкционированных операций

Нюансы работы

Мы столкнулись с рядом нюансов, о которых важно знать. 

1. Избегайте BigInt в инструментах. Если ваш инструмент использует большие числа, например, ID материалов, то обязательно преобразуйте их в строку. В противном случае при преобразовании в формат IEEE-754 потеряется точность и вы никогда не найдёте свои материалы по ID.

2. Избегайте сложных схем в промптах. Ссылки $ref, определения $def, выбор из нескольких схем anyOf, значения по умолчанию default и объекты без полей def my tool(arg: dict) -> dict — всё это может сбить с толку модель и привести к недетерминированному поведению ^[11]. Схемы должны быть максимально простыми, плоскими и однозначными. 

Этот практический опыт — не менее ценная часть разработки, чем выбор архитектуры. Он помогает создавать более стабильные и предсказуемые системы.

Безопасность ИИ-агентов

Хочу затронуть важный аспект: защиту ИИ-систем. Давайте разберёмся, от чего именно нужно их защищать и рассмотрим наши подходы.

Ключевые угрозы. Перед нами стоят следующие ключевые вызовы:

1. Промпт-инъекции: злоумышленники могут попытаться перехватить управление агентом, внедряя специально собранные инструкции, которые заставят модель игнорировать системные промпты и выполнять несанкционированные действия

2. Отклонение от тематики: модель должна строго придерживаться своей предметной области (недвижимость и ипотека) и не отвечать на запросы, выходящие за рамки её компетенции

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

4. Утечка персональных данных: следует предотвращать случайную выдачу конфиденциальной информации, а при необходимости — маскировать её.

Наш подход к защите. Мы разработали собственное решение для защиты данных, поскольку существующие фреймворки безопасности не соответствовали нашим требованиям, в первую очередь из-за недостаточной поддержки русского языка. Наше решение включает в себя следующие компоненты:

• Кастомный обфускатор для маскирования конфиденциальных данных

• Промпты для LLM-as-a-judge — использование самой модели для классификации и проверки запросов и ответов на безопасность

• Набор регулярок для базовой фильтрации контента

Подводные камни и компромиссы. Внедрение системы безопасности неизбежно влечёт за собой издержки:

• Увеличение времени ответа в среднем на 500 миллисекунд

• Потребление токенов увеличивается как минимум в 2 раза, поскольку к каждому запросу добавляются служебные промпты

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

Будущее: переход на Qwen3Guard. Мы постоянно ищем пути оптимизации. Недавно протестировали новую модель Qwen3Guard и планируем перейти на неё. Её ключевые преимущества:

• Скорость: время отклика около 100 миллисекунд

• Эффективность: экономичное потребление памяти и вычислительных ресурсов

Где внедрять защиту

Мы рекомендуем встраивать систему безопасности на нескольких уровнях:

1. Между LLM API Gateway и моделями: все промпты, отправляемые в модель, и все ответы от неё должны проходить фильтрацию

   

2. На этапе индексации документов: перед загрузкой документов в векторную базу знаний (RAG) необходимо проверять их на наличие конфиденциальной или нежелательной информации, так как это предотвратит её последующую выдачу клиентам

   

Многоуровневая система безопасности — не опция, а необходимое условие для создания надёжных и доверенных ИИ-агентов в корпоративной среде. Без неё невозможно масштабирование и реальное внедрение технологии в бизнес-процессы.

Заключение 

Вернусь к общей картине и представлю итоговую архитектуру нашей платформы. 

Как видите, в её основе лежат три ключевых слоя:

1. Слой оркестрации и шлюзов (LLM API Gateway)

2. Слой агентов, где работают различные специализированные ИИ-помощники

3. Слой LLM-моделей, обеспечивающий интеллектуальное ядро системы

И всё это работает на фундаменте, состоящих из компонентов, о которых я выше подробно рассказал: инструменты (Tools), память (Memory), безопасность (Guardrails) и RAG.

Возникает закономерный вопрос: «А сэкономят ли LLM деньги моему бизнесу?»

Сегодня, возможно, нет, если считать только прямые затраты на разработку и инфраструктуру. Однако правильный вопрос звучит иначе: «Позволят ли ИИ-агенты моему бизнесу зарабатывать и экономить больше в будущем?» Наш опыт даёт однозначный ответ: «Да». 

ИИ-агенты — это не просто расходы, а стратегические инвестиции. Они экономят самое ценное — время сотрудников и клиентов, масштабируют экспертизу, автоматизируют рутину и открывают новые каналы взаимодействия. Прямая экономия на операционных расходах проявится позже, но конкурентное преимущество, скорость и качество сервиса, которые дают агенты, начинают работать на бизнес уже сегодня. Внедрение ИИ-агентов — это марафон, а не спринт.