Vairāku nomnieku RAG aiz ar OpenAI saderīgas API vārtejas

Klientiem orientētajiem mākslīgā intelekta palīgiem ir nepieciešama izguves paplašināta ģenerēšana, taču RAG kļūst grūtāks, ja pieprasījumi tiek sūtīti caur ar OpenAI saderīgu API vārteju, nevis viena modeļa nodrošinātāja vietējo steku. Vārtejai ir jāuztur nomnieka dati izolēti, jāsaglabā citāti starp modeļu nodrošinātājiem, jādzēš indeksētais saturs pēc grafika un jāpiešķir iegulšanas, izguves un ģenerēšanas izmaksas pareizajam klientam.

Praktiskā atbilde ir uzskatīt, ka izguve ir pirmās klases vārtejas apakšsistēma. Neslēpiet to viena pakalpojumu sniedzēja integrācijā. Atdaliet izguvi no paaudzes, piešķiriet katram pieprasījumam īrnieka tvēruma izguves kontekstu, normalizējiet citātus pirms to atgriešanas un ierakstiet katru apmaksājamo darbību virsgrāmatā.

Lasītāja problēma

Komanda, kas veido mākslīgā intelekta palīgu daudziem klientiem, parasti sākas ar vienkāršu plūsmu: augšupielādējiet dokumentus, ieguliet gabalus, izgūstiet šīs atbildes, vaicājuma atbilstības, ievietojiet modelī šīs atbildes, vaicājuma atbilstības. Tas darbojas, līdz produktam ir nepieciešami vairāki modeļu nodrošinātāji, klienta līmeņa norēķini, pārslēgšana un auditējamība.

Risks ir ne tikai neprecīzas atbildes. Lielāki darbības riski ir nomnieku nosaukumvietas kļūdas, nepārbaudāmi citāti, novecojuši indeksi pēc dokumenta dzēšanas un rezerves, ko nevar izskaidrot, jo izguves izmaksas pazūd vispārīgajos infrastruktūras tēriņos.

Šajā rakstā ir nodalīti fakti, ieteikumi un prognozes. Fakti ir ieviešanas iespējas, ko dokumentē pašreizējie nodrošinātāja un vektoru datu bāzes API. Ieteikumi ir vārtejas produkta arhitektūras izvēles iespējas. Prognozes ir vieta, kur šai arhitektūrai, visticamāk, ir nepieciešama elastība, jo pakalpojumu sniedzēja izguves līdzekļi nepārtraukti mainās.

Atsauces arhitektūra

Vārtejas līmeņa RAG dizainam ir jābūt pieciem komponentiem:

• Īrnieku atrisinātājs: kartē ienākošo API atslēgu, darbvietu, klienta kontu.>Partneriskā API klients var. profils: nosaka, kurā korpusā meklēt, kuru iegulšanas modeli izmantot, rezultātu skaitu, filtrus, pārkārtošanas opcijas, atsauces prasības un atkāpšanās darbības.
• Izguves adaptera slānis: izsauc vietējā nodrošinātāja izguvi, ārēju vektoru datu bāzi vai pielāgotu meklēšanas pakalpojumu, izmantojot vienu iekšējo interfeisu, izsauc adaptera ģenerēšanu bez konteksta modeļa.
• Uzvedne: zvanītājiem atklāj vektora aizmugursistēmas informāciju.
• Lietošanas un audita virsgrāmata: reģistrē iegulšanu, indeksēšanu, izguvi, uzvednes pilnvaras, pabeigšanas pilnvaras, nomnieku, modeļa, nodrošinātāja un izsekošanas identifikatorus.

Minimālais pieprasījuma līgums var palikt neatkarīgi no pakalpojumu sniedzēja.

< kods.
  "īrnieka_id": "īrnieks_123",
  "modelis": "gpt-compatible-or-claude-compatible-modelis",
  "retrieval_profile": "support_docs_v2",
  "citation_required": patiess,
  "Ziņojumi": [
    {"role": "user", "content": "Kāda ir mūsu atmaksas politika gada plāniem?"}
  ]
}

Atbildei ir jābūt arī neitrālai no pakalpojumu sniedzēja:

