Создание высокореалистичного цифрового двойника (AI-Replica) человека

Решение

Для реализации столь сложной задачи мы предложили современную и модульную архитектуру.

Ключевым элементом решения стал сложный RAG-поток (Retrieval-Augmented Generation). Вместо того чтобы просто отправлять запрос пользователя в LLM (как это делают простые чат-боты), наша система выполняет многоступенчатый процесс:

1. Анализирует запрос пользователя.
2. Мгновенно выполняет семантический поиск по векторной базе данных (Qdrant), где хранятся все факты и черты личности пользователя.
3. Находит наиболее релевантные «кусочки» информации (например, «факт о детстве», «мнение о музыке»).
4. «Дополняет» (Augmented) первоначальный запрос пользователя этой информацией.
5. Отправляет этот обогащенный, высококонтекстный промпт в LLM (OpenAI) для генерации (Generation) ответа.

Этот подход гарантирует, что ИИ «помнит», кто он, и отвечает в соответствии со своей «личностью».

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

Проект был спланирован как интенсивная разработка MVP (Minimum Viable Product) с очень сжатыми сроками.

• Календарный срок: 1 месяц (разбит на 4 спринта по 1 неделе).
• Оценка трудозатрат (MVP): от 352 до 473 общих часов.

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

1. Аналитика, Дизайн и Прототипирование (Параллельно):

• Аналитика: Бизнес-аналитик прорабатывал требования к Website и Backend, описывая логику Wizard, API и RAG-потоков.
• Дизайн: Дизайнер в Figma создавал интерфейс чата, экраны многошагового опросника и «сценарий первого контакта» пользователя с системой.
• Прототипирование: На этом проекте мы применили нестандартный подход. Поскольку оценка результата («похоже на человека или нет») носит крайне субъективный характер, мы сначала создали быстрый прототип на low-code платформе n8n. Это позволило нам быстро и с минимальными затратами протестировать саму концепцию ИИ-агентов, поэкспериментировать с логикой и сконцентрироваться на достижении наилучшего качества ответов ИИ, прежде чем писать сложный production-код.

2. Разработка (Основной этап):

• Frontend (ReactJS): Разработка UI чата и опросника.
• Backend API (Ktor): Разработка API для аутентификации, управления профилями (Wizard) и обработки сообщений чата.
• Backend AI (Ktor/Koog/Qdrant): Самая сложная часть. Интеграция с OpenAI, реализация RAG-потоков, настройка PII-фильтра (для защиты личных данных) и конфигурация всего стека баз данных (Postgres, Redis, Qdrant).

3. QA и PM (Сквозные процессы): Тестирование и управление проектом велись на протяжении всех спринтов.

Состав команды: Над проектом работала компактная и высокоэффективная кросс-функциональная команда:

• 1 Project Manager
• 1 Analyst
• 1 Designer
• 2 Backend-разработчика
• 1 Frontend-разработчик
• 1 QA-специалист

Что было самым сложным

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

1. Сложность Персонализации (RAG-Flow): Это был главный вызов. Нужно было не просто «подключить» ChatGPT. Требовалось обеспечить, чтобы ИИ-двойник давал последовательные и персонализированные ответы, основываясь на десятках и сотнях фактов из профиля. Как сделать так, чтобы ИИ «вспомнил» нужный факт в нужный момент? Самой сложной задачей стала тонкая настройка системного промпта и логики подтягивания дополнительного контекста (фактов) из векторной базы данных Qdrant.

2. Конфиденциальность Данных (PII): Профиль пользователя по своей сути должен был содержать огромное количество персонально идентифицируемой информации (PII) — имена, даты, личные истории, мнения. При этом архитектура подразумевала использование внешнего API (OpenAI). Возник критический конфликт: как использовать эти данные для персонализации, не передавая их во внешний API в явном виде? Обеспечение конфиденциальности PII стало абсолютным приоритетом.

