Skip to content
Gallery
AI Turbo-George
Page d'accueil
Masterclass
George V1
Wiki
Source Externe
Contact
Politiques d'utilisation
George Beta
Configuration Système
Doc Explorer
More
Share
Explore
API AI Turbo-George

En Vrac

Prompt

Conception rapide


Bases

Nos modèles peuvent tout faire, de la génération d'histoires originales à l'analyse de texte complexe. Parce qu'ils peuvent faire tellement de choses, vous devez être explicite en décrivant ce que vous voulez. Montrer, pas seulement dire, est souvent le secret d'une bonne invite.
Il existe trois règles de base pour créer des invites :

Montrer et dire.

Expliquez clairement ce que vous voulez par le biais d'instructions, d'exemples ou d'une combinaison des deux. Si vous souhaitez que le modèle classe une liste d'éléments par ordre alphabétique ou classe un paragraphe par sentiment, montrez-lui que c'est ce que vous voulez.

Fournir des données de qualité.

Si vous essayez de construire un classificateur ou de faire en sorte que le modèle suive un modèle, assurez-vous qu'il y a suffisamment d'exemples. Assurez-vous de relire vos exemples - le modèle est généralement assez intelligent pour voir à travers les fautes d'orthographe de base et vous donner une réponse, mais il peut également supposer que c'est intentionnel et que cela peut affecter la réponse.

Vérifiez vos paramètres.

Les paramètres temperature et top_p contrôlent le degré de déterminisme du modèle dans la génération d'une réponse. Si vous le demandez pour une réponse où il n'y a qu'une seule bonne réponse, alors vous voudrez les définir plus bas. Si vous recherchez des réponses plus diversifiées, vous souhaiterez peut-être les définir plus haut. L'erreur numéro un que les gens utilisent avec ces paramètres est de supposer qu'il s'agit de contrôles "d'intelligence" ou de "créativité".

Dépannage