{
  "atbilde": "Atmaksa par gada plāniem var tikt veikta konfigurētajā politikas logā...",
  "citāts": [
    {
      "source_id": "doc_789",
      "title": "Norēķinu politika",
      "url_or_internal_ref": "kb://billing-policy",
      "chunk_id": "chunk_044",
      "offsets": {"lapa": 3},
      "rezultāts": 0,82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_contact",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "billable_tenant": "īrnieks_123",
  "embedding_usage": null,
  "retrieval_usage": {"queries": 1, "results": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}}

Fakts: nodrošinātāja izguves līdzekļi nav identiski

OpenAI vektoru veikalu API atbalsta vektoru krātuves, kuras var izveidot, meklēt, konfigurēt ar sadalīšanas stratēģijām, saistīt ar faila metadatiem un dzēst. Vektoru veikala meklēšana atbalsta vaicājumus, filtrus, maksimālo rezultātu skaitu, ranžēšanas opcijas, punktu sliekšņus un vaicājumu pārrakstīšanas vadīklas. Šīs vadīklas sniedz vārtejas autoriem noderīgas pogas latentuma, atbilstības un izmaksu noteikšanai.

OpenAI platformas datu vadīklas arī padara dzīves cikla dizainu svarīgu: klientu saturs vektoru veikalos tiek saglabāts līdz dzēšanai. Ja nomnieks atkāpjas no borta vai ja beidzas pagaidu projekta termiņš, vārteja nevar pieņemt, ka nodrošinātājs automātiski noņems indeksēto saturu produkta biznesa grafikā.

Anthropic parāda citu citātu modeli. Lietojumprogrammas var nodrošināt meklēšanas rezultātu satura blokus ar avota un nosaukuma metadatiem, un, ja ir iespējoti citāti, modelis var pievienot atsauces uz atsaucēm ģenerētajam tekstam. Pastāv praktiski ierobežojumi: meklēšanas rezultātu citēšanas iestatījumi pieprasījumā ir “viss vai nekas”, meklēšanas rezultātu bloki atbalsta teksta saturu, un citātu precizitāte ir atkarīga no tā, kā saturs ir sadalīts blokos.

Ietekme ir tieša: vārteja nedrīkst atklāt viena pakalpojumu sniedzēja izguves formu kā savu publisko līgumu, ja vien tā nav paredzējusi šo pakalpojumu sniedzēju izmantot kā pastāvīgu izguves iestādi.

Izguves adapteri, nevis izguves bloķēšana

Izveidojiet iekšējo izguves adaptera saskarni. Vārteja var atbalstīt vairākas aizmugursistēmas:

• Vietējā nodrošinātāja izguve: noderīga, ja klients vēlas visātrāko ceļu uz viena pakalpojumu sniedzēja failu meklēšanas vai vektoru krātuves funkcijām.
• Ārējā vektoru datubāze: noderīga, ja produktam ir jāatbalsta daudzi modeļu nodrošinātāji ar konsekventu nomnieka izolāciju un dzīves cikla noderīgu meklēšanas rezultātuiepriekšēji kad vārteja apkopo izgūto tekstu un nodod to pakalpojumu sniedzējam, kas atbalsta nepārprotamu atsauces kontekstu.

Adapterim ir jāatgriež viena un tā pati iekšējā struktūra neatkarīgi no aizmugursistēmas:

interfeiss RetrievalResult {
  retrievalTraceId: virkne;
  rentantId: virkne;
  corpusId: virkne;
  gabali: masīvs<{
    avota ID: virkne;
    nosaukums: virkne;
    teksts: virkne;
    urlOrInternalRef?: virkne;
    chunkId: virkne;
    nobīdes?: { lapa?: numurs; baitsStart?: numurs; byteEnd?: numurs; tokenStart?: numurs; tokenEnd?: numurs };
    rezultāts?: skaitlis;
    metadati: ieraksts;
    providerPayload?: nezināms;
  }>;
  retrievalUsage: {
    sniedzējs: string;
    queryCount: numurs;
    resultCount: skaitlis;
    apmaksājamās vienības?: numurs;
  };}

Tas ļauj ģenerēšanas slānim saņemt kontekstu, nezinot, vai tas nāk no OpenAI vektoru veikaliem, Pinecone, Weaviate, datu bāzes pilna teksta meklēšanas indeksa vai iekšēja hibrīda retrīvera.

Īrnieka izolācija sākas pirms vektora vaicājuma

Īrnieka izolācija nedrīkst būt atkarīga no tūlītējiem norādījumiem. Tas ir jāīsteno pirms izguves pie krātuves robežas un vaicājuma robežas.

Pinecone stila sistēmām dokumentētais vairāku īrēju modelis ir viena nosaukumvieta katram nomniekam bezserveru indeksos. Datu plaknes operācijas ir vērstas uz nosaukumvietu, kas vienkāršo nomnieka izolāciju un izslēgšanu, jo, dzēšot nosaukumvietu, tiek noņemti šī nomnieka ieraksti. Pinecone arī dokumentē kompromisus starp nosaukumvietām un metadatu filtrēšanu: filtrēšana lielā koplietojamā nosaukumvietā var skenēt vairāk datu, maksāt vairāk un veikt lēnāk nekā nosaukumvietas vaicājumi.

Weaviate stila sistēmās vairāku īrnieku katrs nomnieks tiek glabāts atsevišķā fragmentā, tāpēc viena nomnieka dati nav redzami citam nomniekam. Dzēšot īrnieku, tiek dzēsts saistītais fragments. Weaviate atbalsta arī tādus nomnieku stāvokļus kā aktīvs, neaktīvs un atslogots, kas izveido dzīves cikla opciju reti izmantotiem nomniekiem.

Ieviešanas kontrolsaraksts

• Atrisiniet rentant_id no autentificētās vārtejas identitātes, nevis tikai no lietotāja nodrošināta pamatlauka.
• Kartes vector name_id, vector name_id vai hard rentant_id. identifikators, izmantojot servera puses reģistru.
• Noraidīt pieprasījumus, kuros API atslēgas nomnieks un pieprasītais korpusa nomnieks nesakrīt.
• Saglabājiet koplietojamos publiskos korpusus atsevišķi no privātajiem nomnieku korpusiem.
• Izmantojiet metadatu filtrēšanu dokumenta veidam, valodai, produktu apgabalam vai datumu diapazonam pēc tam, kad jau ir atlasīta nomnieka robeža, corpus_idogl,hardli>. retrieval_profile un retrieval_trace_id, lai nodrošinātu auditējamību.

Rezervējiet starpnomnieku meklēšanu precīzām administratīvajām darbplūsmām ar atsevišķu atļauju, atsevišķiem indeksiem vai kontrolētiem apkopošanas ceļiem. Nepadariet starpnomnieku meklēšanu par nejaušu metadatu filtru blakusefektu.

Normalizējiet citātus kā vārtejas objektus

Citati ir produkta līgums, nevis tikai dekorācija. Klientu atbalsta asistentam, juridisko dokumentu izstrādes rīkam vai iekšējam zināšanu asistentam ir jāparāda, kāpēc tika sniegta atbilde un no kurienes nāk atbalsta teksts.

Vārtejai ir jānormalizē citātu dati savā shēmā:

{
  "source_id": "doc_123",
  "title": "Atmaksas noteikumi",
  "url_or_internal_ref": "kb://refund-terms",
  "chunk_id": "chunk_006",
  "offsets": {"lapa": 2, "byte_start": 4410, "byte_end": 5020},
  "rezultāts": 0,79,
  "retrieval_provider": "weaviate",
  "model_provider": "antropisks",
  "model_provider_citation_payload": {}
}

Saglabājiet normalizētos laukus stabilus un atļaujiet pakalpojumu sniedzējam raksturīgus paplašinājumus. Daži pakalpojumu sniedzēji atklās plašāku informāciju par citātu nekā citi. Daži atsaucas uz meklēšanas rezultātu blokiem. Daži citēs augšupielādētos failus. Daži no tiem nenodrošina precīzu nobīdes formātu, kādu vēlas jūsu lietojumprogramma. Vārtejai ir jāsaglabā tas, kas pastāv, neizliekoties, ka katram pakalpojumu sniedzējam ir identiska citēšanas semantika.

Stingrais citēšanas režīms

Ja parametrs citation_required ir patiess, definējiet kļūmes darbību jau iepriekš. Stingrā režīmā var būt nepieciešams, lai katrā faktiskajā rindkopā būtu jāiekļauj vismaz viens citāts vai gala atbildē jāiekļauj citāti no izgūtajām daļām, kas pārsniedz minimālo punktu skaitu. Ja izvēlētais modeļa nodrošinātājs nevar izpildīt citēšanas līgumu, vārtejai vajadzētu ātri nedarboties, izmantot saderīgu pakalpojumu sniedzēju vai nosūtīt strukturētu atteikumu.

Šis ir ieteikums, nevis universāls noteikums. Stingras citēšanas režīms uzlabo uzticēšanos, taču tas var palielināt atteikumu, atkārtotu mēģinājumu un atkāpšanās sarežģītību. Zema riska radošajām darbplūsmām citāti var būt neobligāti. Klientu atbalstam vai regulētām iekšējām darbplūsmām izguves profilā bieži ir jāiekļauj atsauce_required.

Indeksa dzīves cikls ir produkta funkcija

RAG sistēmas uzkrāj datus. Pagaidu augšupielādes kļūst pastāvīgas nejauši. Bijušie klienti atstāj aiz sevis iegulšanu. Produktu komandas maina sadalīšanas stratēģijas un aizmirst atjaunot vecos indeksus.Vārtejai ir skaidri jānorāda dzīves cikla vadīklas.

Ieteicamās dzīves cikla vadīklas ietver:

• pagaidu korpusa derīguma termiņa beigas: dokumentiem, kas augšupielādēti īslaicīgai sesijai, ir jābūt derīguma termiņa zīmogam un dzēšanas uzdevumam.
• Nomnieka izslēgšanas nosaukumam šķembas, nodrošinātāja vektoru krātuves un saistītie failu objekti.
• Aukstā nomnieka apstrāde: ja tiek atbalstīta, neaktīvos nomniekus var atzīmēt kā neaktīvus vai atslogot, lai samazinātu resursu izmantošanu.
• Versiju kontroles atkārtota indeksēšana: uzglabājiet iegulšanas modeli, sadalīšanas politiku, parsētāja versiju un katra partnera statusa indexed_at. API darbplūsmās jāparāda, vai dokumenta dzēšana, vektoru dzēšana un nodrošinātāja puses dzēšana ir pabeigta.

Svarīgi ir tas, ka daļa vektoru krātuves satura tiek saglabāta līdz dzēšanai. Arhitektūras ieteikums ir padarīt dzēšanu redzamu un pārbaudāmu, nevis ievietot to asinhronā darbā bez klienta statusa.

Izsekojiet trīs izmaksu virsgrāmatas

RAG nepietiek ar vienu marķiera virsgrāmatu. Vārtejai ir nepieciešamas vismaz trīs virsgrāmatas:

• Iegulšanas un indeksēšanas izmaksas: dokumentu parsēšana, sadalīšana, izsaukumu iegulšana, failu glabāšana, indeksa rakstīšana un atkārtota indeksēšana.
• Izguves izmaksas: vektoru datu bāzes nolasīšana, vietējā vektoru veikala meklēšana, vaicājuma rezultātu pārkārtošana, paplašināšana.
• Izveides izmaksas: ievadiet marķierus no lietotāju ziņojumiem un izgūtā konteksta, izvades marķierus, rīku izsaukumus, atkārtotus mēģinājumus un atkāpšanās gadījumus.

Tas ir īpaši svarīgi aģentūrām, SaaS piegādātājiem un iekšējām platformu komandām, kas tālāk pārdod vai piešķir AI izmaksas. Bez atsevišķām virsgrāmatām RAG starpības kļūst grūti izskaidrojamas. Īrnieks, kura lietojums ir mazs, joprojām var būt dārgs, ja tas pastāvīgi augšupielādē dokumentus, atkārtoti indeksē lielus korpusus vai izpilda plašus izguves vaicājumus.

Katrā virsgrāmatas notikumā ir jāiekļauj rentant_id, customer_id, ja tas atšķiras, API atslēgas ID, izguves_profils, korpusa_id, modelis, nodrošinātājs, izsekošanas_id un apmaksājamās vienības. Tas ļauj lietošanas analītikai atbildēt uz praktiskiem jautājumiem: kuriem nomniekiem ir dārgi izguves profili, kuri korpusi ir novecojuši, kuri modeļi rada citēšanas kļūmes un kuri klienti ģenerē pārāk lielas uzvednes, jo izguve atgriež pārāk daudz konteksta.

Pārbaudāmie kļūmju režīmi

Vārtejas RAG apakšsistēmai ir jāizveido tādi testi, kas ir redzami klientu kļūmēm. Bojājumi:

• Trūkst citātu: citation_required ir patiess, bet sniedzēja atbildē nav izmantojamu atsauces uz citātu.
• Novecojuši indeksi: dokuments tika atjaunināts vai dzēsts, bet izguves rezultātos joprojām tiek rādīti veci fragmenti.
• Nomnieka nosaukums vai neatbilstība tiek atrisināts, kamēr īrnieka nosaukums neatbilst: īrniekam B.
• Pārmērīga izguve: profils atgriež pārāk daudz fragmentu, palielinot izmaksas un pasliktinot atbilžu kvalitāti.
• Daļu lieluma neatbilstība: fragmenti ir tik lieli, ka citāti ir neprecīzi vai tik mazi, ka konteksts zaudē nozīmi.
• Cita funkcija var neatbilst citam modelim: Provider. nevar.
• Dzīves cikla kļūme: tiek pieprasīta dzēšana, taču pakalpojumu sniedzēja puses krātuve paliek aktīva vai nav pārbaudīta.

Šīs pārbaudes jāveic vārtejas līguma līmenī, nevis tikai vienā nodrošinātāja adapterī. Mērķis ir pierādīt, ka publiskā darbība paliek stabila, mainoties izguves aizmugursistēmai vai paaudzes nodrošinātājam.

Izmaiņas

Vietējā nodrošinātāja izguve var samazināt lietojumprogrammas kodu un paātrināt pirmās versijas izveidi. Kompromiss ir tāds, ka krātuves dzīves cikls, citēšanas formāts, vaicājumu vadīklas un līdzekļu pieejamība var tikt piesaistīti vienam pakalpojumu sniedzējam.

Ārējās vektoru datu bāzes palielina darbības laukumu. Ieguvums ir lielāka pārnesamība ar OpenAI saderīgajiem modeļiem, antropiskajiem modeļiem un turpmākajiem pakalpojumu sniedzējiem. Tie arī atvieglo nomnieka tvēruma nosaukumvietas vai fragmentus, lai saprastu, kad vārteja ir atbildīga par norēķiniem un izslēgšanu.

Smalki fragmenti uzlabo citēšanas precizitāti un pārbaudāmību. Tie arī palielina indeksa lielumu, izguves apjomu un ātru montāžas sarežģītību. Rupjie fragmenti ir vienkāršāki, taču tie var radīt citātus, kas norāda uz plašu lapu vai sadaļu, nevis uz precīzu atbalsta fragmentu.

Režīms, kurā tiek prasīta stingra atsauce, uzlabo lietotāju uzticēšanos.Tas arī liek vārtejai apstrādāt modeļus, kas nevar izveidot nepieciešamo citātu formātu, kas var nozīmēt pieprasījuma noraidīšanu, modeļu maiņu vai atbildes atgriešanu ar zemāku uzticamības stāvokli.

Prognoze: izguve kļūs nopietnāka, taču vārtejām joprojām ir nepieciešams savs līgums

Pakalpojumu sniedzēja vietējās izguves funkcijas, visticamāk, kļūs spējīgākas. Vairāk modeļu pieņems izgūto kontekstu ar strukturētiem avota metadatiem. Vairāk API atklās ranžēšanas vadīklas, vaicājumu pārrakstīšanu un citēšanas iestatījumus. Tas nenovērš nepieciešamību pēc vārtejas līguma.

Vārtejai joprojām pieder nomnieka identitāte, atslēgu pārvaldība, tēriņu ierobežojumi, lietojuma analīze, partneru API darbplūsmas un klientam paredzēti dzēšanas solījumi. Pakalpojumu sniedzēja funkcijas var izmantot aiz adaptera slāņa, taču produktam nevajadzētu piespiest katru nomnieku, modeli un norēķinu darbplūsmu viena pakalpojumu sniedzēja izguves abstrakcijā.

Rīcāms secinājums

Izveidojiet vairāku nomnieku RAG kā vārtejas apakšsistēmu ar skaidrām robežām. Pirms izguves noskaidrojiet īrnieka identitāti. Izmantojiet nomnieka tvēruma nosaukumvietas, fragmentus vai vektoru veikalus. Saglabājiet izguvi aiz adapteriem. Normalizējiet citātus vārtejai piederošā shēmā. Pievienojiet dzīves cikla stāvokļus un dzēšanas verifikāciju. Atsevišķi izsekojiet iegulšanas, izguves un ģenerēšanas izmaksas.

Šī arhitektūra nodrošina RAG zemējumu, neslēdzot produktu vienam izguves nodrošinātājam. Tas arī nodrošina komandām nepieciešamās darbības vadīklas, kad AI palīgs pāriet no prototipa uz klientu vērstu sistēmu: izolācija, atsauces, pārnesamība, dzīves cikla pārvaldība un izmaksu attiecināšana.

Saistīta informācija

• izsekojumu izgūšana, marķieru izmantošana un nomnieka analīze vienā novērojamības modelī
• normalizējiet pakalpojumu sniedzējam specifiskas izvades, izmantojot stabilu vārtejas līgumu
• savienojiet nomnieka nodrošināšanu un lietojuma mērīšanu ar partneru API darbplūsmām