Программисты — удалённая работа в Москве

Разработка веб сервиса. Разработка с нуля. Требуется разработка MVP веб-сервиса (B2B SaaS) для автоматизации работы арбитражных управляющих. Сервис принимает юридические документы (PDF/DOCX), анализирует их с помощью LLM (Google Gemini ) и выдает правовые заключения. Ключевые особенности: RAG-архитектура, жесткий контроль расходов (Cost Control) и гибкая настройка ролей ИИ для разных разделов. 1. Стек технологий * Backend: Python (FastAPI / Django) или Node.js. * Frontend: React / Next.js / Vue (SPA). * Database: PostgreSQL (пользователи, биллинг) + Vector DB (Pinecone / ChromaDB / PGvector) для поиска по контексту. * AI: Google Gemini API (Vertex AI). * OCR: Tesseract или аналоги (для обработки сканов). 2. Функциональные требования (MVP) А. Ролевая модель и Доступы: * Регистрация/Авторизация (Email + подтверждение). * Система Тиров (Уровней доступа): * Demo: Лимит X запросов/день, малый объем документов. * Pro: Расширенные лимиты. * Admin: Полный доступ. Б. Биллинг (Внутренняя экономика): * Внутренняя валюта (Токены сервиса). * Интеграция платежного шлюза (ЮKassa / CloudPayments). * Логика списания: 1 сложный запрос = X токенов. В. Работа с документами (RAG): * Загрузка файлов (Drag-n-drop). Поддержка PDF, DOCX. * Чанкинг (Chunking): Разбиение больших документов на смысловые части перед сохранением в векторную базу (обязательно!). * История диалогов с сохранением контекста. Г. Управление логикой AI (System Prompts Management): * Разделение по категориям: В интерфейсе должны быть изолированные разделы (например: «Анализ сделок», «Подготовка иска», «Справочная»). * Динамические роли: Под каждый раздел на бэкенде должна подтягиваться своя уникальная Системная Инструкция (System Prompt). * Пример: Для раздела «Анализ» инструкция: “Ты строгий аудитор, ищи ошибки...“, температура (креативность) = 0. * Пример: Для раздела «Иск» инструкция: “Ты адвокат, пиши убедительно...“, температура = 0.7. * Важно: Эти инструкции не должны быть зашиты в код. Они должны храниться в базе данных, чтобы Админ мог их менять. 3. Безопасность бюджета и Технические ограничения (Cost Control) Этому разделу уделить особое внимание при реализации. Задача: Предотвратить неконтролируемый расход средств на API Google при загрузке больших файлов. * Пре-валидация токенов (Token Pre-check): * Перед отправкой запроса в Gemini бэкенд должен посчитать количество токенов в чанке/документе (используя локальный токенизатор). * Если объем превышает лимит тарифа пользователя — запрос блокируется до отправки в платный API. * Hard Limits (Жесткие ограничения): * Настроить лимиты на размер файлов (Мб) и объем текста. * Настроить лимит на количество страниц для OCR. 4. Админ-панель * Дэшборд со статистикой: Расходы на Google API vs Выручка от пользователей. * Список пользователей с возможностью Бана/Разбана. * Редактор Промптов: Интерфейс, где Админ может редактировать тексты Системных Инструкций для каждого раздела и менять параметр Temperature, не залезая в код. 5. Требования к исполнителю * Опыт работы с LangChain / LlamaIndex (или понимание их принципов). * Понимание того, как оптимизировать промпты, чтобы экономить токены (Context Caching). * Готовность подписать NDA (о неразглашении идеи). В отклике укажите: * Ваш опыт с RAG и векторными базами. * Как планируете реализовать редактор системных промптов? * Примерная оценка сроков и бюджета для MVP.