Наблюдаемост на LLM в многомоделен API Gateway: Traces, Token Ledgers, Tenant Analytics и Safe Prompt Logging

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

Тази статия описва практичен дизайн за анализ на използването на AI и наблюдение на LLM в шлюз, който се изправя пред множество доставчици чрез API, съвместим с OpenAI. Моделът е полезен, дори ако не използвате конкретен доставчик: инструмент веднъж на шлюза, нормализиране на телеметрията на модела, запазване на приписването на таксуването и улавяне на подканящо съдържание само при изрични правила.

Проблемът с четеца: „Кой клиент, модел, подкана или път за извличане е причинил промяната?“

Повечето екипи в крайна сметка се сблъскват със същия пропуск при отстраняване на грешки. Регистрационните файлове на приложението показват, че дадена функция е неуспешна. Таблата за управление на доставчика показват, че използването на токени се е увеличило. Финансите виждат сметка. Нито един от тези изгледи сам по себе си не обяснява пълния път от заявка на наемател до извикване на модел до контекст за извличане, за да опитате отново до таксувана цена.

Целта не е още едно табло за управление с общ брой токени. Целта е да се отговори на оперативни въпроси като:

• Кой клиент или API ключ е причинил скок на разходите?
• Увеличи ли се забавянето след промяна на псевдоним на модел?
• Повторните опити или резервните варианти двойно ли отчитат разходите?
• Коя версия на подкана изразходва най-много бюджет за грешки?
• Работният поток на RAG стана ли скъп, защото извличането добави твърде много контекстни токени?
• Може ли да поддържа отстраняване на грешки при инцидент, без да чете частни потребителски подкани?

Факти, препоръки и прогнози

Факти: OpenTelemetry документира Generative AI семантични конвенции и атрибути за операции на модела, включително имена на операции като chat, generate_content и text_completion. Същата документация предупреждава, че атрибутите на входно и изходно съобщение на GenAI може да съдържат чувствителна информация или PII и може да изискват филтриране или съкращаване. Основните доставчици на модели също излагат табла за управление на употребата, API или експортирания, които могат да поддържат съпоставяне от страна на доставчика, въпреки че подробностите се различават според доставчика.

Препоръки: Използвайте OpenTelemetry за неутрални по отношение на доставчика следи, но запазете бизнес измеренията, притежавани от шлюза, във вашите собствени атрибути и счетоводни книги. Не съхранявайте необработени подкани или изходи по подразбиране. Първо съхранявайте метаданни, хешове, брой токени, идентификатори на шаблони за подкани, имена на схеми, класове грешки и етикети за безопасност. Добавете заснемане на съдържание само като опция за отстраняване на грешки с контролиран достъп и кратко задържане.

Прогноза: Наблюдаемостта на LLM ще стане по-малко за таблата за управление на изолирани доставчици и повече за равнините за контрол на различни доставчици. Екипите ще очакват едно място за разследване на латентност, цена, качество, събития, свързани с политиката, поведение на наемател и делта на таксуването между моделите.

Референтна архитектура: наблюдавайте целия път на заявката

Шлюзът може да види пълния жизнен цикъл на заявката, без да изисква всеки екип на приложението да създава персонализирана телеметрия. Един полезен модел за проследяване започва с един родителски интервал за входящата клиентска заявка и дъщерни интервали за стъпките, които влияят на разходите, забавянето и качеството.

Препоръчителна структура на обхват

• Обхват на заявката за шлюз: заявката е приета, удостоверена, оторизирана, с ограничена скорост и насочена.
• Обхват на обаждането на модела: доставчик, модел, операция, използване на токен, състояние на отговор и закъснение.
• Обхват на извличане: заявен индекс, идентификационни номера на документи или хеширани идентификационни номера, брой парчета, забавяне на извличане и споделяне на контекстни токени.
• Обхват на извикване на инструмент: име на инструмента, състояние, латентност, клас на грешка и класификация на страничните ефекти.
• Обхват на повторен опит: причина за повторен опит, номер на опита, състояние на доставчика и допълнителни разходи.
• Резервен обхват: оригинален модел, резервен модел, тригер, политика за съвместимост и краен резултат.
• Преграда или обхват на модериране: извикване на политика, решение, етикети и дали изходът е бил блокиран или трансформиран.
• Обхват на последваща обработка: JSON проверка, поправка на схема, проверки на цитати или окончателно форматиране.