3. Производительность (NFR): Эффект «живого» общения пропадает, если чат-бот «думает» над ответом 10-15 секунд. У нас было строгое нефункциональное требование (NFR): среднее время ответа чата не должно превышать 5 секунд. Это очень агрессивная цель, учитывая сложность нашего RAG-потока: за эти 5 секунд система должна была получить сообщение, обратиться к Redis за историей, обратиться к Qdrant за фактами, сформировать сложный промпт, отправить его в OpenAI, получить ответ и вернуть пользователю.

Как мы решили эту задачу

Для каждого из трех вызовов наша команда разработала и реализовала конкретное техническое решение.

1. Решение для RAG (Персонализация): Для достижения высокого качества ответов мы реализовали динамическую логику на бэкенде (Ktor + Koog).

• История: Сначала мы думали просто передавать в OpenAI весь профиль пользователя, но быстро поняли, что это неэффективно (ограничение токенов) и нерелевантно (ИИ «тонул» в лишней информации).
• Решение: Мы реализовали динамический поиск «Top-K». Когда пользователь отправлял сообщение, бэкенд сперва делал семантический запрос в Qdrant и находил 4–6 наиболее релевантных фактов (чанков) из профиля.
• Далее эти 4-6 фактов форматировались в специальный блок контекста и динамически «вклеивались» в итоговый промпт для OpenAI.
• Параллельно мы вели методичный промпт-инжиниринг, оттачивая главный системный промпт, чтобы научить ИИ правильно интерпретировать и использовать этот дополнительный контекст.

2. Решение для PII (Конфиденциальность): Для защиты PII мы внедрили механизм PII-фильтра и токенизации личных данных.

• История: Простое шифрование не подходило, так как OpenAI должен был понимать смысл данных для генерации векторов (embeddings).
• Решение: Мы разработали PII-фильтр на бэкенде. На этапе подготовки данных для векторной базы (перед отправкой в OpenAI Embeddings API), этот фильтр находил и заменял всю личную информацию на специальные токены. Например, «Мою собаку зовут [DOG_NAME_1]» или «Я живу в [USER_CITY_1]».
• Таким образом, внешний API OpenAI никогда не видел реальных имен, адресов или кличек. Он оперировал только безличными токенами, что полностью снимало риски утечки PII. При этом в нашей внутренней PostgreSQL базе хранилось сопоставление токенов и реальных данных.

3. Решение для Производительности (NFR): Чтобы уложиться в 5 секунд, нам нужно было оптимизировать каждый шаг. Главным «пожирателем» времени и токенов является передача всей истории чата.

• История: «Наивный» подход — отправлять в OpenAI всю историю переписки с каждым новым сообщением. Это быстро приводило к превышению лимита токенов и замедляло ответ.
• Решение: Мы использовали Redis для управления сессиями и хранения недавней истории чата (memory). Вместо всей истории мы отправляли только «скользящее окно» последних сообщений. Это позволило поддерживать непрерывность разговора (ИИ помнил, о чем шла речь 2 минуты назад), но при этом кардинально сокращало количество передаваемых токенов и оптимизировало нагрузку на API. Это решение напрямую ускорило время ответа и снизило стоимость каждого запроса.

Технологический стек

• Frontend: ReactJS, Flowbite (Tailwind CSS) UI-kit.
• Backend: Ktor (Kotlin), Koog (AI-фреймворк для соблюдения принципов чистой архитектуры).

Базы данных:

• PostgreSQL: Хранение учетных записей пользователей и структурированных данных профиля.
• Redis: Управление сессиями и кэширование истории чата (memory) для оптимизации производительности.
• Qdrant: Специализированная векторная база данных для хранения эмбеддингов (векторов) профилей и обеспечения сверхбыстрого семантического поиска для RAG.

AI Сервисы: OpenAI API (Chat Completions для генерации диалогов и Embeddings для векторизации данных профиля).

Прочее: Stripe (для интеграции платежей), Digital Ocean (хостинг).

Прототипирование: n8n.