Multi-Tenant RAG Πίσω από μια πύλη API συμβατής με OpenAI

Οι βοηθοί τεχνητής νοημοσύνης που αντιμετωπίζουν οι πελάτες χρειάζονται επαυξημένη δημιουργία ανάκτησης, αλλά το RAG γίνεται πιο δύσκολο όταν τα αιτήματα ρέουν μέσω μιας πύλης API συμβατής με OpenAI αντί της εγγενούς στοίβας ενός παρόχου μοντέλου. Η πύλη πρέπει να διατηρεί απομονωμένα τα δεδομένα των ενοικιαστών, να διατηρεί τις παραπομπές σε όλους τους παρόχους μοντέλων, να διαγράφει περιεχόμενο με ευρετήριο βάσει χρονοδιαγράμματος και να αποδίδει το κόστος ενσωμάτωσης, ανάκτησης και παραγωγής στον σωστό πελάτη.

Η πρακτική απάντηση είναι να αντιμετωπίζεται η ανάκτηση ως υποσύστημα πύλης πρώτης κατηγορίας. Μην το κρύβετε μέσα στην ενσωμάτωση ενός παρόχου. Διατηρήστε την ανάκτηση ξεχωριστή από τη γενιά, δώστε σε κάθε αίτημα ένα πλαίσιο ανάκτησης με εύρος ενοικιαστή, κανονικοποιήστε τις παραπομπές πριν τις επιστρέψετε και καταγράψτε κάθε χρεώσιμο βήμα σε ένα βιβλίο.

Το πρόβλημα του αναγνώστη

Μια ομάδα που δημιουργεί έναν βοηθό τεχνητής νοημοσύνης για πολλούς πελάτες συνήθως ξεκινά με μια απλή ροή: ανεβάστε έγγραφα, ενσωματώστε αυτά τα κομμάτια σε κορυφές, ενσωματώστε τα κομμάτια στις κορυφές, τεμάχια. προτροπή και ζητήστε από ένα μοντέλο να απαντήσει. Αυτό λειτουργεί έως ότου το προϊόν χρειάζεται πολλούς παρόχους μοντέλων, χρέωση σε επίπεδο πελάτη, offboarding και δυνατότητα ελέγχου.

Ο κίνδυνος δεν είναι μόνο οι ανακριβείς απαντήσεις. Οι μεγαλύτεροι λειτουργικοί κίνδυνοι είναι λάθη χώρου ονομάτων μισθωτών, μη επαληθεύσιμες παραπομπές, μπαγιάτικα ευρετήρια μετά τη διαγραφή του εγγράφου και περιθώρια που δεν μπορούν να εξηγηθούν επειδή το κόστος ανάκτησης εξαφανίζεται στις γενικές δαπάνες υποδομής.

Αυτό το άρθρο διαχωρίζει γεγονότα, προτάσεις και προβλέψεις. Τα γεγονότα είναι δυνατότητες υλοποίησης που τεκμηριώνονται από τα τρέχοντα API βάσεων δεδομένων παρόχου και διανυσμάτων. Οι προτάσεις είναι επιλογές αρχιτεκτονικής για ένα προϊόν πύλης. Οι προβλέψεις είναι όπου αυτή η αρχιτεκτονική είναι πιθανό να χρειάζεται ευελιξία, καθώς τα χαρακτηριστικά ανάκτησης παρόχου συνεχίζουν να αλλάζουν.

Αρχιτεκτονική αναφοράς

Ένα σχέδιο RAG σε επίπεδο πύλης θα πρέπει να περιλαμβάνει πέντε στοιχεία:

