Бывало ли, что вы не спали ночами из-за счёта за ИИ, который взлетел за ночь, без единой зацепки, в чём дело?
Это скелет в шкафу ИИ-разработки: модели жрут токены, как спорткары бензин, а без приборной панели летишь вслепую. На сцену выходит паттерн с тремя таблицами — requests, responses, exchanges. Одна на первый взгляд простая структура фиксирует, что вы отправили, что прилетело в ответ, и связывает их железно — расходы вываливаются сами. Я наблюдал, как она рассеивает туман в чатах, фоновых задачах, везде, где ИИ задевает код.
И вот в чём магия: это не раздутая корпоративная монстра. Всего три таблицы, обмен ID — и каждый обмен под контролем. Без рытья в логах. Без гаданий по UI.
Почему прослеживание обменов ИИ кажется колдовством — до сегодняшнего дня?
Смотрите, ИИ — это платформенный сдвиг покруче iPhone: модели как эндпоинты, промпты как API. А расходы? Это плата за магию. Токены на входе, на выходе, тарифы вендоров — всё умножается в разы.
TL;DR: Добавляете ИИ в приложение? Сохраняйте запрос, сохраняйте ответ и связывайте их обменом. Эта структура делает каждый обмен отслеживаемым — а расходы на токены вылезают сами.
Вот исходная идея, прямехонько из окопов. Бум. Авторитет.
Мой поворот? Это эхо рождения веб-мониторинга — помните, когда логи HTTP-запросов были экзотикой? Теперь это база, спасибо New Relic. Перенесёмся (нет, не надо): этот танец с тремя таблицами — New Relic для ИИ. Пока примитив, завтра везде. Смелый прогноз: к 2026-му встроят в фреймворки вроде LangChain, выжигая утечки промптов на корню и режа отходы.
Короткий абзац. Удар.
Разберём по полочкам. Таблица requests: ввод юзера, его ID, контекст (допустим, ID транскрипта YouTube), статус pending. Минимум. Responses: вывод модели, может JSON-структура, счётчики токенов порой тут. Exchanges: клей — request_id, response_id, input_tokens, output_tokens, model_used, status. По строке на ход чата. Запросите — и счёт готов.
Поток? Вставляем request (pending). Вставляем exchange (привязка к request, pending). Бьём по модели. Вставляем response. Обновляем exchange: токены, модель, готово. Фейл? Помечаем фейл. Всегда готово к аудиту.
Как это подключить в Supabase — без потери рассудка?
Supabase тут на высоте — Postgres внутри, edge-функции для вызовов. Пример: чат UI с запросами к транскриптам YouTube.
Код падает в дело: insertKnowledgeTranscriptChatRequest. Хватает user_id, transcript_id, content, ставит pending. Возвращает ID.
Дальше insertKnowledgeTranscriptChatExchange: привязка к request_id, user_id, pending.
Модель стреляет — скажем, GPT-4o-mini. Ответ прилетает: обновляем exchange с response_id, токенами, моделью, completed.
Клиент ловит responseId, tokens, modelUsed. Redux-слайс нормализует — без лишнего сервиса по расходам. Сессия читает затраты напрямую.
Магия в действии. Масштабируется — та же форма для задач по генерации идей для блога. Топик, контекст ICP в request. Структурированные идеи, токены в response. Exchange связывает. Redux по ID. Всё в унисон.
Но погодите — корпоративный хайп? Нет, это чистый прагматизм для девов. Без локина на вендора. Postgres где угодно.
Фрагмент: Чисто.
Глубже: токены в exchange — и агрегация поёт. “Сколько юзер X спустил за месяц?” SELECT SUM(input_tokens * price_per_million) FROM exchanges JOIN users… Готово. Дашборды расцветают.
Или дебаг: “Почему промпт лёг?” Вытаскиваем request.content, response.structured. Без бардака.
Взорвёт этот паттерн расходы на ИИ-разработку — или закопает их?
Закопает. Моя уникальная ставка: это недостающий слой мониторинга для эры агентов. Агенты цепляют вызовы; без этого — чёрная дыра токенов. Фиксируйте exchanges на запуск агента — и ROI на пальцах. Исторический параллель? Unix-пайпы — простая связка сделала сложность компонуемой. Тут то же для ИИ-пайплайнов.
Настоящий выигрыш: фоновые задачи по блогам. createMarketingBlogIdeationRequest: топик, контекст, ICP, mode, pending. Response: структурированны
