Review Flow — демонстрационный MVP для обработки клиентских обращений, в котором AI используется управляемо: бизнес-решения фиксируются в базе типовых ситуаций, а не передаются модели «на усмотрение». Подробное соответствие исходному ТЗ зафиксировано в отчёте о соответствии ТЗ.
Проект показывает полный цикл: от обращения клиента до публикации ответа и последующего обучения базы знаний через реальные кейсы операторов.
Три типичных крайности не дают устойчивой операционной модели:
| Подход | Ограничение |
|---|---|
| Ручная обработка | плохо масштабируется; растут издержки; качество зависит от отдельных сотрудников |
| Полностью автоматический LLM | решения плохо контролируются и воспроизводятся; сложно аудировать |
| «Модель решает за бизнес» | организация не может формально делегировать принятие решений black-box модели |
Review Flow ищет баланс: автоматизация там, где она прозрачна, и человек там, где нужна ответственность.
Controlled Hybrid — архитектура, в которой:
- типовая ситуация (Response Case) — Source of Truth бизнес-решения (политика ответа, утверждённая основа текста);
- retrieval подбирает наиболее подходящую типовую ситуацию по примерам обращений;
- confidence рассчитывается системой на основе результата retrieval;
- LLM не выбирает типовую ситуацию и не принимает бизнес-решение — только адаптирует текст ответа в рамках
response_policy/approved_response_text; - оператор остаётся Human-in-the-Loop: подтверждает, меняет или эскалирует;
- администратор развивает базу знаний: типовые ситуации, retrieval-примеры, кандидаты.
Чем отличается от типичного LLM-first: решение не «рождается в промпте», а находит опору в управляемой KB и правилах backend.
Подробное обоснование: Обоснование выбора Controlled Hybrid · Controlled Hybrid · Архитектура
Главный сценарий проекта — замыкание цикла обучения: операционный сигнал превращается в новое знание, которое улучшает последующий retrieval.
flowchart LR
A["Обращение клиента"] --> B["Retrieval:<br/>низкая уверенность<br/>или неверная ТС"]
B --> C["Оператор:<br/>«ни одна ТС не подходит»"]
C --> D["Candidate<br/>(кандидат)"]
D --> E["Администратор:<br/>новая ТС или<br/>присоединение к ТС"]
E --> F["Candidate →<br/>retrieval-пример"]
F --> G["Похожее обращение:<br/>высокая уверенность,<br/>автоматический подбор"]
Шаги в системе:
- Клиент создаёт обращение.
- Retrieval предлагает неподходящую или недостаточно уверенную типовую ситуацию.
- Оператор фиксирует: «ни одна типовая ситуация не подходит», создаёт candidate.
- Администратор обрабатывает кандидата: создаёт новую типовую ситуацию или присоединяет к существующей.
- Обращение-кандидат становится retrieval-примером.
- Следующее похожее обращение распознаётся с высокой уверенностью — без смены бизнес-логики «вручную» на каждый раз.
Скриншоты этого сценария — в разделе Демонстрация системы (оператор → администратор).
Ниже — сквозная история по ролям. Все изображения из docs/screenshots/.
Публичный контур: клиент не видит внутренних инструментов, confidence и типовых ситуаций.
Главная — вход в сценарий «оставить обращение» / «проверить статус».
Создание обращения — форма и отправка; система выдаёт номер обращения (NL-…).
Отслеживание статуса — этапы обработки и опубликованный ответ после действий оператора.
Рабочее место: очередь обращений, предложенная типовая ситуация, confidence, правка и публикация ответа.
Карточка обращения — human-in-the-loop: редактирование ответа перед публикацией.
Confidence и альтернативы — retrieval предлагает ТС; при низкой уверенности оператор видит Top-N и принимает решение осознанно.
Запуск learning loop — «нет подходящей ТС» → candidate.
Результат после расширения KB — похожее обращение обрабатывается с высокой уверенностью.
Вход в контур компании (выбор роли): oper-logun.png
Управление базой знаний Controlled Hybrid.
Типовые ситуации (Response Cases) — SOT бизнес-решений: политика, утверждённый текст, пороги.
Кандидаты — очередь предложений от операторов.
Создание новой типовой ситуации — кандидат превращается в элемент KB.
Retrieval-пример — candidate добавлен к типовой ситуации; последующий подбор улучшается.
Отчётность по обращениям и качеству обработки (демо-витрина MVP).
Системные параметры и AI-провайдеры (в демо возможен mock-провайдер).
Полная галерея с пояснениями: Галерея экранов
flowchart TB
subgraph client["Клиентский контур"]
C[Клиент]
end
subgraph api["Backend"]
API[FastAPI API]
CH[Controlled Hybrid pipeline]
RET[Retrieval по примерам]
CONF[Confidence]
RC[(Response Cases)]
LLM[LLM: адаптация текста<br/>в рамках policy]
end
subgraph company["Контур компании"]
OP[Оператор:<br/>подтверждение / override / publish]
ADM[Администратор:<br/>ТС, примеры, кандидаты]
end
C -->|POST обращение| API
API --> CH
CH --> RET
RET --> RC
CH --> CONF
CH --> LLM
CH --> OP
ADM --> RC
OP -->|final_response| C
Семантика потока (реализовано при CH_PIPELINE_ENABLED=true):
- Клиент создаёт обращение → API сохраняет в PostgreSQL.
- Retrieval ранжирует типовые ситуации по примерам; система вычисляет confidence.
- Draft формируется из policy и утверждённого текста выбранной ТС; LLM адаптирует формулировку, не выбирая ситуацию.
- Оператор подтверждает или меняет ТС, редактирует ответ, публикует.
- Администратор поддерживает KB и обрабатывает candidates.
Legacy path (template-guided, для регрессии): CH_PIPELINE_ENABLED=false — см. SOT §3.3.
- Клиентский портал: обращение, номер, статус, опубликованный ответ
- Controlled Hybrid pipeline: retrieval, confidence, decision, bounded LLM adaptation
- Операторская консоль: очередь, override, candidate, публикация
- Админ KB: CRUD типовых ситуаций и retrieval-примеров
- Candidate learning loop (демонстрационный end-to-end сценарий)
- Отчётность и operational logs
- Настройки AI-провайдеров и системные параметры
- Промпты, evaluation, legacy KB (параллельно CH, учебный контур)
| Слой | Технология |
|---|---|
| Frontend | React, Vite, React Router |
| Backend | FastAPI, Python 3.12, SQLAlchemy |
| Database | PostgreSQL 16 |
| AI | OpenAI-compatible API (в демо — mock) |
| Deploy | Docker Compose |
cp .env.example .env
docker compose up --buildПосле запуска:
| Сервис | URL |
|---|---|
| Frontend | http://localhost:5180 |
| Backend API | http://localhost:8700 |
| Health | http://localhost:8700/health |
Подробные инструкции: Запуск и деплой
- Отчёт о соответствии исходному ТЗ
- Архитектура
- Controlled Hybrid
- Руководство пользователя
- Галерея экранов
- История проекта
- Архитектурные и продуктовые решения (SOT)
- Implementation plan
- Демонстрационный MVP: упрощённые сценарии; возможен
mock-провайдер LLM (заглушка текста, не полноценная адаптация) — см. CH pipeline forensics. - Роли переключаются в одном приложении (план разделения UI-контуров).
- База типовых ситуаций — учебный seed для демонстрации retrieval и learning loop.