Перейти до вмісту
Reldava Tech

Reldava Tech

Будую системи, які можуть довести, що працюють.

Продакшн-системи - мультитенантна RAG-платформа, SaaS для AI-чатботів, рушій аналізу репозиторіїв - спроєктовані, побудовані, розгорнуті і виміряні одним інженером.

Обговорити задачуПодивитися проєкти

Відкритий до контрактної роботи.

Що я будую

Чотири речі, і зазвичай вони приходять разом.

RAG, агенти та LLM-системи

Гібридний пошук і реранкери; агентні цикли з власними інструментами і будь-яким MCP-сервером, який ви додасте; прогони оцінювання, які показують ціну зміни до релізу; вартість і токени, пораховані на кожен запит. Моделі, які працюють не лише за API, а й усередині деплою: ембедінги, зведені до спільної розмірності між провайдерами, крос-енкодер, що ранжує на CPU, локальні моделі через Ollama, визначення мови при інгесті, щоб кожен документ індексувався своєю. Пайплайни, які версіонуються і вимірюються, тому зміна в них - це експеримент, а не ставка.

Цілі продукти, а не прототипи

Автентифікація, організації, квоти, білінг, адмін-консоль, OAuth-інтеграції, канали спілкування, деплой. Усе, що демо пропускає, а платний клієнт помічає на другий день: ліміти тарифу, проти яких списується не лише чат, а й індексація, рядок аудиту за кожною чутливою дією і міграції, які тягнуть це все далі без вікна простою.

Операційність, яку видно

Метрики, трейси, вартість на рівні промпта, дашборди з репозиторію, ранбуки для інциденту о третій ночі. Чотири інструменти на чотири різні питання: що модель побачила і скільки це коштувало, куди пішов час усередині одного запиту, що відбувається на всіх запитах разом і коли когось треба будити. Якщо ніхто не може сказати, що зламалося, - робота не завершена.

Аналіз кодових баз

Що репозиторій каже про процес, який його породив: де концентруються переробки, хто насправді володіє якою областю, скільки коштуватиме передача знань. На реальній кодовій базі розробник з найбільшою кількістю комітів володів трьома відсотками бекенда - наївний підрахунок перевертає картину. Докази, сформульовані як питання, а не як вироки.

Вибрані проєкти

Кілька систем, які я побудував. Кожна пройшла шлях від порожнього каталогу до робочого деплою.

Чим можу допомогти

Чотири формати співпраці. Кожен описується письмово до того, як почнеться.

  • Побудувати

    Система, доведена від порожнього каталогу до продакшну і підтримана після запуску: архітектура, реалізація, деплой і дашборд, який каже, чи вона здорова.

    Фіксований обсяг, поетапна здача

  • Аудит RAG та LLM

    Наявна AI-функція, виміряна замість того, щоб про неї сперечатися: якість пошуку на вашому корпусі, вартість відповіді, що каже еталонний набір і які зміни варто зробити першими.

    Один-два тижні, письмовий звіт з числами

  • Дью-ділідженс кодової бази

    Для власника або інвестора, який дивиться на код, що писав не він: володіння, переробки, bus-фактор і скільки коштуватиме передача знань - як питання з прикріпленими комітами.

    За репозиторій, з розбором на дзвінку

  • Технічна експертиза

    Аудит архітектури, вибір моделей і постачальників, будувати чи купувати, і друга думка про план, поки міняти його ще дешево.

    Постійно, погодинно або помісячно

Як я працюю

Шість звичок, які видно в кожному з цих репозиторіїв.

  1. Розвідка перед кодом

    Спочатку прочитати те, що вже є - дані, наявний процес, бізнес-правила, які ніхто не записав, - і скласти їх каталог. Те, що вже існує, це специфікація, а не зразок коду.

  2. Рішення живуть поруч з кодом

    Кожен неочевидний вибір отримує письмовий запис з альтернативами і причиною. Через півроку на питання відповідає репозиторій, а не пам'ять.

  3. Суперечки закінчуються числами

    Еталонний набір питань, зафіксований пайплайн, одна зміна за раз. Сім метрик замість однієї, бо оптимізація єдиного числа - це те, як система гіршає, поки її оцінка росте.

  4. Продукт вирішує власник

    Продуктові питання ставляться до реалізації, простою мовою, з озвученим компромісом. Я не закриваю їх мовчки всередині коміту.

  5. До користувача доходить проста мова

    Кожна настройка, до якої може дотягнутися нетехнічна людина, пояснена там, де вона стоїть. Внутрішні назви ніколи не з'являються в інтерфейсі.

  6. Чесні межі

    Те, чого система не вміє, записано поруч з тим, що вона вміє. Інструмент, який ніколи не каже "тут усе гаразд", нічого не міряє, а обіцянка, що тихо перевищує докази, коштує дорожче, ніж приносить.

Стек

Чим користуюся. Це список того, на чому реально працюють ці системи.

Мови
  • TypeScript
  • Python
  • SQL
  • Bash
Веб
  • Next.js
  • React
  • Tailwind
  • FastAPI
  • Node
Дані
  • PostgreSQL
  • pgvector
  • Postgres FTS
  • ltree
  • Redis
  • Drizzle
  • Alembic
AI
  • OpenAI
  • Anthropic
  • Gemini
  • Ollama
  • LangGraph
  • MCP
  • Крос-енкодер реранкери
  • tree-sitter
Операції
  • Docker
  • Helm
  • Terraform
  • GitHub Actions
  • Prometheus
  • Grafana
  • OpenTelemetry
  • Langfuse
  • systemd
Продукт
  • Stripe
  • OAuth
  • Telegram
  • WhatsApp
  • Messenger
  • Instagram
  • Playwright
  • pytest

Про мене

Я інженер. Я веду систему від порожнього каталогу до того, що працює в продакшні, і залишаюся за неї відповідальним після запуску: схема, пошук, інтерфейс, білінг, деплой і дашборд, який каже, чи вона здорова.

Reldava Tech - це ім'я, під яким живуть мої продукти. Усе на цьому сайті побудовано однією людиною, і саме тому кейси розповідають про компроміси, а не про розмір команди.

Розкажіть, що ви будуєте

Для початку достатньо опису задачі. Якщо це моє - скажу, що б я побудував, скільки це приблизно займе і чого робити не став би.

Обговорити задачу