Роль и обязанности¶
Роль¶
System Designer, AI-assisted Prototype Engineer.
Это работа по архитектуре прототипа: перевод enterprise AI-идеи в ограниченный лабораторный стенд, а не ownership production-архитектуры.
Зона ответственности¶
- перевод продуктовой идеи в архитектурную модель прототипа;
- формулировка концепта контролируемого цикла работы с LLM;
- выбор временного стека для лаборатории PoC;
- проектирование синтетического датасета;
- проектирование прототипного playbook / diagnostic-path подхода;
- проектирование модели контролируемого доступа к инструментам (см. Безопасность и модель доступа);
- реализация и развитие начального концепта Tool Registry (см. Архитектура);
- подготовка синтетических enterprise demo-данных (см. Доменная модель);
- развитие подхода evidence и прозрачности (см. Интеграционные принципы);
- настройка Open WebUI как временного chat-like интерфейса (см. Компромиссы);
- фиксация ограничений, включая отсутствие рабочего multi-turn цикла сессии;
- описание будущего направления к отчётам, карточкам сигналов, evidence view и backend-native orchestration. Эти пункты не были реализованы.
Выполненные работы¶
- спроектировал архитектуру прототипа: chat-like harness, экспериментальный execution flow, концепт маршрутизации диагностических путей, слой инструментов, слой синтетических данных, направление document evidence и execution trace;
- построил лабораторный FastAPI + LangGraph runtime для экспериментальных single-request диагностических flow;
- зафиксировал принцип: LLM не обращается напрямую к PostgreSQL, Qdrant или MinIO;
- реализовал / заложил контролируемый запуск инструментов через FastAPI tool-server;
- подготовил синтетический датасет для fashion/retail/manufacturing-компании;
- расширил датасет в сторону кросс-доменной диагностики: finance, delivery, ITSM, PMO, meetings, documents;
- зафиксировал целевое направление, не выдавая его за уже доставленный scope.
Применение ИИ¶
Проект разрабатывался с использованием AI-assisted prototyping.
LLM использовались для ускорения:
- генерации черновиков кода;
- подготовки synthetic data;
- подготовки промптов и логики процессов;
- анализа вариантов архитектуры;
- подготовки документации;
- генерации черновиков тестовых сценариев.
Ключевые решения оставались под ручным контролем:
- архитектурные границы;
- модель доступа к данным;
- выбор лабораторного и целевого runtime;
- требования к проверяемости;
- структура синтетического датасета;
- смысл диагностических путей;
- ограничения PoC;
- ревью результата;
- позиционирование проекта.