Одной строкой
Собрал корпоративную базу знаний из справки, FAQ, статей, внутренних материалов и базы поддержки — и поверх неё прикладного ИИ-помощника для техподдержки и техпресейла, с заделом под другие службы.
Я начинал не со стратегий и не с презентаций. Сначала был код — системный уровень, C++, память, потоки, упрямые компиляторы. Потом базы данных: схема, целостность, реляционные контуры и объектные хранилища. Оттуда уже рукой подать до того, что позже привыкли называть платформами данных и корпоративными хранилищами — только тогда это ещё не было красивым словом, а было инженерной работой.
Дальше путь ушёл вширь, не отменяя глубину. Руководство разработкой в международной CNET. Программный PMO и внедрения вокруг SAP — уже не «написать модуль», а довести сложную программу до заказчика в банке или телекоме. Долгие годы в экосистеме IBM: Data & AI, enterprise delivery, распределённые команды, крупные внедрения там, где технология обязана выдержать организацию, а не наоборот. Это школа западных технологических компаний: дисциплина поставки, масштаб, ответственность за результат, а не только за идею.
В российских вендорах довелось и консалтинг собирать почти с нуля, и вести продуктовую и инженерную повестку вокруг данных и платформ — другой тип ответственности: не только поставка, но и устройство самой практики, процессов и команд внутри организации.
Сейчас в центре — искусственный интеллект. Не как мода и не как отдельный «отдел чудес», а как слой, который нужно честно встроить в производственные и хозяйственные процессы: найти применимый сценарий, проверить на живых данных, согласовать с ИТ и ИБ, запустить пилот и дать ему прижиться. Я готов вкладывать силы и внимание в то, чтобы эти технологии работали у нас — для наших решений и наших организаций.
Метод
Кейсы
Ниже — рабочие контуры: от корпоративной базы знаний до экспериментов с ИИ. Из любого места можно вернуться к блоку о себе.
knowledge base + assistant (support / pre-sales)
Собрал корпоративную базу знаний из справки, FAQ, статей, внутренних материалов и базы поддержки — и поверх неё прикладного ИИ-помощника для техподдержки и техпресейла, с заделом под другие службы.
Стартовали с гипотезы: взять OpenWebUI как готовый конструктор RAG. Не подошёл — мало гибкости и жёсткие встроенные ограничения под разные роли и чувствительность данных. На базе Qdrant написали свой слой интеграции источников в корпоративную базу знаний и поверх него — простейший чат. Чат быстро упёрся в потолок: расширяли и модернизировали (multi-collection и trust источников, YouTrack, OCR/вложения, профили общения под техподдержку / техпресейл / внешнего пользователя). В итоге пришли к Workspace-рантайму: запрос сначала классифицируется и маршрутизируется, затем подключаются нужные способности — поиск по базе знаний, разбор вложений, сценарии YouTrack и т.д. — а ход выполнения виден как события, артефакты и вызовы инструментов; это управляемый orchestrator, а не «один длинный промпт». Следующий запланированный шаг — multi-step агенты. Команда: я, инженер L2 техподдержки как эксперт предметной области и разработчик системы сопровождения; код писал ИИ-агент под моим управлением.
Единая корпоративная база знаний + ИИ-помощник с ролевыми профилями, а не «один чат на все случаи». Целились помочь L1, а в итоге чат сразу вёл разговор на уровне L2 — в том числе уверенный разбор длинных и тяжёлых вложений (логи, дампы) с инсайтами для инженеров. Потенциал расширения на другие службы. Жёстких публичных KPI нет — акцент на управляемом пайплайне знаний и пригодности под разные контуры.
Python/FastAPI, Celery, React, PostgreSQL, Redis, Qdrant, Docker; LLM: llama.cpp, Ollama, vLLM. Интеграции: YouTrack, RoboHelp.
Схемы + showroom UI (Acme stubs, :3100). Без live YouTrack/корп. коллекций.
flowchart TB
subgraph phase1 [Phase1_Hypothesis]
OpenWebUI[OpenWebUI_RAG]
end
subgraph phase2 [Phase2_Own_KB_Layer]
Sources[Sources_FAQ_Help_Support]
Ingest[Ingest_Index_Collections]
Qdrant[(Qdrant)]
SimpleChat[Simple_Chat]
Sources --> Ingest --> Qdrant --> SimpleChat
end
subgraph phase3 [Phase3_Expand]
Multi[MultiCollection_Trust]
YT[YouTrack]
Attach[OCR_Attachments]
Profiles[Role_Profiles]
end
subgraph phase4 [Phase4_Workspace]
Router[Request_Router]
Caps[Capabilities]
Events[Events_Artifacts_ToolCalls]
Router --> Caps --> Events
end
OpenWebUI -.->|rejected| Ingest
SimpleChat --> Multi
Multi --> Router
YT --> Caps
Attach --> Caps
Profiles --> Router
Next[Next_MultiStep_Agents]
Events -.-> Next
flowchart LR User[User] --> UI[Workspace_UI] UI --> API[Workspace_API] API --> Runtime[Workspace_Runtime] Runtime --> Router[Request_Router] Router --> Direct[DirectAnswer] Router --> Retrieval[Retrieval] Router --> Attach[Attachments] Router --> Domain[Domain_Caps] Retrieval --> Evidence[Evidence_Pack] Attach --> Evidence Domain --> Evidence Direct --> Composer[Answer_Composer] Evidence --> Composer Composer --> Events[Run_Events] Composer --> Artifacts[Run_Artifacts]
market data · hypotheses · analytics · ML + GPU
Исследовательский ML/DS-контур по рыночным данным: интеграции с брокерскими и биржевыми API → кэш истории и дня → гипотезы о поведении котировок → аналитика и графики; backend/frontend, prod/dev, удалённый ML-сервис с GPU.
Начали с разработки и проверки интеграций с API Finam и Tinkoff. Спроектировали архитектуру взаимодействия с площадками, включая MOEX API. Собрали сбор и кэширование исторических рядов и данных текущего дня. Проработали ряд гипотез с инсайтами по поведению котировок на наборе инструментов. Зафиксировали контуры: backend, frontend, production и development, удалённый ML-сервис с GPU-ускорением. Существенно проработали аналитику — зависимости, визуализации, графики — как способ проверки гипотез.
Рабочий research/engineering контур: от API и данных до гипотез и ML-пайплайна с разделёнными контурами и GPU. Публично — технологические возможности и исследовательский цикл; торговые правила, пороги и «рецепт» — вне витрины.
Backend (Go/gRPC/API), frontend, PostgreSQL; Finam / Tinkoff / MOEX; remote ML + GPU; prod и dev.
Схема + UI local demo. Новые кадры — черновик: клик увеличивает; финальный redact скажете отдельно.
flowchart TB
subgraph apis [Market_APIs]
Finam[Finam_API]
Tinkoff[Tinkoff_API]
MOEX[MOEX_API]
end
subgraph data [Data_Layer]
Ingest[Ingest_Integrations]
Cache[Cache_History_and_Intraday]
end
subgraph research [Research_Layer]
Hyp[Hypotheses]
Analytics[Analytics_Charts_Dependencies]
end
subgraph app [App_Contours]
BE[Backend]
FE[Frontend]
Dev[Development]
Prod[Production]
end
subgraph ml [ML_Contour]
MLS[Remote_ML_Service]
GPU[GPU_Acceleration]
MLS --- GPU
end
Finam --> Ingest
Tinkoff --> Ingest
MOEX --> Ingest
Ingest --> Cache
Cache --> Hyp
Cache --> Analytics
Hyp --> MLS
Analytics --> FE
BE --> Ingest
BE --> Cache
BE --> MLS
FE --> BE
Dev --- Prod
BE --- Dev
BE --- Prod
Идея + технология · group/channel KB → RAG
Локальный пайплайн: длинная история группы/канала в Telegram (доступ через свой аккаунт) → темы и факты в KB → RAG с опорой на источники.
Задача: разобрать канал или группу с длинной историей — много объектов, ответы размазаны по годам, глазами неподъёмно. Через свой аккаунт в Telegram вытащить историю, выделить темы и фокусы, собрать факты в KB и отдать в RAG. Спроектировал ingest → flows/KB → Qdrant → ask. Довёл MVP (Telethon/экспорт, Postgres, retrieve/ask, CLI), апробировал на живых диалогах. Адаптировал: гибридная склейка тредов, KB-pipeline (summary/facts/qa со ссылками на сообщения), миграция на Postgres и фоновые воркеры, SwiftUI-оркестратор вместо чистого CLI.
End-to-end контур: из истории группы — темы, фокусы и факты в KB + поиск с источниками, управляемый UI и непрерывный sync. Метрик не фиксировал — ценность в идее и доведённой технологии.
Python (Typer, FastAPI, Telethon), PostgreSQL, Qdrant, vLLM, embedding-сервис, Docker Compose, SwiftUI.
Схема + SwiftUI-оркестратор (публичный канал FINAM API) + showroom ask. Без session files / PII.
flowchart LR TG[Telegram_History] Ingest[Ingest_Export] PG[(PostgreSQL)] KB[KB_Topics_Facts_QA] Qdrant[(Qdrant)] Emb[Embedding_Service] Ask[Ask_RAG] LLM[vLLM] UI[SwiftUI_Orchestrator] TG --> Ingest --> PG --> KB KB --> Qdrant Emb --> Qdrant Qdrant --> Ask LLM --> Ask UI --> Ingest UI --> Ask
Облачная LLM без утечки чувствительных данных
Корпоративный пользователь шлёт в облачную LLM запрос с чувствительными данными — локальный контур маскирует их, облако отвечает, ответ демаскируется.
Задача: пользоваться ChatGPT / DeepSeek / любой облачной LLM, не отдавая наружу коммерческие, юридические и прочие чувствительные данные — например, текст письма контрагента, из которого нужен драфт ответа. On-prem LLM слабее и дешевле: её хватает, чтобы найти и спрятать чувствительные фрагменты (замена на коды/термины). Замаскированный запрос уходит в облако; ответ локально демаскируется. Довёл до MVP трёхшагового цикла mask → cloud LLM → demask: каталог сущностей, API, пошаговый UI, настройка промпта.
Рабочий end-to-end пайплайн: чувствительные данные не уходят в облако в открытом виде, качество генерации — у внешнего LLM.
FastAPI, React/TS/Vite/Tailwind, Ollama (детект), OpenRouter (генерация), Docker.
Схема ниже. Live UI: шоурум-тексты → маскирование, настройки, справочник (исходные значения redact).
flowchart LR User[User_Sensitive_Text] Local[Local_Contour] Detect[Detect_Mask] Catalog[Entity_Catalog] Cloud[Cloud_LLM] Demask[Demask] Out[Safe_Reply] User --> Local --> Detect Catalog --> Detect Detect -->|masked_prompt| Cloud Cloud -->|masked_reply| Demask Demask --> Out
Короткие блоки
Помощник по структурированию и выравниванию позиционирования CV: разные ракурсы себя как соискателя, разные площадки и профили — на какие аспекты делать фокус в каждом. Проработаны интеграции с LinkedIn и HH — и вскрылись ограничения площадок. У HH удобный для таких задач соискательский API к концу 2025 года прекратили: полноценный sync резюме/откликов сейчас сильно урезан; у LinkedIn без Talent API — по сути только базовый профиль. Тем не менее собрано рабочее решение: несколько локальных позиционирований и типов CV, импорт опубликованных резюме файлами (PDF/HTML), сверка локального ↔ площадок, разбор писем «резюме привлекло внимание», пакеты откликов под вакансии и поиск вакансий через публичный HH API.
Python/FastAPI, React, Electron, SQLite, Docker
Собрали MVP-конструктор презентаций как базовую платформу под наращивание: в тот момент облачные LLM ещё не отдавали готовые презентации массово — предлагали структуру слайдов, которую приходилось копипастом собирать в PowerPoint, а специализированные сервисы с экспортом файла были узкоограниченными. За неделю довели контур форма → LLM → превью → экспорт PPTX. Дальнейшее развитие отложено до финансирования; в бэклоге оставались корпоративный стиль, подключение к базе знаний (тезисы → контент слайдов из KB) и расширение пайплайна.
React + Express/TS, OpenRouter/OpenAI, pptxgenjs
Контакты
Прямые каналы и профили на площадках — отдельно: найм и проектные заказы не смешиваю в одну кучу.
Профили для проектной работы и заказов