AR 15 M4
3c2657ab99
Второй кусок Спринта 2: агент теперь помнит контекст. RAG-retrieval
делается по последней реплике пациента, в LLM уходит системный промпт +
последние 20 сообщений треда + новая реплика + найденные фрагменты.
Backend:
- services/chat_service: send_message — создаёт тред при необходимости
(auto-имя из первой реплики + UTC-дата), сохраняет user-реплику до
вызова LLM (чтобы не потерять при сбое), делает retrieval, грузит
историю треда (desc/limit 20 → reversed для хронологии), зовёт
llm.chat, сохраняет ответ ассистента вместе с sources_json и
assembled_prompt, обновляет thread.updated_at. Плюс list_threads с
JOIN-выборкой превью первой реплики и счётчика сообщений,
get_thread_detail через selectinload, rename_thread, delete_thread
(CASCADE на FK делает уборку сообщений автоматически, но
explicit delete оставлен для подсчёта удалённых).
- services/llm_client.chat: принимает history=[{role, content}, ...],
собирает messages = [system, ...history, user-с-RAG]; assembled_prompt
дампит всю цепочку в виде [SYSTEM]/[USER]/[ASSISTANT]-блоков для
отображения в Debug UI.
- routers/chat: POST /chat, обрабатывает LookupError → 404.
- routers/threads: GET /threads, GET /threads/{id}, PATCH /threads/{id}
(переименовать), DELETE /threads/{id}.
- models: ChatRequest, ThreadRenameRequest; ChatResponse, ThreadInfo,
ThreadListResponse, ThreadDetailResponse, MessageInfo,
ThreadDeleteResponse.
Запуск:
- В lifespan main.py: автоматический alembic upgrade head через
asyncio.to_thread (сам alembic делает asyncio.run внутри, его нельзя
звать из уже работающего event loop). LLMClient инициализируется
один раз при старте — вместо создания на каждый запрос.
E2E проверено: новый тред → агент отвечает и просит представиться;
вторая реплика в том же треде — агент помнит контекст; PATCH
переименовывает; DELETE удаляет тред с каскадом на сообщения.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Chat Agent for Patients (RAG) — инструмент настройки
RAG-ядро + веб-инструмент для настройки пациентского чат-агента: загрузка wiki, редактирование промпта и правил, прогон сценариев.
Подключение реальных каналов (чат в мобильном приложении, бот в МАКС) делает другой разработчик — этот проект отдаёт ему готовое RAG-ядро и API плюс согласованную конфигурацию (системный промпт, правила, снапшот базы знаний).
Статус
🟡 Active — MVP, проектирование.
Цель проекта
- Поднять RAG по wiki операторов и API диалога с агентом.
- Дать операторам веб-инструмент, в котором они в процессе настройки:
- загружают документы wiki (постепенно, по мере готовности — не пакетно);
- редактируют системный промпт и правила поведения агента;
- играют роль пациента в тестовом чате и смотрят, что отвечает агент;
- сохраняют проработанные диалоги как сценарии и перегоняют их после изменения настроек.
- Сама интеграция с реальными каналами (приложение, МАКС) — вне скоупа этого проекта.
Что не входит в скоуп
- Реальная интеграция с чатом в мобильном приложении (
work-pcs-pt-mobile). - Реальная интеграция с ботом в МАКС (
work-pcs-pt-bots). - Очередь и UI оператора для живого переключения с агента на человека.
- Мультипользовательская прод-эксплуатация.
Всё это — задача смежного разработчика, который будет использовать API этого сервиса.
Архитектура (черновик)
┌──────────────────────────────────┐ ┌──────────────────────┐
│ Web UI настройки (один экран) │ │ │
│ ┌────────────┐ ┌────────────┐ │ │ RAG (wiki) │
│ │ База знаний│ │ Промпт + │──┼─────▶│ ChromaDB + E5 │
│ │ (upload) │ │ правила │ │ └──────────────────────┘
│ └────────────┘ └────────────┘ │ ┌──────────────────────┐
│ ┌────────────┐ ┌────────────┐ │─────▶│ DeepSeek LLM API │
│ │ Песочница │ │ Сценарии │ │ └──────────────────────┘
│ │ (чат) │ │ (сохран.) │ │
│ └────────────┘ └────────────┘ │
└──────────────────────────────────┘
│
▼
Chat Agent API (FastAPI)
(тот же API, что потом получит
внешний разработчик для каналов)
Ключевая идея: веб-инструмент — это единственный клиент агента на время настройки. Когда конфигурация «устаканивается», её снапшот отдаётся внешнему разработчику вместе с документированным API.
Технологический стек (предварительно)
| Слой | Технология | Назначение |
|---|---|---|
| API | FastAPI (Python 3.11–3.12) | HTTP-эндпоинты агента и настройки |
| Vector DB | ChromaDB | База эмбеддингов wiki |
| Embeddings | intfloat/multilingual-e5-large |
Русскоязычные эмбеддинги |
| LLM | DeepSeek API | Диалоговая модель |
| Хранилище конфигов и сценариев | SQLite | Промпты, правила, сценарии |
| Веб-UI | Vanilla JS / лёгкий фреймворк | Одностраничное приложение настройки |
| Контейнеризация | Docker | Изолированный запуск |
База опыта —
work-pcs-dr-cdss(RAG-сервис для врачей). Переиспользуем паттерн сервисовembeddings.py / vectorstore.py / document_processor.py / llm_client.py.
План (спринты)
См. SPRINTS.md.
Запуск
TBD — будет заполнено в Спринте 1.
Связанные проекты
work-pcs-dr-cdss— RAG для врачей, источник технических паттернов.work-pcs-pt-mobile— мобильное приложение пациента (канал подключит другой разработчик).work-pcs-pt-bots— пациентские боты МАКС (канал подключит другой разработчик).