Як TRUSTBANK побудував Choice AI для Furusato Choice

Furusato Nozei має незвичну user journey: людина не просто купує товар, а намагається використати donation limit, підтримати municipality і вибрати thank-you gift серед величезного каталогу. Keyword search слабкий, коли intent нечіткий: «щось для батьків», «локальна їжа» або «подарунок у межах бюджету».

TRUSTBANK разом із Recursive побудував Choice AI як conversational discovery layer над Furusato Choice. Production-цінність тут не в красивій відповіді LLM, а в перетворенні fuzzy intent на контрольований retrieval/recommendation flow, який повертає реальні catalog entities з актуальними attributes.

Trigger — користувач відкриває Choice AI або задає natural-language запит. Input: текст, user state, first-time/existing-user context, preferences, budget/donation constraints і catalog data. Routing model визначає intent і передає task Search, Recommendation або Greeting agent; subagents/tools дістають додатковий context.

Output має бути не просто prose: конкретні gifts/municipalities з IDs або links, пояснення відповідності intent, relevant constraints і можливість уточнити запит. Transaction/donation confirmation залишається окремим product flow; recommendation agent не повинен самостійно створювати фінансове зобов’язання.

OpenAI описує multi-agent architecture: routing model класифікує intent, після чого Search Agent, Recommendation Agent або Greeting Agent виконують спеціалізовані задачі й можуть викликати subagents/tools. Prompt path змінюється залежно від user-specific state. Це A3: система автономно оркеструє discovery, але high-impact transaction лишається поза її authority.

Для відтворення router contract має бути typed: intent, confidence, required context, chosen agent і fallback reason. Specialist agent отримує лише потрібні tools/scopes. Retrieval повертає product IDs, freshness/version та provenance. Final response не може вигадувати catalog attribute, якого немає в authoritative source.

Choice AI використовує різні interaction paths для new та existing users. OpenAI також описує controlled randomness і variation across prefectures, щоб recommendations не концентрувалися лише на найпопулярніших items. Це продуктова policy, а не магічна властивість моделі.

Відтворення потребує явного policy layer: які user attributes дозволено використовувати, які preference signals ephemeral, як пояснюється recommendation diversity та які categories не можна систематично suppress. Персоналізація без measurement швидко стає прихованим ranking bias.

OpenAI повідомляє, що Choice AI працює на GPT-4.1 series, default — GPT-4.1 mini, а команда експериментує з nano та larger models залежно від latency й accuracy testing. Це production pattern: модель обирається за task slice та acceptance threshold, а не за найдовшою назвою.

Routing table може бути таким: greeting/simple intent → дешевший model; ambiguous multi-constraint recommendation → stronger model; no-answer/unsafe state → clarification або fallback. Model change вимагає frozen eval replay, cost/latency comparison і canary, бо однаковий prompt на іншій revision може змінити ranking behavior.

Failure modes: router вибрав неправильного agent; item stale або недоступний; budget interpreted неправильно; generated recommendation не відповідає returned catalog IDs; duplicate items домінують; latency fallback змінює quality; prompt injection захована в catalog text.

Контролі: schema-validated tool results, product-ID join до source of truth, freshness TTL, eligibility filter після retrieval, diversity/ranking policy, prompt-injection sanitization, no-answer state та fallback to standard search. Якщо downstream transaction має unknown state — authoritative read-back, не повторення donation.

OpenAI повідомляє, що Choice AI users мали higher conversion than standard on-site search, без універсального процента. Recursive окремо публікує 78% accuracy; це partner-reported task metric і без повної methodology не може переноситися як universal recommendation accuracy.

Eval suite: intent routing accuracy, Recall@k для eligible items, unsupported-attribute rate, budget/constraint violations, diversity, no-answer correctness, latency, cost per successful discovery, downstream conversion та correction/abandonment. Business KPI читаються разом із quality/safety slices, а не замість них.

Consumer discovery працює bursty: traffic peaks, long catalogs та iterative conversations швидко збільшують retrieval/model cost. Full cost = model calls + embeddings/search/reranking + catalog sync + cache + telemetry + moderation + experimentation + engineering/support. Cache дозволяється лише для safe state і не повинен зберігати stale user context.

Rollout: offline historical queries → shadow recommendations → small traffic canary → comparison with search baseline → personalization → model routing → promotion після stable catalog-consistency і нуль severe constraint violations. Кейс підходить marketplaces із великим каталогом і fuzzy intent; не підходить там, де catalog truth відсутня або transaction віддається LLM.