Одной строкой
Собрал корпоративную базу знаний из справки, FAQ, статей, внутренних материалов и базы поддержки — и поверх неё прикладного ИИ-помощника для техподдержки и техпресейла, с заделом под другие службы.
Кейсы
Избранные проекты
Компактная лаборатория: от гипотезы до рабочего контура.
Корпоративная база знаний и ИИ-помощник
knowledge base + assistant (support / pre-sales)
Цикл
Стартовали с гипотезы: взять 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/корп. коллекций.
Схема: эволюция контура (L1)
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
Схема: Workspace runtime (L1)
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]
Meridian Lab — ML/DS research
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 скажете отдельно.
Архитектура (L1)
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
Telegram → база знаний → RAG
Идея + технология · 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.
Пайплайн (L1)
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
Safe Dialog
Облачная 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).
Пайплайн mask → LLM → demask (L1)
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 балансировка
Помощник по структурированию и выравниванию позиционирования CV: разные ракурсы себя как соискателя, разные площадки и профили — на какие аспекты делать фокус в каждом. Проработаны интеграции с LinkedIn и HH — и вскрылись ограничения площадок. У HH удобный для таких задач соискательский API к концу 2025 года прекратили: полноценный sync резюме/откликов сейчас сильно урезан; у LinkedIn без Talent API — по сути только базовый профиль. Тем не менее собрано рабочее решение: несколько локальных позиционирований и типов CV, импорт опубликованных резюме файлами (PDF/HTML), сверка локального ↔ площадок, разбор писем «резюме привлекло внимание», пакеты откликов под вакансии и поиск вакансий через публичный HH API.
Python/FastAPI, React, Electron, SQLite, Docker
Slides Wanted
Собрали MVP-конструктор презентаций как базовую платформу под наращивание: в тот момент облачные LLM ещё не отдавали готовые презентации массово — предлагали структуру слайдов, которую приходилось копипастом собирать в PowerPoint, а специализированные сервисы с экспортом файла были узкоограниченными. За неделю довели контур форма → LLM → превью → экспорт PPTX. Дальнейшее развитие отложено до финансирования; в бэклоге оставались корпоративный стиль, подключение к базе знаний (тезисы → контент слайдов из KB) и расширение пайплайна.
React + Express/TS, OpenRouter/OpenAI, pptxgenjs
