Водич и увид

Обједињени пакетни послови преко АИ АПИ мрежног пролаза: издржљиви редови, адаптери добављача и наплата на нивоу станара

Практична архитектура за покретање АИ радних оптерећења која су толерантна на кашњење кроз један АПИ са више модела: трајни записи послова, пакетни адаптери добављача, идемпотентно уношење резултата, резервација буџета и аналитика на нивоу станара.

<п>Серијална обрада не треба да се третира као споредна врата око вашег АИ АПИ мрежног пролаза. Ако евалуације, обогаћивање докумената, екстракција, модерирање или уграђивање напусте синхрони пут захтева, и даље су им потребне контроле закупаца, атрибуција трошкова, поновни покушаји, могућност ревизије и аналитика коришћења.<п>Шаблон имплементације је да се пакетно извршавање учини првокласним подсистемом пролаза. Мрежни пролаз треба да открије један уговор о послу који је неутралан за добављача док се прилагођава ОпенАИ, Антхропиц, Гемини и будућим пакетним АПИ-јима добављача иза сцене.<х2>Проблем читача: АПИ-ји серије су слични по намери, различити у раду<п>Пословна оптерећења која толерише кашњење су природна за групно извршавање. Тежи део није одлучивање да ли посао може да чека. Тежак део је конзистентно функционисање групног рада међу добављачима.<п><стронг>Проверене чињенице: ОпенАИ-јев пакетни АПИ је асинхрони, чита захтеве из отпремљене датотеке, уписује одговоре у излазну датотеку и тренутно користи 24-часовни прозор за обраду. ОпенАИ наводи статусе као што су <цоде>потврђивање, <цоде>неуспешно, <цоде>у_прогресс, <цоде>финализинг, <цоде>цомплетед, <цоде>истекло, <цоде>отказивање и <цоде>отказано. Антхропиц-ов АПИ пакета порука обрађује многе захтеве за поруке асинхроно, управља сваким захтевом независно, захтева анкетирање и враћа резултате након завршетка обраде. Антхропиц такође препоручује смислене вредности <цоде>цустом_ид јер редослед резултата није загарантован. Гемини-јев пакетни АПИ излаже дуготрајне методе у стилу операција као што су методе листе, отказивања, брисања и ажурирања, а његова операција отказивања је описана као најбољи напор.<п>Те разлике су битне када додате стварне пословне захтеве:<ул><ли>Који закупац, клијент, пројекат или АПИ кључ поседује сваку ставку?<ли>Као је посао препустио буџет? мрежни пролаз?<ли>Које завршене ставке се наплаћују ако група истекне или је отказана?<ли>Како се поново покушавају делимични неуспеси без дуплирања успешног рада?<ли>Колико дуго могу да се преузимају датотеке резултата и шта би требало да чува мрежни пролаз?<ли>Може ли партнер да обезбеди пакетну обраду без експонирања пакета који експонира клијента. акредитиви?<п>Одговор није да се сакрију све разлике међу добављачима. Одговор је да се нормализује оперативни уговор уз очување изворних метаподатака добављача за отклањање грешака, усаглашавање и подршку.<х2>Препоручени јавни АПИ: одвојите групне послове од синхроних довршавања<п><стронг>Препорука: изложите пакетне послове као сопствену АПИ површину, а не као посебну ознаку за ћаскање. Синхрони захтев и асинхрони скупни посао имају различиту семантику животног циклуса, обрачуна, поновног покушаја и преузимања резултата.<п>Практични уговор о мрежном пролазу укључује ове операције:<ул><ли><цоде>цреате_јоб: креирајте радну верзију посла у власништву закупца, пројекта, кључа или клијента партнера><ли><мс><ли><мсцоде><ли><мсцоде>. <цоде>уплоад_манифест: додајте појединачне захтеве са стабилним идентификаторима ставки.<ли><цоде>субмит: потврдите, резервишите буџет, изаберите добављача, отпремите и закључајте достављени манифест.<ли><цоде>гет_статус: вратите нормализован посао и број ставки.<ли><цоде>грешка резултата, ит_ресулт, ><цоде>ем_лист> ит_> коришћење.<ли><цоде>отказивање: отказивање захтева, без обећања тренутног прекида.<ли><цоде>екпорт_усаге: извоз записа трошкова на нивоу посла и ставке за аналитику или системе наплате.<п>Пример јавног објекта посла:<пре><цоде>{ "јоб_ид": "јоб_01ј7...", "тенант_ид": "тенант_ацме", "цустомер_ид": "цуст_123", "крајња тачка": "цхат.цомплетионс", "модел": "велика анализа", "статус": "у току", "броји": { "послато": 50000, "завршено": 31240, "неуспешно": 180, "истекао": 0 }, "цена": { "процењено": "184,20", "резервисано": "205.00", "решено": "117,43", "валута": "УСД" }, "цреатед_ат": "2026-08-19Т10:00:00З", "субмиттед_ат": "2026-08-19Т10:05:00З", "ретриевал_деадлине": "2026-09-17Т10:00:00З" }<п>Јавни објекат подразумевано не би требало да излаже ИД-ове датотека добављача, имена операција или необрађене грешке у узводном току. Они спадају у метаподатке окренуте оператеру.<х2>Користите трајне записе послова као извор истине<п>Батцх слоју у власништву мрежног пролаза потребно је трајно стање пре него што се било шта пошаље узводно. Немојте се ослањати на записе о серијама добављача као своју једину државну продавницу. Евиденција добављача је неопходна, али не познаје вашу хијерархију станара, резервације буџета, псеудониме интерног модела, партнерске клијенте или захтеве за аналитику.<х3>Минимални модел базе података<п>Корисна шема има три нивоа:<п><стронг>1. Батцх посао<пре><цоде>батцх_јобс - јоб_ид - тенант_ид - пројецт_ид - цустомер_ид је нулл- апи_кеи_ид - крајња тачка - рекуестед_модел - ресолвед_провидер - ресолвед_провидер_модел - статус - итем_цоунт - процењени_улазни_токени - процењени_излазни_токени - резервисани_износ - измирени_износ - цреатед_ат - Субмиттед_ат - цомплетед_ат - екпирес_ат - ретриевал_деадлине - цанцеллатион_рекуестед_ат<п><стронг>2. Батцх итем<пре><цоде>батцх_итемс - јоб_ид - итем_ид - цустом_ид - идемпотенци_кеи - рекуест_хасх - статус - провидер_рекуест_индек нуллабле - процењени_токени - стварни_инпут_токенс је нуллабле - стварни_излазни_токени је нуллабле - сеттлед_амоунт нуллабле - показивач резултата је нулл - еррор_цоде нуллабле - ретри_оф_итем_ид нуллабле - цреатед_ат - сеттлед_ат<п><стронг>3. Метаподаци добављача<пре><цоде>батцх_провидер_метадата - јоб_ид - провајдер - провидер_батцх_ид нуллабле - инпут_филе_ид нуллабле - оутпут_филе_ид нуллабле - еррор_филе_ид нуллабле - Оператион_наме нуллабле - крајња тачка - регион је нуллабле - нативе_статус - нативе_рекуест_цоунтс јсонб - ласт_поллед_ат - рав_еррор_поинтер нуллабле<п>Одржавање метаподатака добављача одвојено од јавног уговора о послу омогућава гатеваи-у да развије адаптере добављача без прекида АПИ-ја који се суочавају са закупцима.<х2>Захтевајте стабилне идентификаторе ставки пре слања<п><стронг>генеришите препоруку за <п><стронг>препорукупрепоруку за кодирање:цоде агаваи: пер-итем <цоде>цустом_ид или кључ идемпотенције пре слања. Никада не усаглашавајте резултате по редоследу.<п>Антхропиц изричито упозорава да редослед резултата није загарантован и препоручује смислене вредности <цоде>цустом_ид. Чак и када се чини да провајдер чува ред, мрежни пролаз не би требало да зависи од њега. Послови се деле, покушавају поново, отказују, делимично довршавају и поново уносе. Претпоставке о наручивању на крају не успеју.<п>Формат безбедног идентификатора ставке је дескриптиван, али није осетљив:<пре><цоде>тенантА.инвоице_ектрацтион.2026-08-19.ров_000381<п>Избегавајте стављање необрађених е-порука, имена клијената, наслова тајних докумената у идентификацију докумената Чувајте осетљиве податке о корелацији унутар сопствене базе података закупаца, а не унутар ИД-ова видљивих од добављача.<х2>Нормализујте статусе без брисања детаља о добављачу<п>АПИ пакета добављача излажу различите животне циклусе. Мрежни пролаз треба да их нормализује у малу интерну државну машину коју контролне табле, обрачун и аутоматизација могу да разумеју.<п><стронг>Препоручени нормализовани животни циклус:<ул><ли><цоде>нацрт: посао постоји, али се још увек може уређивати.<ли><цоде>провера: мрежни пролаз. још се обрађује.<ли><цоде>у току: добављач обрађује ставке.<ли><цоде>финализирање: добављач је завршио израчунавање и припрема артефакте резултата.<ли><цоде>завршено: све прихваћене ставке су постигле терминални успех.<ли><цоде>цомплетед_витх_еррорс: неке ставке су урађене и неке ставке суцце> неуспешно.<ли><цоде>истекао: прозор добављача је завршен пре него што су сви радови завршени.<ли><цоде>цанцел_рекуестед: закупац је затражио да откаже, али коначни наплативи посао није измирен.<ли><цоде>отказан: отказивање је решено.<ли><цоде>неуспешно отказивање. извршење.<п>Немојте прерано сажимати грешке изворног добављача у генеричке ознаке. Оператерима је и даље потребан приступ изворним статусима, грешкама валидације, бројању захтева, ИД-овима датотека и називима операција приликом отклањања грешака.<х2>Проверите матрицу могућности пре слања<п><стронг>Препорука: покрените проверу пре објављивања пре резервације буџета и слања добављача. Батцх режим није само синхрони режим са кашњењем. Неки модели, крајње тачке, функције захтева, региони и конфигурације алата можда неће бити подржане од стране пакетног АПИ-ја добављача.<п>Ваша интерна матрица способности треба да провери:<ул><ли>Подржана крајња тачка: ћаскање, поруке, уградње, модерирање или генерисање.<ли>Подобност модела,<ем величина захтева за пакет>Мак ит сизе. и величина отпремљене датотеке.<ли>Да ли је стримовање забрањено.<ли>Подршка за коришћење алата и позивање функција.<ли>Подршка за структурирани излаз или ЈСОН шему.<ли>Подршка за слике, аудио или мултимодални унос.<ли>Ограничења региона и пребивалишта.<ли>Ретрие ретрие анд Ресидентиал Ретриемент Ретрие <ли>Резултат. прозори.<ли>Ограничења брзине и редоследа специфична за групу.<ли>Семантика отказивања.<п>Добар одговор пре прегледа је специфичан:<пре><цоде>{ "еррор": "батцх_цапабилити_нот_суппортед", "мессаге": "Одабрани пакетни адаптер провајдера не подржава стримовање одговора. Уклоните стреам=труе или изаберите синхрони крај.", "фиелд": "итемс[*].рекуест.стреам"}<п>Ово је корисније од прихватања посла и неуспеха након претходног проласка валидације.<х2>Резервишите буџет закупца, а затим измирите стварну употребу<п>Скупно извршење компликује наплату јер мрежни пролаз може да изгуби синхрони приступ тачном коришћењу док датотеке резултата не буду доступне. Безбедан образац је цитирање, резервисање, слање, унос, поравнање и усаглашавање.<п><стронг>Проверене чињенице: ОпенАИ наводи да се цене АПИ-ја пакета нуде са попустом у поређењу са синхроним АПИ-јима, а истекли или отказани пакети и даље могу да врате завршен посао који се наплаћује. Антхропиц напомиње да скупна обрада високог протока може мало да премаши ограничење потрошње радног простора, што чини резервацију на страни пролаза и после поравнања важним.<п><стронг>Препорука: резервишите буџет станара пре подношења користећи процењене токене, правила о цени одабраних добављача и сигурносну маргину. Након што се резултати прогутају, поравнајте стварну употребу на нивоу ставке. Ако је процена била превисока, отпустите неискоришћену резервацију. Ако је био пренизак, примените конфигурисану политику закупца.<п>Практични догађаји у књизи:<пре><цоде>батцх.естиматед батцх.ресервед батцх.субмиттед батцх.итем.сеттлед батцх.итем.рефундед батцх.цанцел_рекуестед серија.истекаобатцх.рецонцилед<п>Књига на нивоу ставке је неопходна. Ако је 45.000 ставки довршено, а 5.000 истекне, закупцу би требало да се наплати завршен посао провајдера, а не оригинални манифест као један недиференцирани блоб.<х2>Изградите адаптере добављача као преводиоце, а не као власници пословне логике<п>Сваки адаптер добављача треба да зна како да трансформише посао мрежног пролаза, врати статус гатеваи-а, врати га у пакет за преузимање, врати статус гатеваи-а у пакет. резултате и мапирајте изворне исходе назад у нормализоване записе.<п>Задржите политику закупца изван адаптера. Адаптер не би требало да одлучује да ли корисник има довољно буџета, да ли је клијент партнера суспендован или да ли се упити могу чувати. То су одлуке мрежног пролаза.<х3>Одговорности адаптера<ул><ли>Прикажите манифесте захтева специфичног за провајдера.<ли>Отпремите улазне датотеке или креирајте операције добављача.<ли>Чувајте идентификаторе добављача у метаподацима.<ли>Мапирајте изворни статус у нормализовани статус и извршите излазну слику ><ли>Парлиеве> арт.><ли>Парлиеве> еррор.> резултате на нивоу ставке.<ли>Вратите изворне записе о коришћењу када су доступни.<ли>Површински покушај поново у односу на грешке терминала.<х3>Одговорности мрежног пролаза<ул><ли>Потврдите аутентичност закупца и АПИ кључа.<ли>Примените тим, пројекат и друге контроле за клијенте и обезбедите контроле за кориснике.<али Росолве модел. смерница.<ли>Потврдите групне могућности.<ли>Резервирајте и измирите буџет.<ли>Задржите стање посла и ставке.<ли>Примените политику задржавања.<ли>Откријте аналитику и извоз.<п>Ово одвајање олакшава додавање новог добављача за наплату или десет аналитичких наплата без поновног прегледавања аналитике. управљање.<х2>Уношење резултата идемпотентно<п>Уношење резултата је место где многи системи серије случајно дуплирају трошкове или губе делимичан рад. Третирајте гутање као процес који се понавља. Требало би да буде безбедно да двапут преузмете исту излазну датотеку, двапут обрадите исту операцију добављача или двапут поновите исти веб-хук догађај.<п><стронг>Препорука: користите кључеве идемпотенције на нивоу ставке и ограничења јединствености књиге. Резултат за <цоде>јоб_ид + цустом_ид би требало да се подмири тачно једном, чак и ако се поново покуша унос.<п>Робусни ток убацивања:<ол><ли>Стекните краткотрајно закључавање за задатак или артефакт резултата.<ли>Преузми излаз добављача и артефакте грешке грешке.<ли>Партирај сваки резултат у нормалним догађајима.<ли>Партирај у нормалне догађаје. запис према <цоде>цустом_ид или ИД-у ставке гатеваи-а.<ли>Упишите метаподатке резултата и употребу у трансакцији.<ли>Креирајте догађај поравнања главне књиге само ако он већ не постоји.<ли>Ажурирај бројање послова из стања ставке, а не из претпоставки.<ли>Отпуштање када су све резерве буџета неискоришћене ><п> ><п>Резервације су неискоришћене терминала><п>. веб-хукови су доступни, верификују потписе и штите од понављања. Ако је тражење потребно, користите прилагодљиво анкетирање: анкетирајте често близу очекиваног завршетка, повуците се током дуготрајних периода и зауставите се након терминалног поравнања.<х2>Пробајте поново ставке, а не целе послове<п><стронг>Препорука: покушајте поново на нивоу ставке кад год је то могуће. Поновни покушаји целог посла су једноставни, али повећавају ризик од дуплирања посла и отежавају наплату.<п>Класификујте грешке пре поновног покушаја:<ул><ли><стронг>Грешке при валидацији: обично се завршавају док се захтев не поправи.<ли><стронг>Грешке добављача 5кк: често се могу поново покушати са повратном стопом<ли><стронг>-Клиумит><стронг>ретри витх ретриинг витх ретриинг витх ретриинг. грешке: покушајте поново само након што капацитет буде доступан.<ли><стронг>Сигурносни блокови: немојте слепо поново покушавати; пут до руковања смерницама.<ли><стронг>Ставке које су истекле: могу се поново покушати у новом послу ако закупац и даље жели да посао и буџет дозвољава.<п>Поновни покушај би требало да креира нову ставку повезану са оригиналом:<пре><цоде>{ "итем_ид": "итем_ретри_002", "ретри_оф_итем_ид": "итем_001", "цустом_ид": "тенантА.евал.ров_901.ретри_1" }<п>Немојте поново да шаљете довршене ставке само зато што су биле део посла који је завршио као <цоде>цомплетед_витх_еррорс или <цоде>истекао.<х2>Одлучите шта да складиштите: необрађене резултате, показиваче или хешове<п>Пакетни системи су примамљива места за акумулацију резултата. То може бити корисно за извоз и отклањање грешака, али повећава одговорност за задржавање података.<п><стронг>Препорука: нека смернице за складиштење могу да конфигуришу закупци. За осетљива радна оптерећења, складиштите метаподатке, хешове, употребу и показиваче резултата, а не необрађене упите и излазе.За мање осетљива радна оптерећења, нормализовано складиштење резултата може бити прихватљиво ако су прозори задржавања, контроле приступа и токови рада јасни.<п>Пратите најмање:<ул><ли>Да ли је необрађени унос био ускладиштен.<ли>Да ли је необрађени излаз био ускладиштен.<ли>Где је провајдер уживо ревидирао артефакте резултата ><ли>Про. рок.<ли>Рок за брисање мрежног пролаза.<ли>Хаш захтева и одговора за ревизију без излагања садржаја.<п><стронг>Проверена чињеница: Антропски резултати групе су доступни 29 дана након креирања и изоловани у оквиру радног простора. Ова врста прозора за преузимање специфичног за провајдера треба да се одрази на метаподатке мрежног пролаза и извозе окренуте закупцима.<х2>Изложите аналитику која одговара начину на који тимови раде.<п>Пакетна анализа треба да постоји и на нивоу посла и на нивоу ставке. Власник производа жели да зна да ли је ноћно обогаћивање завршено. Администратор финансија жели трошкове по закупцу, моделу и купцу. Инжењер жели да зна коју класу неуспеха да покуша поново.<п>Корисне метрике обухватају:<ул><ли>Број ставки:<ул><ли>Послати, завршени, неуспели, истекли и отказани.<ли>Процењени у односу на измирени трошак.<ли>Резервисани буџет се и даље држи.<ли>Инпут анд оутпут би тхе Инпут анд Оутпут модел то тхе Инпут анд Оутпут модел то где их провајдери откривају.<ли>Број покушаја и стопа успеха поновних покушаја.<ли>Просечно време у стању чекања, покретања и финализације.<ли>Највеће грешке при валидацији према крајњој тачки и моделу.<ли>Атрибуција клијента партнера.<п>За кориснике АПИ-ја партнера, изложите групне послове као клијенте. То омогућава агенцијама и креаторима СааС-а да понуде офлајн обраду вештачке интелигенције, док истовремено задржавају акредитиве добављача, усаглашавање наплате и руковање ограничењем стопе унутар гејтвеја.<х2>Уступци да се експлицитно учине<п><стронг>Апстракција мрежног пролаза у односу на специфичну способност добављача: али не може да обезбеди сваку функцију, али је не може интегрисати, али је немогућност идентичне. Нека грешке у могућности буду експлицитне.<п><стронг>Резервација буџета у односу на тачност процене: резервација штити станаре од одбеглих послова, али процене могу бити погрешне. Књига мора да подржава прилагођавања, повраћаје средстава и руковање вишком.<п><стронг>Прозивање у односу на веб-хукове: Анкетирање је једноставно и поуздано, али може изгубити АПИ позиве и одложити завршетак. Веб-хукови су бржи, али захтевају верификацију потписа, заштиту од поновног пуштања и надгледање.<п><стронг>Складиштење сирових резултата у односу на минимизирање задржавања: Чување нормализованих резултата побољшава извоз и аналитику, али повећава оптерећење усклађености. Осетљиви закупци могу да преферирају показиваче и хешове.<п><стронг>Велике групе у односу на групе које су подељене у комаде: огромне серије могу да побољшају ефикасност на страни добављача, али мањи делови смањују радијус експлоатације и олакшавају поновне покушаје.<х2>Контролна листа за имплементацију<ул><ли>Креирајте површинске записе за посао пре него што АПИ-је обезбеде задатак<П дајте на површину засебан посао. подношење.<ли>Захтевајте ИД-ове послова мрежног пролаза и прилагођене ИД-ове по ставци.<ли>Нормализујте статусе док складиштите изворне метаподатке добављача.<ли>Направите матрицу могућности за сваки пакетни адаптер добављача.<ли>Потврдите манифесте пре резервисања буџета.<ли>Пре него што нам резервишете стварни буџет.<ли>Резервирајте га на нивоу закупца. гутање.<ли>Учините унос резултата идемпотентним.<ли>Пробајте поново неуспеле ставке селективно, а не наслепо.<ли>Пратите рокове преузимања добављача и политику задржавања мрежног пролаза.<ли>Изложите анализу послова и ставки закупцима и партнерским клијентима.<х где је овај образац: где је овај образац: х. наслов<п><стронг>Предвиђање: групно извршавање ће постати нормалан део инфраструктуре за аутоматизацију вештачке интелигенције, а не само механизам попуста. Како тимови извршавају више процена, задатака чишћења података, прегледа безбедности и цевовода за обогаћивање, они ће очекивати да асинхрони радни оптерећења имају исто управљање као и синхрони АПИ позиви.<п><стронг>Предвиђање: АПИ-ји пакета добављача ће наставити да се разликују на корисне начине. Неки ће се оптимизовати за датотеке, други за дуготрајне операције, а трећи за управљане скупове података или повратне позиве догађаја. Слој адаптера мрежног пролаза ће постати вреднији, а не мање, јер оперативни уговор изнад адаптера може да остане стабилан.<х2>Закључак који се може предузети<п>Немојте причвршћивати групну обраду на АИ АПИ мрежни пролаз као излаз за излаз који је специфичан за провајдера. Изградите га као издржљив подсистем са сопственим записима послова, идентификаторима ставки, статусним моделом, адаптерима добављача, резервацијом буџета, идемпотентним уносом и аналитиком.<п>Најважнији избор дизајна је рачуноводство на нивоу ставке. Када сваки захтев унутар групе има стабилан идентитет, мрежни пролаз може да усклади неуређене резултате, да поново покуша само неуспели рад, наплати само завршен посао добављача и покаже станарима шта се догодило.То је разлика између слања датотека добављачу и рада поузданог АПИ-ја са више модела за асинхрона радна оптерећења.<х2>Повезано читање<ул><ли><а хреф="хттпс://модел-гате.цом/ен/блог/аи-апи-биллинг-ледгер-куоте-ресерве-сеттле-рецонциле-14">ресерве-сеттле-рецонциле-14" образац<ли><а хреф="хттпс://модел-гате.цом/ен/блог/ллм-обсервабилити-мулти-модел-апи-гатеваи-трацес-токен-ледгерс-сафе-промпт-логгинг-9/">аналитика коришћења на нивоу мрежног пролаза и дизајн књиге токена<ли><а хреф="хттпс://модел-гате.цом/ен/блог/цут-ллм-апи-цостс-батцх-јобс-промпт-цацхинг-5/">када радна оптерећења која су толерантна на кашњење одговарају групној обради
FAQ

Често постављана питања

Да ли мрежни пролаз треба директно да изложи пакетне АПИ-је који су изворни добављачу?
Обично не. Излагање изворних АПИ-ја директно даје програмерима приступ функцијама провајдера, али слаби наплату на нивоу закупца, аналитику, поновне покушаје и управљање. Бољи образац је уговор о раду који је неутралан за провајдера са метаподацима специфичним за провајдера који су доступни оператерима.
Зашто је потребан цустом_ид по ставци?
Групни резултати се не могу вратити истим редоследом у ком су достављени. Стабилан идентификатор по ставци омогућава мрежном пролазу да усклади резултате, измири коришћење, поново покуша са неуспелим ставкама и избегне дупле трошкове.
Како треба наплатити поништене или истекле серије?
Рачун само за завршен рад провајдера након што се резултати прогутају и усагласе. Отказани или истекли послови и даље могу да садрже завршене ставке, тако да сам статус на нивоу посла није довољан за тачан обрачун.
Да ли мрежни пролаз треба да чува необрађене упите и излазе из пакетних послова?
Није подразумевано за осетљиве станаре. Чувајте метаподатке, хешеве, употребу и показиваче резултата осим ако закупац изричито не омогући складиштење сирових резултата са јасном политиком задржавања.