Родителският диапазон трябва да носи стабилни идентификатори на корелация. Детските обхвати трябва да носят нормализирани технически атрибути. Книгата за използване трябва да съдържа трайни записи за фактуриране и анализи. Избягвайте да поставяте цялата информация в етикетите на показателите; Стойностите с висока кардиналност, като идентификатори на клиенти, хешове за подкани и идентификатори на документи, се съхраняват по-добре в проследявания, регистрационни файлове или таблици на главни книги и след това се агрегират в табла за управление.

Нормализиране на метаданните, заснети при всяко LLM повикване

Всяка заявка за модел трябва да създава последователен запис, независимо от доставчика. Точната схема ще варира, но практическият минимум изглежда така:

<пре><код>{ "request_id": "req_01J...", "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736", "tenant_id": "tenant_123", "team_id": "team_456", "app_id": "support_bot", "gateway_key_id": "ключ_789", "операция": "чат", "доставчик": "име_на_доставчик", "модел": "идентификатор на модел-доставчик", "model_alias": "чат за бърза поддръжка", "prompt_template_id": "refund_policy_v5", "prompt_hash": "sha256:...", "response_schema": "support_answer_v2", "статус": "завършен", "error_class": нула, "latency_ms": 1842, "input_tokens": 2110, "output_tokens": 384, "cached_input_tokens": 1200, "estimated_cost_usd": "0,00492", "final_billed_cost_usd": нула, "finish_reason": "стоп", "retry_count": 0, "fallback_used": невярно, "content_capture_policy": "само метаданни" }

Дръжте две идеи разделени: телеметрията обяснява какво се е случило, докато дневникът за използване записва какво трябва да бъде таксувано, съгласувано и отчетено. Те се препращат взаимно с идентификатори на заявки и идентификатори за проследяване, но не е необходимо да живеят в една и съща система за съхранение.

Изградете книга за токени и разходи, а не само броячи

Броячите на токени са полезни за диаграми, но не са достатъчни за фактуриране или разследване на инциденти. Книгата трябва да представлява преходите на състоянието. Създайте ред, когато шлюзът приеме заявка, след което го актуализирайте, докато заявката напредва.

Полезни състояния на счетоводна книга

• прието: проверките за удостоверяване и правила са преминали.
• препратена: заявката е изпратена до доставчик.
• поточно предаване: доставчикът започна да връща токени.
• завършено: отговорът завърши успешно.
• user_aborted: клиентът прекъсна връзката преди завършване.
• повторен опит: беше направен допълнителен опит за доставчик.
• fallback_used: различен модел или доставчик е избран след грешка или съвпадение на правилата.
• неуспешно: заявката приключи без използваем отговор.
• съгласувано: данните за използването или разходите от страната на доставчика бяха сравнени и приложени.

Този модел на състояние помага за улавяне на често срещани грешки при таксуването и анализа: поточно предавани отговори, когато клиентът е прекъснал връзката, опити за повторен опит, които са били таксувани от доставчика, но скрити от потребителя, резервни пътища, които са отчели грешния модел, и кеширани разлики в отчитането между доставчиците.

Използвайте конвенциите на OpenTelemetry GenAI, след което разширете внимателно

Семантичните конвенции на OpenTelemetry GenAI предоставят преносим речник за операции с модели. Използвайте тези конвенции за общи атрибути като име на операция, доставчик, модел, параметри на заявката, причини за завършване на отговора, използване на токен и състояние на грешка, където са приложими.

Неутралните по отношение на доставчика конвенции обаче няма да обхванат всяко бизнес измерение в шлюза. Добавяне на притежавани от шлюза атрибути или колони в книга за:

• идентификатор на наемател, идентификационен номер на екип, идентификационен номер на дистрибутор и идентификационен номер на приложение;
• идентификатор на ключ за API на шлюза и обхват на ключа;
• план за таксуване, лимит на разходите и бюджетна политика;
• псевдоним на модела и версия на правилата за маршрутизиране;
• ID на шаблона на подкана и версия на подкана;
• име на работния процес и стъпка на работния поток;
• приблизителна цена, крайна таксувана цена и състояние на съгласуване.

Компромисът е кардиналността. Тези полета са ценни за разследване, но могат да направят показателите скъпи и шумни, ако се използват като етикети на показатели навсякъде. Практическо правило е: агрегатите с ниска кардиналност отиват към метрики; идентификаторите с висока кардиналност отиват към трасировки, регистрационни файлове и счетоводни книги.

Проектиране на безопасна подкана и регистриране на изход

Пълното бързо регистриране улеснява отстраняването на грешки, но увеличава поверителността, съответствието, съхранението и излагането на вътрешни рискове. По-безопасното по подразбиране е наблюдението на първо място на метаданните.

По подразбиране: само метаданни

За повечето производствен трафик съхранявайте:

• идентификация и версия на шаблона за подкана;
• хешове на нормализирани подкани и изходи;
• входни, изходни, кеширани и контекстни токени се броят;
• име на схемата на отговор и резултат от проверката;
• етикети за безопасност и политически решения;
• обобщения на грешки и класове грешки на доставчика;
• метаданни за извличане, а не необработени документи.

Включване: контролирано заснемане на съдържание

Ако имате нужда от необработено или редактирано съдържание за дълбоко отстраняване на грешки, изисквайте изрична политика. Добрите контроли включват разрешени списъци на средата, съгласие на клиента, вземане на проби, максимална дължина на полезния товар, автоматично редактиране, кратки прозорци за задържане, криптиране, ролеви достъп, регистрационни файлове за одит и път за одобрение на счупено стъкло за чувствителни инциденти.

Не третирайте редакцията като перфектна. Намалява риска; не го елиминира. За регулирани или високочувствителни работни натоварвания помислете за съхраняване само на хешове и възпроизвеждане на проблеми в синтетичен пакет с одобрени тестови данни.

Добавяне на видимост на RAG като отделен слой

Генерирането с разширено извличане може да промени както качеството, така и цената. Регистрирането само на последното извикване на модел скрива първопричината, когато ретривърът връща твърде много парчета, остарели документи или неподходящ контекст.

За всяка стъпка на извличане заснемете:

• индекс или име на колекция;
• стратегия за извличане и модел на вграждане;
• идентификатори на документи или хеширани идентификатори;
• брой парчета и общ контекстни жетони;
• закъснение при извличане;
• разпределение на най-добрите резултати, ако е налично;
• обхват на цитиране;
• дали извлеченият контекст е използван в крайния отговор.

Това ви позволява да разграничите „моделът се влоши“ от „ретривърът започна да изпраща нискокачествен или прекомерен контекст“. Също така помага да се идентифицират работни потоци, при които контекстните токени доминират общите разходи.

Съгласувайте използването на шлюза с таксуването на доставчик

Прогнозите за шлюза са налични веднага. Данните за фактуриране от страна на доставчика обикновено са по-бавни, но по-достоверни. Използвайте и двете.

Ежедневното задание за съгласуване трябва да сравнява редовете на главната книга на шлюза с API за използване на доставчика, API за разходите, експорти на табло за управление или експорти на фактури. Групирайте делта по доставчик, модел, проект и времеви прозорец. Проследявайте разликите отделно за входни токени, изходни токени, кеширани токени, брой заявки и цена.

Често срещани различия при съгласуване

• Поточното предаване прекъсва връзката: шлюзът може да види прекъснат клиент, докато доставчикът все още таксува генерираните токени.
• Повторни опити: многократните опити могат да бъдат таксувани дори ако бъде върнат само един краен отговор.
• Бързо кеширане: доставчиците могат да излагат отчитането на кешираните токени по различен начин.
• Закръгляване: малки разлики за всяка заявка могат да станат видими в мащаб.
• Отстъпки за партиди или нива: фактурите на доставчика може да прилагат цени, които прогнозата в реално време все още не е знаела.
• Промени от страна на доставчика: ценообразуването на модела, поведението на токенизацията или експортирането на таксуване могат да се променят с времето.

Когато съгласуването открие делта, избягвайте тихото презаписване на вашата счетоводна книга. Съхранявайте първоначалната оценка, съгласуваната от доставчика стойност, източника на съгласуване и кода на причината, ако е известен.

Табла за управление, които отговарят на оперативни въпроси

Стартирайте таблата за управление от проблеми с четеца, а не от показатели за суета. Полезните изгледи включват:

• цена на наемател, екип, приложение и работен процес;
• цена на успешна задача, а не само цена на заявка;
• закъснение на p50, p95 и p99 по доставчик, модел и псевдоним на модела;
• резервен процент и процент на повторни опити по маршрут;
• честота на изчакване и тенденции в класа грешки на доставчика;
• коефициент на попадение в кеша и прогноза за спестяване на кеширани токени;
• честота на неуспешно валидиране на структуриран изход;
• най-популярните версии на подкана по грешка при изгаряне на бюджета;
• споделяне на RAG контекстен токен по работен поток;
• блокове на парапета и удари на класификатора за бързо инжектиране.

За предупреждение комбинирайте технически и бизнес сигнали. Внезапен скок на разходите на наемател може да е по-спешен от малко глобално увеличение на латентността. Скок на резервната честота след промяна на псевдоним на модел може да означава проблем със съвместимостта. Повтарящите се отговори 401, 429 или 5xx може да сочат ключови проблеми, изчерпване на квотите или нестабилност на доставчика.

Минимален поток на внедряване за съвместим с OpenAI прокси

За /chat/completions прокси потокът може да бъде прост:

1. Получаване на заявката и присвояване на request_id и контекст за проследяване.
2. Удостоверете ключа на шлюза и разрешите обхвата на клиента, екипа, приложението и правилата.
3. Създайте участъка на родителския шлюз.
4. Създайте ред в счетоводна книга със състояние accepted.
5. Разрешете псевдонима на модела към модела на доставчика и версията на правилата за маршрутизиране.
6. Запис на метаданни: операция, ID на шаблона за подкана, име на схема, хеш на подкана и политика за улавяне на съдържание.
7. Започнете обхвата на извикване на модела, като използвате семантични атрибути на GenAI, където е приложимо.
8. Препратете заявката до избрания доставчик.
9. За поточно предаване, актуализирайте състоянието, когато пристигне първата част и пребройте използването толкова точно, колкото позволява отговорът на доставчика.
10. При завършване анализирайте използването на доставчика, причината за приключване, състоянието и класа на грешката.
11. Актуализирайте счетоводната книга с токени, прогнозна цена, подробности за повторен/резервен опит и окончателно състояние на заявка.
12. Излъчване на показатели от счетоводната книга и данни за обхват.
13. Извършвайте ежедневно съгласуване и съхранявайте потвърдени от доставчика разходи отделно от първоначалната прогноза.

Контролен списък за внедряване

• Дефинирайте идентификатори на канонични заявки и идентификатори за проследяване.
• Приемане на OpenTelemetry GenAI атрибути за общ модел телеметрия.
• Създайте книга за използване на шлюз с преходи на състояние на заявка.
• Нормализиране на измерения на доставчик, модел, псевдоним на модел, клиент, приложение и работен поток.
• Пазете данни от проучване с висока кардиналност извън етикетите на показателите.
• Направете необработените подкани и улавянето на изхода деактивирани по подразбиране.
• Добавяне на изрични правила за вземане на проби, редактиране, задържане и контрол на достъпа.
• Заснемане на метаданни за извличане за RAG работни потоци.
• Изградете табла за управление за разходи, забавяне, надеждност, валидиране и поведение на наемател.
• Съгласувайте оценките на шлюза с износа на използването на доставчика и разходите.
• Сигнал за пикове на разходите, регресии на забавяне, резервни скокове, неуспешно валидиране и събития, свързани със сигурността.

Заключение

Многомоделният шлюз е правилното място за внедряване на възможност за наблюдение на LLM, защото той вижда заявките, преди да достигнат до който и да е доставчик, и може да прикачи бизнес контекст, който доставчиците не знаят. Най-силният дизайн не е „регистрирайте всичко“. Това е многослоен модел: неутрални спрямо доставчика следи за изпълнение, траен токен и регистър на разходите за таксуване, анализ на клиента за управление, RAG метаданни за качество на извличане и бързо регистриране на поверителността за безопасно отстраняване на грешки.

Започнете с метаданни, преходи на състояния и съгласуване. Добавете заснемане на съдържание само когато политиката, задържането и контролите за достъп са готови. Тази последователност дава на разработчиците доказателствата, от които се нуждаят, за да отстраняват грешки в латентността, качеството и разходите, без да превръщат наблюдаемостта в нов риск от излагане на данни.

Свързано четене

• повторни опити и резервно поведение в LLM API маршрутизиране
• бързо кеширане и пакетни модели за контрол на разходите
• управление на ключове за API на екипа и ограничения на разходите