Si vous ne parvenez pas à faire fonctionner l'API comme prévu, suivez cette liste de contrôle :
La génération visée est-elle claire ?
Y a-t-il suffisamment d'exemples ?
Avez-vous vérifié vos exemples pour les erreurs? (L'API ne vous le dira pas directement)
Utilisez-vous temperature et top_p correctement ?

Classification

Pour créer un classificateur de texte avec l'API, nous fournissons une description de la tâche et quelques exemples. Dans cet exemple, nous montrons comment classer le sentiment des Tweets.
Décidez si le sentiment d'un Tweet est positif, neutre ou négatif. Tweet : J'ai adoré le nouveau film Batman ! Sentiment:
Il convient de prêter attention à plusieurs fonctionnalités dans cet exemple :
Utilisez un langage simple pour décrire vos entrées et vos sorties. Nous utilisons un langage simple pour l'entrée "Tweet" et la sortie attendue "Sentiment". Comme meilleure pratique, commencez par des descriptions en langage clair. Bien que vous puissiez souvent utiliser des raccourcis ou des touches pour indiquer l'entrée et la sortie, il est préférable de commencer par être aussi descriptif que possible, puis de revenir en arrière pour supprimer les mots supplémentaires et voir si les performances restent cohérentes.
Montrez à l'API comment répondre à tous les cas. Dans cet exemple, nous incluons les étiquettes de sentiment possibles dans notre instruction. Une étiquette neutre est importante car il y aura de nombreux cas où même un humain aurait du mal à déterminer si quelque chose est positif ou négatif, et des situations où ce n'est ni l'un ni l'autre.
Vous avez besoin de moins d'exemples pour les tâches familières. Pour ce classificateur, nous ne fournissons aucun exemple. En effet, l'API comprend déjà le sentiment et le concept de Tweet. Si vous construisez un classificateur pour quelque chose que l'API n'est peut-être pas familier, il peut être nécessaire de fournir plus d'exemples.

Améliorer l'efficacité du classificateur

Maintenant que nous savons comment créer un classificateur, prenons cet exemple et rendons-le encore plus efficace afin que nous puissions l'utiliser pour obtenir plusieurs résultats à partir d'un seul appel d'API.
Classez le sentiment dans ces tweets : 1. "Je ne supporte pas les devoirs" 2. "C'est nul. Je m'ennuie 😠" 3. "J'ai hâte d'Halloween !!!" 4. "Mon chat est adorable ❤️❤️" 5. "Je déteste le chocolat"
Nous fournissons une liste numérotée de Tweets afin que l'API puisse évaluer cinq (et même plus) Tweets en un seul appel API.
Il est important de noter que lorsque vous demandez à l'API de créer des listes ou d'évaluer du texte, vous devez accorder une attention particulière à vos paramètres de probabilité (Top P ou Température) pour éviter toute dérive.
Assurez-vous que votre paramètre de probabilité est correctement calibré en exécutant plusieurs tests.
Ne faites pas votre liste trop longue ou l'API risque de dériver.

Classer

Organisez les informations à une échelle gargantuesque. Donnez des étiquettes de classification dans lesquelles placer le texte, puis configurez-les pour qu'elles fonctionnent sur des tâches telles que la modération de contenu ou les réponses de chatbot
Cas d'utilisation typiques :
Reconnaissance d'intention
Classement des sujets
Analyse des sentiments
Modération du contenu
Acheminement des tickets d'assistance

Le pouvoir de comprendre

Classifier utilise un apprentissage automatique de pointe pour analyser et classer le texte dans des catégories spécifiques. Créez des classificateurs de texte automatisés dans votre application pour, par exemple, identifier le langage toxique, acheminer automatiquement les requêtes des clients ou détecter les dernières tendances dans les avis sur les produits.

Protégez votre communauté

Utilisez Classifier pour identifier les discours haineux, les propos abusifs, les spams, les grossièretés ou tout ce qui répond aux filtres fournis par l'utilisateur.

Exploiter la reconnaissance d'intention

Trier les demandes entrants comprendre l'intention de l'utilisateur et rediriger l’utilisateur vers les bon George.
George le Plombier
George le Musicien
George le Motard

Mieux servir les Utilisateurs

Gagnez du temps en chargeant George d'acheminer les demandes entrantes des Utilisateurs vers d’autre Utilisateur ou vers l’Assistance client .
Partager des infos
Ajoutez un Utilisateur a un Projet/Tache

Accédez à une analyse des sentiments de pointe

Développez une affinité client plus forte en classant les publications, les avis, etc. pour comprendre comment ils perçoivent votre entreprise/marque.
J’aime George = Sentiments Positif
Je ne suis pas très fan de cette Musique = Sentiments Positif

Générer

Imaginez un grand modèle de langage qui peut être utilisé pour écrire ou résumer une copie pour à peu près n'importe quelle autre application à laquelle vous pouvez penser. C'est Générer.
Cas d'utilisation typiques :
Rédaction des descriptifs produits
Rédaction d'articles de blog
Rédaction de création publicitaire
Résumé des articles
Correction orthographe, grammaire
Extraction d'entité

Intégrer

Imaginez que l'IA charge de lire chaque message Reddit sur votre entreprise, puis de le tracer dans un graphique facile à comprendre. Vous pouvez le faire, et plus encore, avec Embed.
Cas d'utilisation typiques :
Recherche sémantique
Modélisation de sujet
Recommandations

Jouer

Testez nos modèles dans notre Playground. Aucune expérience en ML nécessaire !

Apprendre


The Clean Architecture

⁠
image.jpeg
⁠
⁠
Au cours des dernières années, nous avons vu toute une gamme d'idées concernant l'architecture des systèmes. Ceux-ci inclus:
⁠
Hexagonal Architecture
⁠
(a.k.a. Ports and Adapters) by Alistair Cockburn and adopted by Steve Freeman, and Nat Pryce in their wonderful book
Growing Object Oriented Software
⁠
⁠
⁠
Onion Architecture
⁠
by Jeffrey Palermo
⁠
Screaming Architecture
⁠
from a blog of mine last year
⁠
DCI
⁠
from James Coplien, and Trygve Reenskaug.
⁠
BCE
⁠
by Ivar Jacobson from his book Object Oriented Software Engineering: A Use-Case Driven Approach
Bien que ces architectures varient toutes quelque peu dans leurs détails, elles sont très similaires. Ils ont tous le même objectif, qui est la séparation des préoccupations. Ils réalisent tous cette séparation en divisant le logiciel en couches. Chacun a au moins une couche pour les règles métier et une autre pour les interfaces.
Chacune de ces architectures produit des systèmes qui sont :
1. Indépendant des cadres. L'architecture ne dépend pas de l'existence d'une bibliothèque de logiciels chargés de fonctionnalités. Cela vous permet d'utiliser ces frameworks comme des outils, plutôt que d'avoir à entasser votre système dans leurs contraintes limitées. 2. Testable. Les règles métier peuvent être testées sans l'interface utilisateur, la base de données, le serveur Web ou tout autre élément externe. 3. Indépendant de l'interface utilisateur. L'interface utilisateur peut changer facilement, sans changer le reste du système. Une interface utilisateur Web pourrait être remplacée par une interface utilisateur de console, par exemple, sans modifier les règles métier. 4. Indépendant de la base de données. Vous pouvez remplacer Oracle ou SQL Server par Mongo, BigTable, CouchDB ou autre chose. Vos règles métier ne sont pas liées à la base de données. 5. Indépendant de toute agence externe. En fait, vos règles métier ne savent tout simplement rien du monde extérieur.
Le diagramme en haut de cet article est une tentative d'intégration de toutes ces architectures en une seule idée exploitable.

La règle de dépendance

Les cercles concentriques représentent différents domaines du logiciel. En général, plus vous avancez, plus le logiciel monte en niveau. Les cercles extérieurs sont des mécanismes. Les cercles intérieurs sont des politiques.
La règle primordiale qui fait fonctionner cette architecture est la règle de dépendance. Cette règle indique que les dépendances du code source ne peuvent pointer que vers l'intérieur. Rien dans un cercle intérieur ne peut savoir quoi que ce soit sur quelque chose dans un cercle extérieur. En particulier, le nom d'une chose déclarée dans un cercle extérieur ne doit pas être mentionné par le code dans un cercle intérieur. Cela inclut, les fonctions, les classes. variables ou toute autre entité logicielle nommée.
De même, les formats de données utilisés dans un cercle extérieur ne doivent pas être utilisés par un cercle intérieur, surtout si ces formats sont générés par un framework dans un cercle extérieur. Nous ne voulons pas que quoi que ce soit dans un cercle extérieur ait un impact sur les cercles intérieurs.

Entités

Les entités encapsulent les règles métier à l'échelle de l'entreprise. Une entité peut être un objet avec des méthodes ou un ensemble de structures de données et de fonctions. Peu importe tant que les entités peuvent être utilisées par de nombreuses applications différentes dans l'entreprise.
Si vous n'avez pas d'entreprise et que vous écrivez une seule application, ces entités sont les objets métier de l'application. Ils encapsulent les règles les plus générales et de haut niveau. Ils sont les moins susceptibles de changer lorsque quelque chose d'extérieur change. Par exemple, vous ne vous attendriez pas à ce que ces objets soient affectés par une modification de la navigation dans les pages ou de la sécurité. Aucune modification opérationnelle d'une application particulière ne doit affecter la couche entité.

Cas d'utilisation

Le logiciel de cette couche contient des règles métier spécifiques à l'application. Il encapsule et implémente tous les cas d'utilisation du système. Ces cas d'utilisation orchestrent le flux de données vers et depuis les entités et ordonnent à ces entités d'utiliser leurs règles métier à l'échelle de l'entreprise pour atteindre les objectifs du cas d'utilisation.
Nous ne nous attendons pas à ce que les modifications apportées à cette couche affectent les entités. Nous ne nous attendons pas non plus à ce que cette couche soit affectée par des modifications d'externalités telles que la base de données, l'interface utilisateur ou l'un des cadres communs. Cette couche est isolée de ces préoccupations.
Cependant, nous nous attendons à ce que les modifications apportées au fonctionnement de l'application affectent les cas d'utilisation et donc les logiciels de cette couche. Si les détails d'un cas d'utilisation changent, une partie du code de cette couche sera certainement affectée.

Adaptateurs d'interface

Le logiciel de cette couche est un ensemble d'adaptateurs qui convertissent les données du format le plus pratique pour les cas d'utilisation et les entités, au format le plus pratique pour une agence externe telle que la base de données ou le Web. C'est cette couche, par exemple, qui contiendra entièrement l'architecture MVC d'une IHM. Les présentateurs, les vues et les contrôleurs appartiennent tous ici. Les modèles ne sont probablement que des structures de données qui sont transmises des contrôleurs aux cas d'utilisation, puis des cas d'utilisation aux présentateurs et aux vues.
De même, les données sont converties, dans cette couche, de la forme la plus pratique pour les entités et les cas d'utilisation, à la forme la plus pratique pour le cadre de persistance utilisé. c'est-à-dire la base de données. Aucun code à l'intérieur de ce cercle ne devrait savoir quoi que ce soit sur la base de données. Si la base de données est une base de données SQL, alors tout le SQL doit être limité à cette couche, et en particulier aux parties de cette couche qui ont à voir avec la base de données.
Dans cette couche se trouve également tout autre adaptateur nécessaire pour convertir les données d'un formulaire externe, tel qu'un service externe, vers le formulaire interne utilisé par les cas d'utilisation et les entités.

Cadres et pilotes.

La couche la plus externe est généralement composée de frameworks et d'outils tels que la base de données, le framework Web, etc. Généralement, vous n'écrivez pas beaucoup de code dans cette couche autre que le code de colle qui communique avec le cercle suivant vers l'intérieur.
Cette couche est l'endroit où tous les détails vont. Le Web est un détail. La base de données est un détail. Nous gardons ces choses à l'extérieur où elles peuvent faire peu de mal.

Seulement quatre cercles ?

Non, les cercles sont schématiques. Vous constaterez peut-être que vous avez besoin de plus que ces quatre éléments. Il n'y a aucune règle qui dit que vous devez toujours avoir seulement ces quatre. Cependant, la règle de dépendance s'applique toujours. Les dépendances du code source pointent toujours vers l'intérieur. Au fur et à mesure que vous vous déplacez vers l'intérieur, le niveau d'abstraction augmente. Le cercle le plus à l'extérieur est un détail concret de bas niveau. Au fur et à mesure que vous vous déplacez vers l'intérieur, le logiciel devient plus abstrait et encapsule des politiques de niveau supérieur. Le cercle le plus intérieur est le plus général.

Franchir les frontières.

En bas à droite du diagramme se trouve un exemple de la façon dont nous traversons les limites du cercle. Il montre les contrôleurs et les présentateurs communiquant avec les cas d'utilisation dans la couche suivante. Notez le flux de contrôle. Il commence dans le contrôleur, se déplace dans le cas d'utilisation, puis finit par s'exécuter dans le présentateur. Notez également les dépendances du code source. Chacun d'eux pointe vers l'intérieur vers les cas d'utilisation.
Nous résolvons généralement cette contradiction apparente en utilisant le principe d'inversion de dépendance. Dans un langage comme Java, par exemple, nous organiserions les interfaces et les relations d'héritage de telle sorte que les dépendances du code source s'opposent au flux de contrôle juste aux bons points à travers la frontière.
Par exemple, considérez que le cas d'utilisation doit appeler le présentateur. Cependant, cet appel ne doit pas être direct car cela violerait la règle de dépendance : aucun nom dans un cercle extérieur ne peut être mentionné par un cercle intérieur. Nous avons donc le cas d'utilisation appeler une interface (illustrée ici en tant que port de sortie du cas d'utilisation) dans le cercle intérieur, et demander au présentateur du cercle extérieur de l'implémenter.
La même technique est utilisée pour franchir toutes les frontières dans les architectures. Nous profitons du polymorphisme dynamique pour créer des dépendances de code source qui s'opposent au flux de contrôle afin que nous puissions nous conformer à la règle de dépendance quelle que soit la direction dans laquelle le flux de contrôle va.

Quelles données franchissent les frontières.

Généralement, les données qui traversent les frontières sont des structures de données simples. Vous pouvez utiliser des structures de base ou de simples objets de transfert de données si vous le souhaitez. Ou les données peuvent simplement être des arguments dans des appels de fonction. Ou vous pouvez l'emballer dans un hashmap ou le construire dans un objet. L'important est que des structures de données simples et isolées traversent les frontières. Nous ne voulons pas tricher et passer des lignes d'entités ou de base de données. Nous ne voulons pas que les structures de données aient un type de dépendance qui viole la règle de dépendance.
Par exemple, de nombreux frameworks de base de données renvoient un format de données pratique en réponse à une requête. Nous pourrions appeler cela une RowStructure. Nous ne voulons pas faire passer cette structure de lignes vers l'intérieur à travers une limite. Cela violerait la règle de dépendance car cela forcerait un cercle intérieur à savoir quelque chose sur un cercle extérieur.
Ainsi, lorsque nous transmettons des données à travers une frontière, elles sont toujours sous la forme la plus pratique pour le cercle intérieur.

Conclusion

Se conformer à ces règles simples n'est pas difficile et vous évitera bien des maux de tête à l'avenir. En séparant le logiciel en couches et en vous conformant à la règle de dépendance, vous créerez un système intrinsèquement testable, avec tous les avantages que cela implique. Lorsque l'une des parties externes du système devient obsolète, comme la base de données ou le framework Web, vous pouvez remplacer ces éléments obsolètes avec un minimum de tracas.

Prompt

Placez les instructions au début de l'invite et utilisez ### ou """ pour séparer l'instruction et le contexte


Moins efficace ❌ :
Mieux ✅ :
⁠

Soyez précis, descriptif et aussi détaillé que possible sur le contexte souhaité, le résultat, la longueur, le format, le style, etc Soyez précis sur le contexte, le résultat, la longueur, le format, le style, etc.


Moins efficace ❌ :

Mieux ✅ :
⁠

Articulez le format de sortie souhaité à l'aide d'exemples (exemple 1?, exemple 2?).


Moins efficace ❌ :
Afficher et raconter : les modèles réagissent mieux lorsqu'ils présentent des exigences de format spécifiques. Cela facilite également l'analyse par programmation de plusieurs sorties de manière fiable.

Mieux ✅:
⁠

Commencez par zéro-coup, puis quelques-coups (exemple), aucun d'eux n'a fonctionné, puis ajustez

✅ Zero-shot
✅ Extrayez les mots clés des textes correspondants ci-dessous.
✅Fine-tune: voir les meilleures pratiques d'ajustement
Classification best practices (Access: Open to All)
Update: we recommend this more comprehensive guide: Best practices for classifying text with fine-tuned models Ted Sanders May 2022 Public resources Fine tuning documentation Code example How fine-tuning works You can improve GPT-3’s performance on specific tasks by fine-tuning it on trainin...
docs.google.com
⁠
⁠
⁠

Réduire les descriptions "floues" et imprécises

Moins efficace ❌ :
Better ✅:
⁠

Au lieu de simplement dire ce qu'il ne faut pas faire, dites plutôt ce qu'il faut faire

Moins efficace ❌ :
Mieux ✅:




test
.Filter(
date >= thisRow.[Start Day] and date <= thisRow.[End Day]
)
.[Total Task]
.Sum()
test
1
date
in
out
Total Task
1
19/03/2023
19/03/2023, 00:30
19/03/2023, 02:30
2 hrs
2
21/03/2023
21/03/2023, 02:00
21/03/2023, 03:00
1 hr
3
20/03/2023
20/03/2023, 01:00
20/03/2023, 03:30
2 hrs 30 mins
4
28/03/2023
28/03/2023, 07:00
28/03/2023, 07:30
30 mins
5
30/03/2023
30/03/2023, 01:30
30/03/2023, 10:30
9 hrs
There are no rows in this table
⁠

test2
1
Start Day
End Day
Total Week
1
20/03/2023
29/03/2023
4 hrs
2
-
3
-
There are no rows in this table
⁠

[Work Log].Filter(Year=year(Today())).[Session Duration].Sum().AbsoluteValue()*24

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.