Системный аналитик с 7+ годами опыта в корпоративных IT-системах и практическим опытом применения AI/LLM в коммерческой аналитике. Основной профиль: AI-enabled процессы, интеграции, API, данные и автоматизация аналитической работы. Использую AI не только как пользователь: самостоятельно создаю технические PoC на Python/FastAPI, PostgreSQL, RabbitMQ и Docker, работаю с локальными моделями через Ollama. Разработал локальный AI-сервис для обработки внутренних материалов без передачи содержимого внешним LLM-провайдерам. Применял AI на разных этапах системного анализа: Whisper → DeepSeek для транскрибации и структурирования рабочих материалов, AI-assisted research при выборе отраслевого решения, Claude Code для reverse engineering XML/BSL и анализа существующей реализации. Проводил исследование локальных LLM для корпоративного использования: сравнивал варианты локального запуска и инфраструктуры, ограничения по конфиденциальности и варианты масштабирования от локального MVP к централизованному AI-контуру. Сильная сторона: работа на стыке бизнеса, IT и новых технологий, разбираю противоречивые требования, договариваюсь со стейкхолдерами, быстро проверяю технические гипотезы и довожу решения от идеи до реализации, тестирования и приёмки. Pet project: распределённая Smart Home / IoT-система с несколькими transport/gateway/cloud-контурами; анализ зависимостей и точек отказа, локализация проблем между device, radio, gateway, LAN и cloud-слоями.
Системный аналитик в Компания ВИАНТ автоматизация торгово-производственных предприятий на базе 1С ERP складских решений и Auto-ID
· 22.10резюме
2 коммента
· 22.10
Для цепочки «транскрибация → структурирование» полезно сохранять связь каждого требования с фрагментом исходной записи: так спорную формулировку можно проверить, а не обсуждать уверенный пересказ модели. Как вы в PoC различаете явно согласованное требование, предположение модели и открытый вопрос к заказчику?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 22.10
Хорошее замечание про связь требования с первоисточником. В таком процессе я бы сохранял для каждого извлечённого пункта ссылку на исходный фрагмент транскрипта с таймкодом, если он доступен. Это позволяет вернуться к контексту и проверить формулировку, а не принимать результат модели на веру.
Логически я разделяю три статуса: — Подтверждено источником — заказчик явно сформулировал потребность или ограничение. — Гипотеза модели — вывод или интерпретация, которую ещё нужно проверить. — Открытый вопрос — информации недостаточно или в обсуждении есть неоднозначность.
При этом наличие фрагмента в транскрипте само по себе ещё не означает, что требование согласовано: это подтверждает происхождение формулировки, но не факт её утверждения заказчиком.
В моём PoC я проверял саму цепочку обработки транскрипта и структурирования результата. Связь каждого требования с таймкодом и статусы согласования я бы рассматривал как отдельный слой валидации, который нужно реализовать и проверить.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён