Creazione di un modello personalizzato
Importante
Alcune informazioni in questo articolo fanno riferimento alle caratteristiche di un prodotto prima del rilascio, che possono essere modificate sostanzialmente prima della distribuzione al pubblico. Microsoft non fornisce alcuna garanzia, esplicita o implicita, in relazione alle informazioni contenute in questo documento.
Consiglio
Se hai bisogno di assistenza per i plug-in non Microsoft, consulta la documentazione e rivolgiti al team di supporto.
Creazione di nuovi plug-in
A seconda di come gli amministratori configurano Copilot per la sicurezza, è possibile creare nuovi plug-in seguendo questa procedura:
Crea un plug-in dall'elenco dei plug-in supportati.
Crea un file manifesto del plug-in YAML o JSON, che descrive i metadati relativi al plug-in e il metodo per richiamarlo.
Pubblica il manifesto del plug-in in Copilot per la sicurezza.
Requisiti del plug-in
Ogni plug-in Copilot per la sicurezza richiede un file manifesto in formato YAML o JSON (ad esempio: plugin.yaml
o plugin.json
) che descrive i metadati relativi alle funzionalità e il metodo per richiamarle.
Un manifesto è costituito da due chiavi di primo livello necessarie, Descriptor
e SkillGroups
, ognuna con coppie chiave secondaria o valore e campi obbligatori/facoltativi a seconda del formato della funzionalità.
Per informazioni sui plug-in OpenAI, vedi Introduzione.
Riepilogo del campo descrittore
Campo | Tipo | Descrizione | Obbligatorio |
---|---|---|---|
Name |
stringa | Nome interno del plug-in. Non consente / \ ? # @ . |
Sì |
DisplayName |
stringa | Nome leggibile del plug-in. | Consigliata |
Description |
stringa | Descrizione leggibile del plug-in. | Sì |
DescriptionDisplay |
stringa | Descrizione alternativa leggibile del plug-in se la descrizione non è specificata. | No |
Category |
stringa | Nota: questo valore è attualmente forzato per Plugin durante il processo di caricamento del plug-in personalizzato. |
No |
Prerequisites |
stringa | No | |
Icon |
stringa | URL usato per recuperare l'icona principale per le competenze. | Consigliata |
Riepilogo del campo SkillGroups
È costituito da un elenco di gruppi di funzionalità tra cui Format
, Settings
e Skills
.
Campo | Tipo | Descrizione | Obbligatorio |
---|---|---|---|
Format |
stringa | Per le opzioni disponibili, vedi la sezione Formato. | Sì |
Settings |
oggetto | Per la struttura degli oggetti, vedi la sezione Impostazioni. | Sì, per i formati: API , DOTNET , CONTAINER |
Skills |
oggetto | Per la struttura degli oggetti, vedi la sezione Competenze. | Sì, per i formati: GPT , DOTNET , KQL , LogicApp |
Formato (campo SkillGroups)
Opzioni per il campo Format
:
API
GPT
KQL
Impostazioni (campo SkillGroups)
Struttura dell'oggetto per il campo Settings
.
Campo | Tipo | Descrizione | Obbligatorio |
---|---|---|---|
OpenApiSpecUrl |
stringa | URL per la specifica OpenAPI pubblica. | Sì |
EndpointUrl |
stringa | URL per l'endpoint pubblico. | No |
Competenze (campo SkillGroups)
Struttura dell'oggetto per il campo Skills
.
Campo | Tipo | Descrizione | Obbligatorio |
---|---|---|---|
Description |
stringa | Descrizione leggibile per questa funzionalità. | Consigliata |
DescriptionForModel |
stringa | Descrizione dettagliata della funzionalità usata per la selezione delle funzionalità | No |
Inputs |
oggetto | Elenco degli oggetti Name , Description , Required e DefaultValue (facoltativo) per l'input dell'utente nella funzionalità. |
|
Settings |
oggetto | Impostazioni personalizzate in base al formato della funzionalità. |
Differenze tra i manifesti OpenAI e Copilot per la sicurezza
I plug-in OpenAI compilati seguendo la documentazione del plug-in ChatGPT usano in genere un formato manifesto diverso rispetto a quello di Copilot per la sicurezza. Copilot per la sicurezza supporta entrambi i formati.
Al momento del caricamento, il manifesto del plug-in OpenAI viene convertito nel manifesto Copilot per la sicurezza.
Nota
I dettagli di mapping, in particolare per quanto riguarda le restrizioni nelle note, possono cambiare in futuro. Attualmente, la piattaforma supporta solo i plug-in nelle versioni OpenAPI 3.0 o 3.0.1.
Mapping dei campi del plug-in
Campo del plug-in | Tipo | Campo descrittore | Obbligatorio | Note |
---|---|---|---|---|
schema_version |
stringa | No | Si tratta della versione dello schema del manifesto OpenAI, ad esempio 'v1'. Attualmente non in uso. | |
name_for_model |
stringa | Nome | Sì | Limite di lunghezza di 100 caratteri. Nome interno delle competenze. Non consente / \ ? # . |
name_for_human |
stringa | DisplayName | Sì | Nome leggibile del plug-in. Limite di lunghezza di 40 caratteri. |
description_for_model |
stringa | Descrizione | Sì | Limite di lunghezza di 16.000 caratteri. Descrizione interna da usare con LLM. |
description_for_human |
stringa | DescriptionDisplay | Sì | Descrizione leggibile del plug-in. Limite di lunghezza di 200 caratteri. |
logo_url |
stringa | Icona | Consigliata | URL usato per recuperare l'icona principale per il plug-in. |
contact_email |
stringa | No | Contatto di posta elettronica per il plug-in. Attualmente non in uso. | |
legal_info_url |
stringa | No | Collegamento per informazioni sui plug-in. Attualmente non in uso. | |
api |
oggetto | Per la struttura degli oggetti, vedi la sezione API del plug-in. | Sì | |
auth |
oggetto | Sì | authorization_type è limitato a bearer . Dettagli da seguire sul supporto per un'autenticazione type diversa, ad esempio nessuno, oauth, api_key, aad, aad_delegated. |
Plug-in (campo API)
Struttura dell'oggetto per il campo api
Campo | Tipo | Descrizione | Obbligatorio |
---|---|---|---|
type |
stringa | L'unico tipo attualmente supportato è openapi . |
Sì |
url |
stringa | Collegamento al documento di specifica OpenAPI dell'API. | Sì |
Linee guida per la creazione di plug-in
Le considerazioni da fare sulla creazione di plug-in sono molte. Questo documento ha lo scopo di acquisire alcune delle linee guida e delle procedure consigliate per la scrittura di plug-in per Copilot per la sicurezza.
Nota
Una "collisione di funzionalità" si verifica quando Copilot per la sicurezza non distingue accuratamente tra due funzionalità diverse.
Anziché avere più funzionalità che restituiscono lo stesso tipo di risposta, ma differiscono solo in base agli input, è opportuno definire le funzionalità, che accettano più input e pertanto consentono di capire internamente come ottenere i dati.
- Ad esempio, è utile avere una singola funzionalità
GetDevices
che accetta l'ID dispositivo, l'ID utente o il nome utente anziché separareGetDeviceById
,GetDeviceByUserId
eGetDeviceByUserName
.
- Ad esempio, è utile avere una singola funzionalità
Copilot per la sicurezza supporta i
Description
campi eDescriptionForModel
.Description
viene usato nell'esperienza utente (e per la selezione delle funzionalità seDescriptionForModel
non è impostato) eDescriptionForModel
viene usato solo per la selezione delle funzionalità.- Ad esempio, supponiamo di avere una funzionalità GetSslCertsByHostname, con la descrizione "Restituisce i certificati SSL associati a un nome host". Una descriptionForModel dettagliata potrebbe essere la seguente: "Recupera i certificati SSL (noti anche come certificati TLS) per un nome host DNS o un nome di dominio. Restituisce un elenco di certificati SSL insieme ai dettagli del certificato, ad esempio autorità di certificazione, soggetto, numero di serie, sha1 e date".
Le descrizioni delle competenze devono essere dettagliate e formulate per una persona che ha una conoscenza ragionevole, ma che potrebbe non essere un esperto del problema. Dovrebbe descrivere cosa fa la funzionalità e il motivo per cui una persona potrebbe usarla.
- Ad esempio, una descrizione valida è la seguente: "Ottiene informazioni sulla reputazione di un indirizzo IP. Consente agli utenti di stabilire se un indirizzo IP è rischioso".