22.1 LLM

The LLM section of the settings allows you to register the Large Language Models (LLMs) that vtenext can use for AI agents and other AI-powered features. Here, you can define the model's connection details, assign it a name for identification, and configure parameters that influence the model's response behavior.

vtenext does not include a built-in AI model within the CRM. To configure an LLM, you must have either a remote model accessible through OpenAI-compatible APIs or a locally installed model that is reachable by the system. In other words, this configuration is used to connect vtenext to an external or local AI service—the model itself is not built into the CRM.

The List View

The list displays all previously saved configurations. For each entry, you can view:

• Active or inactive status
  
• Configuration name
  
• Service URL
  
• Model used

From the list, you can create a new configuration, edit an existing entry, delete it, or quickly enable and disable it.

Creating a new LLM

1. Apri la sezione LLM.
2. Fai clic su Aggiungi.
3. Compila i campi richiesti.
4. Se necessario, esegui un test della configurazione.
5. Salva.

• Attivo: rende il modello disponibile per l'utilizzo.
• Nome: nome descrittivo del modello visualizzato in vtenext. Campo obbligatorio.
• URL: endpoint API a cui vtenext invia le richieste al modello (ad esempio https://api.openai.com/v1/chat/completions). Campo obbligatorio.
• Modello: identificativo del modello da utilizzare (ad esempio gpt-5.2). Campo obbligatorio.
• Base URL: è l'indirizzo di base del servizio che ospita il modello. In pratica dice agli agenti AI e all'orchestratore Python dove si trova il servizio del modello. Diventa particolarmente importante quando si utilizza un modello locale o un servizio interno all'infrastruttura, per esempio un endpoint come http://127.0.0.1:11434.
• Provider: indica a vtenext e all'orchestratore Python che tipo di servizio c'è dietro al modello, ad esempio OpenAI oppure Ollama.
• API Key: chiave di autenticazione fornita dal provider, necessaria per autorizzare le richieste API.
• Temperatura: controlla il livello di casualità delle risposte generate. Valori bassi (ad esempio 0,2) producono risposte più coerenti, prevedibili e ripetibili; valori più alti (ad esempio 0,8 o superiori) favoriscono risposte più varie e creative.
• Token massimi: definisce il numero massimo complessivo di token che il modello può utilizzare per elaborare la richiesta, includendo sia i messaggi inviati sia la risposta generata (se supportato dal provider).
• Token di completamento massimi: limita il numero massimo di token che il modello può utilizzare esclusivamente per la risposta generata.
• Developer Message: istruzioni rivolte al modello con ruolo developer, utilizzate per definire regole di comportamento o vincoli applicativi.
• System Message: istruzioni generali che definiscono il comportamento del modello durante la conversazione.
• User Message: messaggio di prova inviato al modello per verificarne il funzionamento. Campo obbligatorio.
  

Come funziona il test

Il pulsante di PROVA invia una richiesta reale al modello con i parametri configurati e mostra:

• esito dell'operazione
• codice di risposta
• header restituiti
• corpo completo della risposta

Risultato della chiamata: tab RISULTATO

Risultato della chiamata: tab HEADERS

Risultato della chiamata: tab RISPOSTA

Il test serve a verificare la configurazione, ma non sostituisce il salvataggio.

Il test invia una richiesta reale al modello remoto o locale. Se il modello non è raggiungibile via API, il test non può funzionare.

Esempi pratici

Esempio 1: modello compatibile OpenAI

Usa questa configurazione quando il modello è disponibile come servizio remoto tramite API esterna. Imposta nome, URL, modello e API Key, poi invia un semplice messaggio di test.

Esempio 2: modello locale

Se il modello gira in locale o su infrastruttura interna, compila anche Base URL e Provider. Anche in questo caso il modello deve essere già installato, attivo e raggiungibile via rete.