Платформа AI-видимості (GEO/AEO)

Я був єдиним інженером платформи AI-видимості (GEO) — продукту, що вимірює, як бренд з’являється у відповідях ШІ-асистентів, і допомагає це покращити. Вів її повністю: від першого архітектурного рішення до системи в продакшні.

Контекст

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

Що я побудував

Монорепозиторій на TypeScript, задеплоєний як кілька сервісів із CI/CD. Мультиагентні конвеєри вимірюють видимість, аналізують відповіді та формують звіти. Node.js API стоїть перед фоновими воркерами й чергами; Next.js-дашборд, адмін-панель і браузерне розширення — поверхні, якими користуються люди. Два MCP-сервери відкривають можливості платформи ШІ-клієнтам та внутрішнім інструментам.

Архітектура й рішення

Агенти за чергою. Запуски вимірювання повільні й обмежені rate-limit, тож API ніколи не викликає LLM синхронно. Робота йде в чергу й обробляється фоновими воркерами — це тримає API чуйним, а дорогі виклики робить ретраябельними та ідемпотентними.

Agent-harness runtime. Агенти працюють усередині харнесу, який планує їх, застосовує бюджети, записує трасування кожного кроку й коректно відновлюється, коли один падає, — з власним об’єктним сховищем для артефактів запусків. Два MCP-сервери (публічний і адмінський) відкривають платформу ШІ-клієнтам та внутрішнім інструментам.

Мультипровайдерність за дизайном. Платформа працює з OpenAI, Anthropic, Google і Perplexity. Промпти й конвеєри написані один раз і оцінюються за якістю відповіді, тож провайдера можна замінити чи порівняти без переписування конвеєра.

Явний стан і трасування. Кожен запуск — довговічний запис; кожен крок пише входи й виходи. PostgreSQL тримає реляційний стан, Redis — черги й кеш, MinIO зберігає великі артефакти поза БД. OpenTelemetry трасує кожен запуск, тож коли відповідь виглядає неправильно, трасування пояснює чому — саме ця спостережність зробила набір недетермінованих агентів керованим.

Моя роль

Усе: архітектура, API, воркери, модель даних, агентні конвеєри, MCP-сервери, дашборд і браузерне розширення, плюс DevOps — Railway, Vercel, Docker, моніторинг і спостережність. Повна технічна відповідальність, самостійно.

Що я залишив би

Дизайн «трасування передусім». Те, що кожен запуск — довговічний трасований запис, і перетворило набір недетермінованих агентів на систему, яку я міг налагоджувати й змінювати в продакшні.