B-Arts DocumentationIndice generale

Namespace B.BAI

Scopo

B.BAI espone un modello comune per utilizzare Ollama, OpenAI, Anthropic e Gemini senza inserire nell'applicazione formati HTTP specifici del provider.

L'accesso applicativo avviene tramite BAIConnection. La connection mantiene configurazione, stato, regole, contesto, conversazione, funzioni, timeout, errori e log. La traduzione verso le API native è delegata alle implementazioni del namespace B.BAI.BAIProviders; i dati normalizzati delle risposte e dello streaming appartengono a B.BAI.BAIParser.

Per esempi completi consultare Casi d'uso.

Tipi principali

Enumerazioni

  • eBAITipoProvider: Ollama, Anthropic, OpenAI, Gemini.

  • eBAIRole: System, User, Assistant, Tool.

  • eSendOption: All, Rules, Context, None.

  • eBAICreativity: Precise, Conservative, Balanced, Creative, VeryCreative.

Semantiche fondamentali

  • SendAsync e SendStreamingAsync usano la conversazione e aggiungono a Messages la risposta Assistant completata con successo.

  • SendSingleAsync e SendSingleStreamingAsync sono stateless e non modificano Messages.

  • ExecuteAsync<T> usa la conversazione; ExecuteSingleAsync<T> usa un singolo messaggio. Entrambi restituiscono BTypeResult<T>.

  • Rules e Context vengono inclusi secondo eSendOption.

  • Se sono registrate Functions, i metodi Send ricevono le tool call, eseguono i delegate registrati, inviano i risultati e proseguono fino alla risposta conclusiva.

  • Gli errori operativi vengono registrati in ExceptionList e Log; le API restituiscono il risultato neutro previsto dal proprio contratto.

Architettura provider

BAIConnection
  -> IBAIProvider
      -> BAIOllamaProvider
      -> BAIOpenAIProvider
      -> BAIAnthropicProvider
      -> BAIGeminiProvider

BAIConnection gestisce l'orchestrazione comune. Endpoint, header, request, mapping dei messaggi, parsing, streaming, Structured Output, allegati, Function Calling, modelli ed embeddings restano nelle classi provider.