Як Uber будує AI Assistant для водіїв на OpenAI

Водій працює в системі, де попит, пропозиція, географія, час і доступність типів поїздок змінюються постійно. Статичний FAQ тут майже декоративний: корисна відповідь повинна враховувати актуальний marketplace state і контекст конкретного водія. Тому AI Assistant має не просто пояснювати продукт, а перетворювати live signals на зрозумілі рекомендації без вигадування того, чого система не знає.

Ключова архітектурна межа — recommendation не є system of record. Модель може пояснити earnings trend або підказати, де зараз вищий попит, але факт eligibility, incentive, current heatmap або доступність конкретної функції має приходити з authoritative Uber systems. Якщо live evidence недоступне, правильний terminal state — degraded guidance або explicit uncertainty, а не переконлива фантазія про ринок.

Trigger — запит водія в Uber Assistant, follow-up у поточній сесії або voice interaction. Input — authenticated user identity, role/account state, location/time context, task-eligible marketplace signals, product/policy knowledge і user preferences. До model call application layer фільтрує дані за purpose та permission; історія розмови не замінює current marketplace query.

AI stage складається з intent classification, retrieval/tool planning, specialist routing, synthesis і response/action preparation. Integrations — marketplace APIs, earnings/heatmap signals, account/product knowledge, navigation/deep links, safety/policy services і voice Realtime API. Output — grounded explanation, recommendation, comparison або підготовлений next step із freshness evidence.

• Trigger → driver question або voice request.
• Input → authenticated context + current marketplace evidence.
• AI → classify → route → retrieve/call tool → synthesize.
• Integrations → marketplace, account, policy, navigation, voice.
• Output → recommendation або bounded action preparation, не прихована autonomous authority.

OpenAI описує multi-agent design, де lightweight classification і прості запити можуть йти в швидші nano/mini models, а складніші задачі — у сильніші reasoning models. Production routing має починатися не з питання «яка модель найрозумніша», а з deterministic eligibility: які tools, data classes, latency budget і authority дозволені цьому intent.

Router зберігає versioned decision trace: intent, risk tier, candidate models, selected route, fallback reason, tool scope та cost. Provider/model failover не повинен непомітно змінювати policy або data residency. High-risk route може бути дорожчим і повільнішим, якщо він дає кращий evidence contract; простий navigation query не повинен оплачувати frontier reasoning без причини.

Uber Engineering окремо описує проблему identity для agentic systems: агент діє від імені людини або сервісу, тому actor chain, scopes і downstream authorization мають бути machine-verifiable. Для відтворення потрібен short-lived token або інший scoped credential, прив'язаний до authenticated actor, конкретного resource/action і expiry; модель не отримує reusable secret.

Tool call перевіряється поза LLM: хто користувач, який account, яка дія, чи дозволена вона зараз, чи не змінився policy state. Якщо користувач просить «увімкни все, щоб заробляти більше», модель може пояснити доступні опції, але application policy вирішує, які settings взагалі існують і чи може агент їх змінювати.

OpenAI описує Uber AI Guard як internal governance layer для safety, privacy, security, policy і hallucination consistency. Для production це не один classifier, а кілька control points: input/content policy, source eligibility, prompt-injection resistance, tool authorization, output validation, PII minimization і postcondition verification.

External web content, support text і tool outputs трактуються як data, а не instructions. Навіть успішна prompt injection не повинна отримати sink із небезпечним authority: egress, account mutation, payout change або secret access мають deterministic policy gates. Safety-layer вимірюється не лише detection rate, а prohibited-action rate та blast radius після adversarial input.

Realtime voice прибирає friction, але додає transcription error, interruption, noisy environment, accidental confirmation і race між user speech та tool execution. Critical slots — location, amount, option, identity-related field — треба повторювати або показувати в UI перед consequential action. Conversation barge-in не повинен створювати два паралельні side effects.

Voice trace зберігає turn IDs, ASR confidence where available, selected intent, tool calls і terminal reason, але не перетворюється на безмежний archive raw audio. Для privacy-sensitive сценаріїв metadata-first telemetry і retention policy важливіші за бажання «логувати все на випадок дебагу».

Failure modes: marketplace API timeout, stale heatmap, user location mismatch, account-state change, classifier misroute, model fallback, voice disconnect, policy-service outage і tool timeout після side effect. Read-only recommendation може перейти в degraded mode; будь-яка невизначеність після write вимагає authoritative reconciliation.

Кожен write-capable request отримує idempotency key. Якщо відповідь загубилась після submit, система спочатку читає current authoritative state і лише потім вирішує, чи потрібен retry. Resume після довгої паузи повторно перевіряє identity, permission, freshness і preconditions — session history не є доказом, що умови досі ті самі.

Eval corpus ділиться за slices: simple FAQ, current marketplace, ambiguous goal, unavailable feature, stale data, no-live-data, conflicting sources, wrong-driver context, prompt injection, restricted data, voice noise, latency spike, model fallback і timeout після action. Graders окремо оцінюють intent, source correctness, freshness, unsupported claims, policy compliance, action arguments і final system state.

Для рекомендацій потрібен outcome-aware check: чи посилалася відповідь на дійсні signals, чи не зробила causal earnings claim із correlation, чи коректно abstain-нула без даних. Для tool path важливі trajectory, authorization decision та authoritative postcondition. Incident із production додається як permanent regression case.

При marketplace scale cost складається не лише з tokens. Повна модель: classification/routing, frontier inference, real-time marketplace APIs, vector/search layer, voice streaming, AI Guard, identity/token services, telemetry, eval infrastructure, human support, incident handling і engineering maintenance. Найкорисніший KPI — cost per verified useful outcome, а не середня ціна одного model call.

Scalability потребує cache тільки для даних із правильним TTL. Product knowledge можна кешувати довше; current marketplace signals — значно коротше. Routing має обмежувати fan-out і parallel specialists. Rate limit або provider outage переводить систему у graceful fallback, а не запускає uncontrolled retry storm у момент пікового попиту.

Етап 1 — один read-only intent із current authoritative source і manual review. Етап 2 — intent router + two-model pool + evidence trace. Етап 3 — broader marketplace retrieval та UI deep links. Етап 4 — voice. Етап 5 — bounded reversible actions із exact confirmation та reconciliation. Лише після failure drills можна підвищувати autonomy.

Патерн підходить marketplaces, delivery, mobility, field service і gig platforms, де користувачу потрібне context-aware рішення в реальному часі. Не підходить для систем, де source-of-truth недоступний або business owner не може визначити authority boundary. Найсильніша 80/20 версія — один high-frequency driver intent із live evidence, а не «AI для всього Uber» за один квартал.