• Επιλύτης μισθωτή: αντιστοιχίζει το εισερχόμενο κλειδί API, τον χώρο εργασίας, τον λογαριασμό canonical πελάτη ή ένα τμήμα tenant_id.
• Προφίλ ανάκτησης: καθορίζει ποιο σώμα θα αναζητηθεί, ποιο μοντέλο ενσωμάτωσης θα χρησιμοποιηθεί, πλήθος αποτελεσμάτων, φίλτρα, επιλογές ανακατάταξης, απαιτήσεις παραπομπών και εναλλακτική συμπεριφορά.
• Επίπεδο προσαρμογέα ανάκτησης: καλεί την ανάκτηση εγγενούς παρόχου, μια εξωτερική βάση δεδομένων διανυσματικής αναζήτησης και μια προσαρμοσμένη διασύνδεση υπηρεσίας assembly Promoblit ή μια προσαρμοσμένη διεπαφή. προσαρμογέας γενιάς: μεταβιβάζει το ανακτηθέν πλαίσιο στον επιλεγμένο πάροχο μοντέλου χωρίς να εκθέτει τα διανυσματικά στοιχεία υποστήριξης στους καλούντες.
• Λογιστικό χρήσης και ελέγχου: καταγράφει την ενσωμάτωση, την ευρετηρίαση, την ανάκτηση, τα διακριτικά προτροπής, τα διακριτικά ολοκλήρωσης, τον μισθωτή, το μοντέλο, τον πάροχο και το ελάχιστο αίτημα για την παραμονή του συμβολαίου

  {
    "tenant_id": "tenant_123",
    "model": "gpt-compatible-or-claude-compatible-model",
    "retrieval_profile": "support_docs_v2",
    "citation_required": true,
    "μηνύματα": [
      {"role": "user", "content": "Ποια είναι η πολιτική επιστροφής χρημάτων μας για ετήσια προγράμματα;"}
    ]
  }

  Η απάντηση θα πρέπει επίσης να είναι ουδέτερη ως προς τον πάροχο:

  {
    "answer": "Τα ετήσια προγράμματα μπορούν να επιστραφούν εντός του διαμορφωμένου παραθύρου πολιτικής...",
    "παραπομπές": [
      {
        "source_id": "doc_789",
        "title": "Πολιτική χρέωσης",
        "url_or_internal_ref": "kb://billing-policy",
        "chunk_id": "chunk_044",
        "offsets": {"σελίδα": 3},
        "σκορ": 0,82,
        "retrieval_provider": "vector_db",
        "model_provider": "openai_compatible",
        "provider_payload": {}
      }
    ],
    "retrieval_trace_id": "rt_456",
    "billable_tenant": "tenant_123",
    "embedding_usage": null,
    "retrieval_usage": {"queries": 1, "results": 6},
    "model_usage": {"input_tokens": 1920, "output_tokens": 180}}

  Γεγονός: Οι δυνατότητες ανάκτησης παρόχου δεν είναι πανομοιότυπες

  Το Vector Stores API του OpenAI υποστηρίζει διανυσματικά καταστήματα που μπορούν να δημιουργηθούν, να αναζητηθούν, να διαμορφωθούν με στρατηγικές τμηματοποίησης, να συσχετιστούν με μεταδεδομένα αρχείων και να διαγραφούν. Η αναζήτηση του διανυσματικού καταστήματος υποστηρίζει ερωτήματα, φίλτρα, μέγιστο πλήθος αποτελεσμάτων, επιλογές κατάταξης, όρια βαθμολογίας και στοιχεία ελέγχου επανεγγραφής ερωτημάτων. Αυτά τα στοιχεία ελέγχου δίνουν στους συντάκτες της πύλης χρήσιμα κουμπιά για καθυστέρηση, συνάφεια και κόστος.

  Οι έλεγχοι δεδομένων πλατφόρμας OpenAI καθιστούν επίσης σημαντικό τον σχεδιασμό του κύκλου ζωής: το περιεχόμενο των πελατών στα διανυσματικά καταστήματα διατηρείται μέχρι να διαγραφεί. Εάν ένας μισθωτής απομακρυνθεί ή εάν λήξει ένα προσωρινό έργο, η πύλη δεν μπορεί να υποθέσει ότι ο πάροχος θα αφαιρέσει αυτόματα το ευρετηριασμένο περιεχόμενο στο επιχειρηματικό πρόγραμμα του προϊόντος.

  Το Anthropic εκθέτει διαφορετικό μοτίβο για τις αναφορές. Οι εφαρμογές μπορούν να παρέχουν μπλοκ περιεχομένου αποτελεσμάτων αναζήτησης με μεταδεδομένα πηγής και τίτλου και όταν είναι ενεργοποιημένες οι αναφορές, το μοντέλο μπορεί να επισυνάψει αναφορές παραπομπών στο κείμενο που δημιουργείται. Υπάρχουν πρακτικοί περιορισμοί: οι ρυθμίσεις παραπομπών αποτελεσμάτων αναζήτησης είναι όλα ή τίποτα μέσα σε ένα αίτημα, τα μπλοκ αποτελεσμάτων αναζήτησης υποστηρίζουν περιεχόμενο κειμένου και η ευκρίνεια των παραπομπών εξαρτάται από τον τρόπο με τον οποίο το περιεχόμενο χωρίζεται σε μπλοκ.

  Η συνέπεια είναι άμεση: μια πύλη δεν πρέπει να εκθέτει το σχήμα ανάκτησης ενός παρόχου ως δημόσια σύμβαση, εκτός εάν σκοπεύει να το επαναφέρει σε μόνιμη αρχή

  Χρήση προσαρμογέων ανάκτησης, όχι κλειδώματος ανάκτησης

  Δημιουργήστε μια εσωτερική διεπαφή προσαρμογέα ανάκτησης. Η πύλη μπορεί να υποστηρίξει πολλά backend πίσω από αυτήν:

  • Ανάκτηση εγγενούς παρόχου: χρήσιμη όταν ένας πελάτης θέλει την ταχύτερη διαδρομή προς την αναζήτηση αρχείων ενός παρόχου ή δυνατότητες αποθήκευσης διανυσμάτων.
  • Εξωτερική διανυσματική βάση δεδομένων: χρήσιμο όταν το προϊόν πρέπει να υποστηρίζει πολλούς παρόχους μοντέλων με συνεπή απομόνωση μισθωτήlifecyclelitch. μπλοκ: χρήσιμο όταν η πύλη συναρμολογεί το ανακτηθέν κείμενο και το μεταβιβάζει σε έναν πάροχο που υποστηρίζει ρητό περιβάλλον με επίγνωση παραπομπών.

  Ο προσαρμογέας θα πρέπει να επιστρέψει την ίδια εσωτερική δομή ανεξάρτητα από το backend:

  interface RetrievalResult {
    retrievalTraceId: συμβολοσειρά;
    tenantId: συμβολοσειρά;
    corpusId: συμβολοσειρά;
    κομμάτια: Πίνακας<{
      sourceId: συμβολοσειρά;
      τίτλος: συμβολοσειρά;
      κείμενο: συμβολοσειρά;
      urlOrInternalRef?: συμβολοσειρά;
      chunkId: συμβολοσειρά;
      μετατοπίσεις;: { σελίδα;: αριθμός; byteStart?: αριθμός; byteEnd?: αριθμός; tokenStart?: αριθμός; tokenEnd?: αριθμός };
      σκορ;: αριθμός;
      μεταδεδομένα: Record;
      providerPayload?: άγνωστο;
    }>;
    retrievalUsage: {
      πάροχος: συμβολοσειρά;
      queryCount: αριθμός;
      resultCount: αριθμός;
      Billable Units?: αριθμός;
    };}

  Αυτό επιτρέπει στο επίπεδο δημιουργίας να λαμβάνει πλαίσιο χωρίς να γνωρίζει εάν προέρχεται από καταστήματα OpenAI vector, Pinecone, Weaviate, ευρετήριο αναζήτησης πλήρους κειμένου βάσης δεδομένων ή εσωτερικό υβριδικό retriever.

  Η απομόνωση ενοικιαστή ξεκινά πριν από το Vector Query

  Οι οδηγίες απομόνωσης του Prompt Tenant δεν πρέπει να εξαρτώνται από. Πρέπει να επιβληθεί πριν από την ανάκτηση, στο όριο αποθήκευσης και στο όριο ερωτήματος.

  Για συστήματα τύπου Pinecone, το τεκμηριωμένο μοτίβο πολυμίσθωσης είναι ένας χώρος ονομάτων ανά μισθωτή σε ευρετήρια χωρίς διακομιστή. Οι λειτουργίες επιπέδου δεδομένων στοχεύουν έναν χώρο ονομάτων, ο οποίος απλοποιεί την απομόνωση και την αποβίβαση ενοικιαστή, επειδή η διαγραφή του χώρου ονομάτων καταργεί τις εγγραφές αυτού του ενοικιαστή. Το Pinecone τεκμηριώνει επίσης ανταλλαγές μεταξύ χώρων ονομάτων και φιλτραρίσματος μεταδεδομένων: το φιλτράρισμα μέσα σε έναν μεγάλο κοινόχρηστο χώρο ονομάτων μπορεί να σαρώσει περισσότερα δεδομένα, να κοστίσει περισσότερο και να αποδώσει πιο αργά από τα ερωτήματα με εύρος ονομάτων.

  Για συστήματα τύπου Weaviate, η πολλαπλή ενοικίαση αποθηκεύει κάθε ενοικιαστή σε ξεχωριστό θραύσμα, επομένως τα δεδομένα ενός ενοικιαστή δεν είναι ορατά στον άλλο. Η διαγραφή ενοικιαστή διαγράφει το συσχετισμένο θραύσμα. Το Weaviate υποστηρίζει επίσης καταστάσεις μισθωτή, όπως ενεργές, ανενεργές και εκφορτωμένες, γεγονός που δημιουργεί μια επιλογή κύκλου ζωής για σπάνια χρησιμοποιούμενους ενοικιαστές.

  Λίστα ελέγχου εφαρμογής

  • Επιλύστε το tenant_id από την ταυτότητα της ελεγμένης πύλης, όχι μόνο από ένα πεδίο σώματος που παρέχεται από τον χρήστη μόνο. Αποθηκεύστε το αναγνωριστικό μέσω ενός μητρώου στην πλευρά του διακομιστή.
  • Απορρίψτε αιτήματα όπου ο μισθωτής κλειδιού API και ο μισθωτής που ζητήθηκε δεν ταιριάζουν.
  • Διατηρήστε τα κοινόχρηστα δημόσια σώματα ξεχωριστά από τα ιδιωτικά σώματα ενοικιαστή.
  • Χρησιμοποιήστε το φιλτράρισμα μεταδεδομένων για τον τύπο εγγράφου, τη γλώσσα, την περιοχή προϊόντος ή το εύρος ημερομηνιών, αφού έχει ήδη επιλεγεί το δεσμευμένο όνομα ενοικιαστή
  • . corpus_id, retrieval_profile και retrieval_trace_id για δυνατότητα ελέγχου.

  Διατηρήστε την αναζήτηση μεταξύ μισθωτών για ρητές διοικητικές ροές εργασίας με ξεχωριστή εξουσιοδότηση, ξεχωριστά ευρετήρια ή ελεγχόμενες διαδρομές συγκέντρωσης. Μην κάνετε την αναζήτηση μεταξύ ενοικιαστών ως τυχαία παρενέργεια των φίλτρων μεταδεδομένων.

  Κανονοποίηση Αναφορών ως Αντικείμενα Πύλης

  Οι παραπομπές είναι σύμβαση προϊόντος και όχι απλώς διακόσμηση. Ένας βοηθός υποστήριξης πελατών, ένα εργαλείο νομικής σύνταξης ή ένας εσωτερικός βοηθός γνώσεων πρέπει να δείξει γιατί δημιουργήθηκε μια απάντηση και από πού προήλθε το υποστηρικτικό κείμενο.

  Η πύλη θα πρέπει να κανονικοποιεί τα δεδομένα παραπομπών στο δικό της σχήμα:

  {
    "source_id": "doc_123",
    "title": "Όροι επιστροφής χρημάτων",
    "url_or_internal_ref": "kb://refund-terms",
    "chunk_id": "chunk_006",
    "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
    "σκορ": 0,79,
    "retrieval_provider": "weaviate",
    "model_provider": "anthropic",
    "model_provider_citation_payload": {}
  }

  Διατηρήστε σταθερά τα κανονικοποιημένα πεδία και επιτρέψτε επεκτάσεις για συγκεκριμένους παρόχους. Ορισμένοι πάροχοι θα εκθέσουν πλουσιότερες λεπτομέρειες αναφορών από άλλους. Ορισμένοι θα αναφέρουν μπλοκ αποτελεσμάτων αναζήτησης. Ορισμένοι θα αναφέρουν τα μεταφορτωμένα αρχεία. Ορισμένοι δεν θα παρέχουν την ακριβή μορφή μετατόπισης που θέλει η εφαρμογή σας. Η πύλη θα πρέπει να διατηρεί αυτό που υπάρχει χωρίς να προσποιείται ότι κάθε πάροχος έχει πανομοιότυπη σημασιολογία παραπομπών.

  Λειτουργία αυστηρής αναφοράς

  Όταν το citation_required είναι αληθές, ορίστε τη συμπεριφορά αποτυχίας εκ των προτέρων. Ένας αυστηρός τρόπος λειτουργίας μπορεί να απαιτεί κάθε τεκμηριωμένη παράγραφος να περιλαμβάνει τουλάχιστον μία παραπομπή ή η τελική απάντηση να περιέχει παραπομπές από ανακτημένα κομμάτια πάνω από ένα ελάχιστο όριο βαθμολογίας. Εάν ο επιλεγμένος πάροχος μοντέλου δεν μπορεί να ικανοποιήσει τη σύμβαση παραπομπής, η πύλη θα πρέπει να αποτύχει γρήγορα, να χρησιμοποιήσει έναν συμβατό πάροχο ή να επιστρέψει μια δομημένη άρνηση.

  Αυτή είναι μια σύσταση και όχι ένας καθολικός κανόνας. Η λειτουργία αυστηρής αναφοράς βελτιώνει την εμπιστοσύνη, αλλά μπορεί να αυξήσει τις αρνήσεις, τις επαναλήψεις και την εναλλακτική πολυπλοκότητα. Για ροές δημιουργικών χαμηλού κινδύνου, οι αναφορές μπορεί να είναι προαιρετικές. Για υποστήριξη από πελάτες ή ρυθμιζόμενες εσωτερικές ροές εργασίας, το citation_required θα πρέπει συχνά να αποτελεί μέρος του προφίλ ανάκτησης.

  Ο κύκλος ζωής του ευρετηρίου είναι χαρακτηριστικό προϊόντος

  Τα συστήματα RAG συγκεντρώνουν δεδομένα. Οι προσωρινές μεταφορτώσεις γίνονται μόνιμες κατά λάθος. Οι πρώην πελάτες αφήνουν πίσω τους ενσωματώσεις. Οι ομάδες προϊόντων αλλάζουν στρατηγικές τμηματοποίησης και ξεχνούν να ξαναφτιάξουν παλιά ευρετήρια.Μια πύλη πρέπει να καθιστά σαφή τα στοιχεία ελέγχου του κύκλου ζωής.

  Στα προτεινόμενα στοιχεία ελέγχου κύκλου ζωής περιλαμβάνονται:

  • Προσωρινή λήξη σώματος: τα έγγραφα που μεταφορτώνονται για μια σύντομη περίοδο λειτουργίας θα πρέπει να έχουν μια χρονική σήμανση λήξης και μια εργασία διαγραφής.
  • Tenant offboarding: θραύσματα, αποθήκες διανύσματος παρόχου και σχετικά αντικείμενα αρχείων.
  • Χειρισμός ψυχρού μισθωτή: όπου υποστηρίζεται, οι ανενεργοί ενοικιαστές μπορούν να επισημανθούν ως ανενεργοί ή να εκφορτωθούν για να μειωθεί η χρήση πόρων.
  • Επαναπροσαρμογή ελέγχου έκδοσης: μοντέλο ενσωμάτωσης καταστήματος, πολιτική τεμαχισμού, > Οι ροές εργασίας του Partner API θα πρέπει να δείχνουν εάν ολοκληρώθηκε η διαγραφή εγγράφου, η διανυσματική διαγραφή και η διαγραφή από την πλευρά του παρόχου.

  Το σημαντικό γεγονός είναι ότι κάποιο διανυσματικό περιεχόμενο του καταστήματος διατηρείται μέχρι να διαγραφεί. Η σύσταση αρχιτεκτονικής είναι να κάνετε τη διαγραφή ορατή και δοκιμαστή αντί να την θάβετε σε μια ασύγχρονη εργασία χωρίς κατάσταση που να αντιμετωπίζει ο πελάτης.

  Παρακολούθηση τριών καταλόγων κόστους

  Ένα μεμονωμένο λογιστικό βιβλίο δεν αρκεί για το RAG. Μια πύλη χρειάζεται τουλάχιστον τρία λογιστικά βιβλία:

  • Κόστος ενσωμάτωσης και ευρετηρίασης: ανάλυση εγγράφων, τμηματοποίηση, ενσωμάτωση κλήσεων, αποθήκευση αρχείων, εγγραφή ευρετηρίου και εκ νέου ευρετηρίαση.
  • Κόστος ανάκτησης: διανυσματικές αναγνώσεις βάσης δεδομένων, αναζήτηση εγγενών διανυσματικών καταστημάτων, ανακατάταξη, επανακατάταξη, qu. επέκταση.
  • Κόστος δημιουργίας: εισαγάγετε διακριτικά από μηνύματα χρήστη και ανακτημένα περιβάλλοντα, διακριτικά εξόδου, κλήσεις εργαλείων, επαναλήψεις και εναλλακτικές λύσεις.

  Αυτό είναι ιδιαίτερα σημαντικό για εταιρείες, προμηθευτές SaaS και εσωτερικές ομάδες πλατφόρμας που μεταπωλούν ή κατανέμουν κόστη τεχνητής νοημοσύνης. Χωρίς ξεχωριστά καθολικά, τα περιθώρια RAG είναι δύσκολο να εξηγηθούν. Ένας μισθωτής με χρήση μικρής γενιάς μπορεί να εξακολουθεί να είναι ακριβός εάν ανεβάζει συνεχώς έγγραφα, αναπροσαρμόζει ευρετήρια μεγάλα σώματα ή εκτελεί ευρεία ερωτήματα ανάκτησης.

  Κάθε συμβάν ledger θα πρέπει να περιλαμβάνει tenant_id, customer_id εάν είναι διαφορετικό, αναγνωριστικό κλειδιού API, retrieval_profile, corpus_id, model, provider, trace_id και bi. Αυτό επιτρέπει στα αναλυτικά στοιχεία χρήσης να απαντούν σε πρακτικές ερωτήσεις: ποιοι ενοικιαστές έχουν ακριβά προφίλ ανάκτησης, ποια σώματα είναι μπαγιάτικα, ποια μοντέλα παράγουν αποτυχίες παραπομπών και ποιοι πελάτες δημιουργούν υπερμεγέθη προτροπές επειδή η ανάκτηση επιστρέφει πάρα πολύ περιβάλλον.

  Λειτουργίες αποτυχίας στη δοκιμή

  Μια πύλη RAG θα πρέπει να δημιουργεί δοκιμές RAG για την αποτυχία του πελάτη. ζημιά:

  • Αναφορές που λείπουν: citation_required είναι αληθές, αλλά η απάντηση του παρόχου δεν περιέχει αναφορές παραπομπών που να μπορούν να χρησιμοποιηθούν.
  • Παλιά ευρετήρια: ένα έγγραφο ενημερώθηκε ή διαγράφηκε, αλλά παλιά κομμάτια εξακολουθούν να εμφανίζονται στα αποτελέσματα ανάκτησης.
  • Επιλύει το λάθος αίτημα:
  • Ten: ή ο χώρος ονομάτων ανήκει στον ενοικιαστή B.
  • Υπερβολική ανάκτηση: το προφίλ επιστρέφει πάρα πολλά κομμάτια, αυξάνοντας το κόστος και μειώνοντας την ποιότητα των απαντήσεων.
  • Αναντιστοιχία μεγέθους τμημάτων: τα κομμάτια είναι τόσο μεγάλα που οι παραπομπές είναι ανακριβείς ή τόσο μικρά που το πλαίσιο μπορεί να χάσει το νόημα ενός μοντέλου.
  • misma>Proitch.
  • Αποτυχία κύκλου ζωής: ζητείται η διαγραφή, αλλά ο χώρος αποθήκευσης από την πλευρά του παρόχου παραμένει ενεργός ή μη επαληθευμένος.

  Αυτές οι δοκιμές θα πρέπει να εκτελούνται σε επίπεδο σύμβασης πύλης, όχι μόνο σε έναν προσαρμογέα παρόχου. Ο στόχος είναι να αποδειχθεί ότι η δημόσια συμπεριφορά παραμένει σταθερή όταν αλλάζει ο παροχέας υποστήριξης ανάκτησης ή δημιουργίας.

  Εναλλαγές

  Η ανάκτηση εγγενούς παρόχου μπορεί να μειώσει τον κώδικα εφαρμογής και να επιταχύνει μια πρώτη έκδοση. Η αντιστάθμιση είναι ότι ο κύκλος ζωής αποθήκευσης, η μορφή παραπομπών, τα στοιχεία ελέγχου ερωτημάτων και η διαθεσιμότητα λειτουργιών ενδέχεται να συνδέονται με έναν πάροχο.

  Οι εξωτερικές διανυσματικές βάσεις δεδομένων προσθέτουν λειτουργική επιφάνεια. Το πλεονέκτημα είναι η ισχυρότερη φορητότητα σε μοντέλα συμβατά με OpenAI, μοντέλα Anthropic και μελλοντικούς παρόχους. Επίσης, κάνουν τους χώρους ονομάτων ή τα θραύσματα με εμβέλεια ενοικιαστών ευκολότερο να εξηγήσουν πότε η πύλη είναι υπεύθυνη για τη χρέωση και την αποβίβαση.

  Τα λεπτόκοκκα κομμάτια βελτιώνουν την ακρίβεια των παραπομπών και τη δυνατότητα ελέγχου. Αυξάνουν επίσης το μέγεθος του ευρετηρίου, τον όγκο ανάκτησης και την άμεση πολυπλοκότητα της συναρμολόγησης. Τα χοντρά κομμάτια είναι πιο απλά, αλλά μπορεί να παράγουν παραπομπές που παραπέμπουν σε μια ευρεία σελίδα ή ενότητα αντί για το ακριβές υποστηρικτικό απόσπασμα.

  Η λειτουργία αυστηρής απαίτησης αναφοράς βελτιώνει την εμπιστοσύνη των χρηστών.Επίσης, αναγκάζει την πύλη να χειρίζεται μοντέλα που δεν μπορούν να παράγουν την απαιτούμενη μορφή παραπομπής, πράγμα που μπορεί να σημαίνει απόρριψη του αιτήματος, αλλαγή μοντέλων ή επιστροφή μιας απάντησης με χαμηλότερη κατάσταση εμπιστοσύνης.

  Πρόβλεψη: Η ανάκτηση θα γίνει πιο εγγενής, αλλά οι πύλες χρειάζονται ακόμα τη δική τους σύμβαση

  Οι λειτουργίες με δυνατότητα επανάληψης του κεφαλαίου είναι πιθανότερο να γίνουν παροχείς. Περισσότερα μοντέλα θα δέχονται το ανακτημένο πλαίσιο με μεταδεδομένα δομημένης πηγής. Περισσότερα API θα εκθέσουν τα στοιχεία ελέγχου κατάταξης, την επανεγγραφή ερωτημάτων και τις ρυθμίσεις παραπομπών. Αυτό δεν καταργεί την ανάγκη για σύμβαση πύλης.

  Η πύλη εξακολουθεί να κατέχει την ταυτότητα μισθωτή, τη διαχείριση κλειδιών, τα όρια δαπανών, τα αναλυτικά στοιχεία χρήσης, τις ροές εργασίας του Partner API και τις υποσχέσεις διαγραφής που αντιμετωπίζουν οι πελάτες. Οι δυνατότητες παρόχου μπορούν να χρησιμοποιηθούν πίσω από το επίπεδο προσαρμογέα, αλλά το προϊόν δεν θα πρέπει να αναγκάζει κάθε μισθωτή, μοντέλο και ροή εργασιών χρέωσης σε μια αφαίρεση ανάκτησης ενός παρόχου.

  Δράσιμο συμπέρασμα

  Δημιουργήστε το multi-entant RAG ως υποσύστημα πύλης με ρητά όρια. Επιλύστε την ταυτότητα του ενοικιαστή πριν από την ανάκτηση. Χρησιμοποιήστε χώρους ονομάτων με εύρος μισθωτή, θραύσματα ή διανυσματικά καταστήματα. Διατηρήστε την ανάκτηση πίσω από προσαρμογείς. Κανονικοποιήστε τις αναφορές σε ένα σχήμα που ανήκει στην πύλη. Προσθήκη καταστάσεων κύκλου ζωής και επαλήθευση διαγραφής. Παρακολουθήστε το κόστος ενσωμάτωσης, ανάκτησης και δημιουργίας χωριστά.

  Αυτή η αρχιτεκτονική διατηρεί το RAG γειωμένο χωρίς να κλειδώνει το προϊόν σε έναν πάροχο ανάκτησης. Παρέχει επίσης στις ομάδες τους λειτουργικούς ελέγχους που χρειάζονται όταν ένας βοηθός τεχνητής νοημοσύνης μετακινείται από ένα πρωτότυπο σε ένα σύστημα που απευθύνεται σε πελάτες: απομόνωση, αναφορές, φορητότητα, διαχείριση κύκλου ζωής και απόδοση κόστους.

  Σχετική ανάγνωση

  • ανάκτηση ίχνους, χρήση διακριτικών και αναλυτικά στοιχεία μισθωτή σε ένα μοντέλο παρατηρησιμότητας
  • κανονικοποίηση εξόδων για συγκεκριμένους παρόχους πίσω από μια σταθερή σύμβαση πύλης
  • σύνδεση παροχής ενοικιαστή και μέτρησης χρήσης με ροές εργασίας Partner API