Tutoriel API Grok 4.7 : créez un relecteur de schémas électroniques dopé à l'IA

Un schéma électrique représente les connexions entre composants. Le relire consiste à vérifier si les composants et leurs valeurs respectent les exigences de conception. L'alimentation peut-elle fournir suffisamment de courant ? Le microcontrôleur peut-il lire toute la plage du capteur ? Les réponses se trouvent dans le schéma, les fiches techniques et quelques calculs.

Je voulais voir si Grok 4.7 pouvait mener l'intégralité de cette revue. Le guide Grok 4.7 explique que le modèle a été entraîné pour des tâches longues et pour réexaminer son propre travail avec plus de rigueur. Un circuit fournit également des nombres que du Python classique peut contrôler : nul besoin d'un autre modèle d'IA pour juger le résultat.

Pour l'expérience, j'ai conçu EnviroNode Rev A, une petite carte capteur alimentée en USB, et j'y ai introduit trois défauts. Grok n'est pas informé du nombre de défauts. Il doit les trouver, étayer chaque constat par la documentation des composants, proposer des corrections, puis soumettre les valeurs corrigées à des contrôles Python.

Vous n'avez pas besoin d'un bagage en génie électrique pour suivre. J'explique chaque règle de circuit au moment où elle intervient. Vous apprendrez à :

• Envoyer une image de schéma à Grok 4.7 via la Responses API

• Joindre des fiches techniques avec la Files API et laisser Grok les rechercher

• Vérifier des calculs avec l'exécution de code et des limites avec la recherche web

• Donner à Grok une fonction locale verify_design() qui statue sur réussite ou échec

• Maintenir une conversation longue et très documentée dans la limite de contexte du modèle

• Rendre un format de revue cohérent, puis comparer les niveaux de raisonnement

La même carte reste au centre depuis la première relecture d'image jusqu'au contrôle Python final.

En bref

Grok 4.7 a identifié tous les défauts injectés une fois les fiches techniques fournies, et la conception corrigée a réussi les contrôles Python. Cela en dit plus sur ces trois défauts que sur la relecture de circuits en général.

• Sans documents, Grok refuse de deviner : l'image seule a permis de confirmer un défaut, et les limites du régulateur et de l'ADC (convertisseur analogique-numérique) sont restées en "nécessite des preuves".
• Les fiches techniques transforment le soupçon en preuve : chaque constat cite une valeur documentaire, sans faux positifs sur les composants corrects.
• Des échanges très chargés en fichiers peuvent épuiser le contexte : après des recherches PDF répétées, une poursuite a dépassé la fenêtre de 500 K ; la boucle corrigée compacte avant le tour suivant.
• Low a réussi la vérification mais révèle un angle mort : ses valeurs de filtre passent les contrôles écrits tout en laissant non testés le comportement en charge capacitive et la stabilisation.

Ceci concerne une petite carte, pas un benchmark. Une carte avec une douzaine de fiches techniques créera un contexte plus volumineux et pourra donner d'autres résultats.

Qu'est-ce que l'API Grok 4.7 ?

L'API Grok 4.7 offre aux apps Python une entrée texte et image, une sortie texte et une fenêtre de contexte de 500 000 tokens via l'identifiant de modèle grok-4.7. Le guide officiel liste les niveaux de raisonnement low, medium, high (par défaut) et xhigh ; le raisonnement ne peut pas être désactivé. L'API prend aussi en charge l'appel de fonctions, les sorties structurées, la recherche web, la recherche sur X et l'exécution de code.

Notre aperçu de Grok 4.7 couvre le lancement et les benchmarks. SpaceXAI classe Chat Completions comme légué ; tous les exemples ici utilisent donc la Responses API.

Combien coûte Grok 4.7 ?

Sous 200 000 tokens d'invite, Grok 4.7 coûte 2 $ par million de tokens en entrée, 0,50 $ par million de tokens d'entrée mis en cache, et 6 $ par million de tokens en sortie. Une fois l'invite à 200 000 tokens, chaque token de cette requête est facturé 4 $, 1 $ et 12 $.

Les outils côté serveur sont facturés séparément : la page tarifs indique 5 $ par 1 000 recherches web ou appels d'exécution de code. Les recherches dans les documents joints coûtaient un centime chacune, et les documents stockés entraînent un coût quotidien par Gio. Utilisez une prompt_cache_key stable pour les requêtes liées, mais prévoyez du budget pour l'entrée non mise en cache.

Lisez le coût facturé via usage.cost_in_usd_ticks. La documentation de suivi des coûts précise qu'il inclut la mise en cache et les frais d'outils. Divisez la valeur par 10^10 pour obtenir des dollars.

Pourquoi tester Grok 4.7 sur la conception de circuits ?

La conception de circuits teste à la fois la lecture de documents, les calculs, l'usage d'outils et la vérification, dans une même tâche. SpaceXAI annonce 64,0 % pour Grok 4.7 sur EEBench. La méthodologie EEBench s'appuie sur des simulations et des contrôles de nomenclature (BOM) plutôt que sur le jugement d'un LLM, et EnviroNode suit la même logique.

Ce que nous allons construire : la relecture du circuit EnviroNode Rev A

EnviroNode Rev A est un nœud capteur alimenté par USB. Vous pouvez télécharger le projet complet sur GitHub.

Le schéma indique toutes les valeurs dont Grok a besoin pour la revue. Chaque exigence a un identifiant, comme PWR-002 ou BW-001, de sorte que chaque constat puisse renvoyer à une règle précise.

Schéma EnviroNode Rev A avec valeurs. Image de l'auteur.

Avant que Grok ne relise la carte, exposez toutes les règles que le vérificateur utilisera. La fonction renvoie cinq contrôles réussite/échec basés sur ces huit exigences :

• PWR-001 : l'entrée USB reste entre 4,75 V et 5,25 V
• PWR-002 : le régulateur couvre le pic de charge
• PWR-003 : les charges hors MCU utilisent un budget de 10 mA
• SIG-001 : le plein échelle du capteur est à 1,0 V
• ADC-001 : l'entrée ADC reste à ou sous 2 250 mV
• ADC-002 : l'entrée ADC atteint au moins 1 500 mV
• BW-001 : les signaux jusqu'à 100 Hz perdent moins de 1 dB
• BW-002 : la fréquence de coupure du filtre reste à ou sous 500 Hz

Le modèle reçoit le même jeu d'exigences. Aucune limite supplémentaire du vérificateur n'apparaît après que Grok a proposé un correctif.

Quels sont les trois défauts injectés ?

Trois défauts se vérifient numériquement. Leur nombre reste en dehors de l'invite.

• Régulateur sous-dimensionné (PWR-002) : le TI TLV700 est donné pour 200 mA, tandis que la fiche technique ESP32-C3 mentionne un pic d'émission Wi-Fi à 335 mA et la checklist de schéma d'Espressif recommande au moins 500 mA.

• ADC hors plage (ADC-001) : un gain de 3 amène 3,0 V à l'ADC, mais la plage effective de la fiche technique culmine à 2 500 mV, et l'exigence autorise 90 % de cette valeur.

• Filtre trop lent (BW-001) : 10 kΩ et 1 µF donnent une coupure à 15,9 Hz, alors que les signaux jusqu'à 100 Hz ne doivent pas perdre plus de 1 dB.

Le défaut ADC concerne la plage de mesure, pas un risque d'endommagement de broche. Des choix corrects, comme la résistance de LED et le retard CHIP_EN, rendent les faux positifs mesurables.

Comment fonctionne la boucle de relecture ?

La relecture exige une frontière nette : Grok propose des changements, tandis que Python statue sur réussite ou échec. Le schéma montre où les documents et outils s'insèrent dans cette boucle.

La boucle sépare la proposition de la vérification. Image de l'auteur.

Définissez la réussite avant le premier appel d'API. Ne comptabilisez un défaut que lorsque Grok le relie à une exigence et à une preuve. Ne comptabilisez un correctif que lorsque verify_design() renvoie all_pass = true.

Comment configurer l'API Grok 4.7 en Python

Il vous faut une clé d'API xAI avec des crédits prépayés, Python 3.10 ou plus récent, et le SDK Python OpenAI pointé sur l'URL de base de xAI. Créez la clé dans la console xAI, puis installez les paquets ci-dessous.

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install openai python-dotenv pydantic httpx streamlit
pip install matplotlib schemdraw pytest  # Optional diagrams and verifier tests

Les exemples d'API utilisent le premier groupe de paquets ; le second sert aux schémas et tests du dépôt. Je les ai testés avec Python 3.11.9, openai 3.19.2, pydantic 2.13.5, streamlit 1.64.0 et httpx 0.28.1. Enregistrez la clé dans la variable d'environnement XAI_API_KEY et chargez-la avec python-dotenv plutôt que de la placer en code source ; notre guide des environnements virtuels explique la configuration si c'est nouveau pour vous.

Faites votre premier appel à l'API Grok 4.7

Si votre clé fonctionne déjà avec la Responses API, passez à l'étape 1. Sinon, cette requête vérifie en une fois la clé, l'URL de base et l'ID de modèle.

import os
import httpx
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.environ["XAI_API_KEY"], base_url="https://api.x.ai/v1",
                timeout=httpx.Timeout(3600.0))

response = client.responses.create(
    model="grok-4.7",
    reasoning={"effort": "low"},
    input="In one sentence, what does a low-dropout regulator do?",
)
print(response.output_text)

Une réponse en une phrase signifie que la configuration est opérationnelle. Le long délai d'attente sera utile plus tard, car les requêtes avec raisonnement et outils peuvent prendre plusieurs minutes.

Étape 1 : Grok 4.7 peut-il relire un circuit à partir d'une image ?

Oui, Grok 4.7 peut relire un schéma à partir d'une image seule, à condition que l'invite annonce clairement qu'aucun outil ne sera utilisé. Le référentiel envoie le PNG en URL de données base64 avec le texte des exigences.

image = {
    "type": "input_image",
    "image_url": f"data:image/png;base64,{SCHEMATIC_B64}",
    "detail": "high",
}
response = client.responses.create(
    model="grok-4.7",
    input=[{"role": "user", "content": [
        image,
        {"type": "input_text", "text": REVIEW_PROMPT},
    ]}],
)

L'invite demande trois sections : confirmé, nécessite plus de preuves, et contrôlé et acceptable. Elle ne mentionne ni nombre de défauts ni composant suspect.

Qu'a trouvé la relecture à partir de l'image seule ?

Précisez explicitement au modèle qu'aucun outil ni aucune fiche technique n'est disponible. Sinon, il peut clore sa réponse après avoir annoncé une recherche de spécification à laquelle il n'a pas accès.

Comme indiqué dans l'aperçu, Grok a confirmé le défaut du filtre avec une coupure à 15,9 Hz et 16,1 dB de perte à 100 Hz. Il a placé le régulateur et l'ADC dans "nécessite des preuves" plutôt que de deviner leurs limites.

Étape 2 : comment ajouter des fiches techniques avec la Files API

Les documents joints transforment une inquiétude vague en affirmation étayée par des nombres. Téléversez chaque document une fois et référencez-le par son file_id.

with open(DATASHEET_PATH, "rb") as datasheet:
    uploaded = client.files.create(
        file=datasheet,
        purpose="assistants",
        expires_after={"anchor": "created_at", "seconds": 7 * 24 * 3600},
    )
content = [image, *[{"type": "input_file", "file_id": fid} for fid in file_ids],
           {"type": "input_text", "text": EVIDENCE_PROMPT}]

Parce que ce tutoriel fixe expires_after à sept jours, les IDs mis en cache ne sont valables que dans cette fenêtre. Sans expires_after, xAI conserve les fichiers téléversés jusqu'à suppression.

Dans les réponses du SDK OpenAI capturées ici, la recherche dans les pièces jointes apparaissait comme des éléments custom_tool_call nommés pdf_search et pdf_browse, tandis que l'usage les comptait sous document_search_calls. C'est un constétat empirique, pas un contrat générique d'outils ; la boucle vérifie donc aussi le compteur documenté d'utilisation.

Quel a été l'effet des fiches techniques ?

Les documents ont résolu les deux questions ouvertes de l'étape 1 et étayé les constats puissance, ADC et filtre. Le constat sur le régulateur cite le 200 mA du TLV700, le pic démission à 335 mA de l'ESP32-C3 et la recommandation d'alimentation à 500 mA.

Pour le filtre, Grok a déterminé quelles capacités respecteraient les deux règles de bande passante en gardant R5 inchangée : environ 32 à 81 nF. Tous les leurres sont arrivés dans "contrôlé et acceptable" avec justification.

Étape 3 : comment vérifier les calculs avec l'exécution de code Grok 4.7

L'exécution de code est le bac à sable Python côté serveur de xAI, ajouté à tools sous {"type": "code_interpreter"} quand vous utilisez le client OpenAI. L'invite ajoute une règle : toute affirmation numérique doit être calculée avant d'être considérée comme confirmée.

Le guide de l'exécution de code lié plus haut précise que le bac à sable n'a pas d'accès réseau et ne conserve pas d'état entre requêtes. Pour quelques valeurs de fiches techniques, c'est suffisant.

Quels calculs Grok doit-il vérifier ?

Demandez à Grok de vérifier le budget de puissance, la plage de l'ADC et la bande passante du filtre dans un seul script. Si les circuits ne sont pas votre sujet, passez la sortie ci-dessous ; la conclusion suit.

f=  100.0 Hz  |H|=0.157177  attenuation=16.0722 dB
fc required for <= 1 dB at 100 Hz: fc >= 196.5227 Hz
V_adc_fs = 3.0000 V
90% limit = 2.2500 V
required rating = max(headroom, mcu min) = 500.00 mA

La coupure minimale à 196,5 Hz est le chiffre sur lequel repose le correctif du filtre, et le code la calcule plutôt que de la laisser au calcul mental du modèle. Même dans le pire cas toléré en atténuation minimale, on perd plus de 15 dB à 100 Hz ; le verdict tient.

Étape 4 : Grok 4.7 peut-il rechercher sur le web via l'API ?

Oui. La recherche web vérifie si les documents joints sont toujours à jour, les fabricants révisant leurs fiches après la date de coupe d'entraînement d'un modèle. Limitez-vous aux domaines officiels pour rester sur des sources de première main.

tools = [
    {"type": "code_interpreter"},
    {"type": "web_search", "filters": {"allowed_domains": ["ti.com", "espressif.com"]}},
]

Le guide de recherche web lié plus haut autorise jusqu'à cinq allowed_domains, y compris les sous-domaines comme docs.espressif.com. Je garderais cette étape même si les fiches jointes sont à jour, car elle peut détecter une révision publiée après votre téléversement.

Que prouvent les citations ?

Grok doit citer la page produit TI actuelle, la documentation ESP32-C3, la checklist matérielle et toute errata pertinente. Considérez ces citations comme la preuve de la source, pas comme une garantie que la conclusion technique est exacte.

Des filtres de domaine peuvent tout de même renvoyer une page hors sujet. Vérifiez que chaque référence correspond exactement au composant et à la limite utilisés dans le calcul.

Grok cherche dans les fichiers, calcule, vérifie les sources. Image de l'auteur.

Étape 5 : comment ajouter un vérificateur avec l'appel de fonctions Grok 4.7

verify_design() est une simple fonction Python exécutée sur votre machine, et c'est l'unique arbitre du succès d'une révision. Grok propose des valeurs de conception via l'appel de fonctions, et la fonction les vérifie contre des limites fixes.

VERIFY_DESIGN_TOOL = {
    "type": "function",
    "name": "verify_design",
    "description": "Deterministically check an EnviroNode revision against EN-REQ-001...",
    "parameters": {
        "type": "object",
        "properties": {
            "revision": {"type": "string"},
            "regulator_part": {"type": "string"},
            "gain_rf_ohm": {"type": "number"},
            "gain_rg_ohm": {"type": "number"},
            "filter_r_ohm": {"type": "number"},
            "filter_c_nf": {"type": "number"},
        },
        "required": ["revision", "regulator_part", "gain_rf_ohm",
                     "gain_rg_ohm", "filter_r_ohm", "filter_c_nf"],
    },
}

La capacité de puissance doit respecter max((335 + 10) mA × 1.25, 500 mA). Pour l'ADC, 1.0 V × (1 + Rf/Rg) doit rester entre 1 500 et 2 250 mV. Les contrôles du filtre mesurent la perte à 100 Hz et plafonnent la coupure à 500 Hz ; chaque contrôle renvoie une valeur, une limite et réussite/échec.

Le schéma d'outil dit uniquement à Grok quelles valeurs envoyer. La logique cœur réussite/échec est du Python ordinaire :

import math

part = PARTS.get(regulator_part.strip().upper())
required_ma = max((335 + 10) * 1.25, 500)
power_ok = (
    part is not None
    and float(part["rated_iout_ma"]) >= required_ma
    and float(part["vin_max_v"]) >= 5.25
    and float(part["vout_v"]) == 3.3
)

gain = 1 + gain_rf_ohm / gain_rg_ohm
adc_mv = gain * 1000

fc = 1 / (2 * math.pi * filter_r_ohm * filter_c_nf * 1e-9)
loss_db = 10 * math.log10(1 + (100 / fc) ** 2)

checks = {
    "PWR-002": power_ok,
    "ADC-001": adc_mv <= 2250,
    "ADC-002": adc_mv >= 1500,
    "BW-001": loss_db <= 1.0,
    "BW-002": fc <= 500,
}
return {"all_pass": all(checks.values()), "checks": checks}

La fonction complète rejette aussi les valeurs invalides et renvoie des mesures avec chaque résultat. Testez-la avec une conception bonne connue, une mauvaise connue, un composant inconnu et un cas limite.

Pourquoi laisser le code, et non le modèle, noter le correctif ?

Gardez les spécifications des composants hors du contrôle du modèle. Je ne laisserais pas le modèle fournir lui-même un courant nominal. Grok envoie une référence de composant, et la fonction consulte la spécification dans le catalogue de l'application.

Un agent ne doit pas à la fois proposer une solution et juger de sa validité quand du code peut vérifier la réponse. Remplacez verify_design() par une batterie de tests ou une vérification de schéma si la tâche change. Écrire le vérificateur demande un effort supplémentaire, mais son verdict ne dépend pas de l'opinion du modèle.

Étape 6 : comment redéfinir et vérifier le circuit

Donnez à Grok un objectif : corriger chaque violation confirmée avec le plus petit ensemble de changements raisonnables, et ne pas déclarer la conception terminée tant que le contrôle défini plus tôt n'est pas réussi. Fournissez les preuves et outils des étapes 3 à 5, puis fixez une limite de requêtes.

C'est là que l'avertissement de contexte de l'aperçu compte. Réglez-le avant d'ajouter d'autres tours.

Pourquoi les boucles très chargées en fichiers nécessitent-elles une compaction du contexte ?

Une requête poursuivie inclut les résultats d'outils précédents, et les recherches documentaires peuvent renvoyer beaucoup de texte. Dans le prototype échoué, la poursuite suivante a atteint 1 116 321 tokens, dépassant la fenêtre de 500 000 de Grok 4.7.

La compaction du contexte ne peut pas sauver une requête déjà hors limite. La boucle corrigée compacte chaque tour avec recherche documentaire avant d'envoyer la requête suivante.

details = (response.usage.model_extra or {}).get(
    "server_side_tool_usage_details", {}
)
observed_attachment_call = any(
    item.type == "custom_tool_call"
    and item.name in {"pdf_search", "pdf_browse"}
    for item in response.output
)
used_documents = (
    details.get("document_search_calls", 0) > 0
    or observed_attachment_call
)

if used_documents:
    compacted = client.responses.compact(
        model="grok-4.7", input=history + list(response.output) + follow_up)
    history = list(compacted.output)  # pass the compaction item back unchanged
    # Compaction drops tool output, so restate the verifier's verdict ourselves.
    history.append({"role": "user", "content":
                    "verify_design results, exactly as returned: " + json.dumps(results)})
else:
    history = history + list(response.output) + follow_up
response = client.responses.create(model="grok-4.7", input=history, tools=TOOLS,
                                   store=False, prompt_cache_key=cache_key)

Conservez ce dernier append. La compaction supprime les sorties verbeuses d'outils, donc réitérer le résultat du vérificateur aide la réponse suivante à éviter des contrôles inventés ou confus. Compacter après chaque tour riche en documents est une cadence prudente ; un système plus grand peut utiliser un seuil de tokens en entrée.

La Rev B a-t-elle passé la vérification ?

Oui. Grok a changé un composant dans chaque sous-système en défaut : puissance, gain de l'ADC et bande passante du filtre. Le schéma montre les valeurs exactes des Rev A et Rev B.

Trois changements de composants corrigent la Rev A. Image de l'auteur.

Les valeurs révisées sont ensuite transmises à verify_design(), qui renvoie un résultat pour chaque exigence.

La conception révisée passe tous les contrôles. Image de l'auteur.

Un résultat d'échec revient en function_call_output, ce qui permet à Grok de revoir la conception jusqu'à ce que les contrôles passent ou que la limite de requêtes soit atteinte.

Étape 7 : comment renvoyer une relecture de circuit structurée

Les sorties structurées renvoient un objet conforme à un schéma, plutôt qu'un texte à parser. Appelez client.responses.parse() avec un modèle Pydantic dans la même conversation, et outils désactivés.

class Finding(BaseModel):
    violated_requirement: str
    severity: Literal["blocker", "major", "minor"]
    evidence: list[str]
    recommended_change: str
    verifier_result: Literal["pass", "fail", "not_verified"]

parsed = client.responses.parse(
    model="grok-4.7", input=history + [REPORT_REQUEST],
    text_format=DesignReview, tools=TOOLS, tool_choice="none", store=False,
)

Un schéma valide ne prouve pas que le fond est correct, donc incluez les résultats du vérificateur et demandez à Grok de baser verifier_result dessus. Le JSON peut ensuite alimenter un tracker d'anomalies ou une file d'approbation humaine.

Qu'a rapporté la revue structurée ?

Le rapport structuré doit marquer chaque défaut initial comme résolu, citer la valeur mesurée renvoyée par le vérificateur, et conserver les points non testés sous open_risks. Pour cette conception, cela inclut un régulateur exactement au plancher de 500 mA et un condensateur ADC différent de la recommandation d'Espressif.

Un effort de raisonnement plus élevé améliore-t-il la relecture ?

Un effort plus élevé n'a pas amélioré le score du vérificateur, mais il a changé la qualité du correctif du filtre. Chaque niveau a reçu le même schéma, la même invite, les mêmes outils et la même limite de requêtes.

low a réduit la résistance et conservé le condensateur de 1 µF, laissant hors du vérificateur le comportement en charge capacitive et la stabilisation. La note Microchip sur les charges capacitives indique qu'une résistance série peut améliorer la stabilité ; ce résultat ne prouve donc pas que le correctif est instable ; il appelle des tests de réponse en fréquence, échelon ou sur banc. high a changé le condensateur, tandis que xhigh a choisi les mêmes valeurs finales que high après un appel vérificateur supplémentaire.

Quand l'effort xhigh vaut-il la peine ?

Pour cette unique comparaison, high offrait le meilleur compromis. Il a évité l'inquiétude non modélisée de la charge sans l'appel vérificateur supplémentaire effectué par xhigh. Une seule exécution par niveau ne permet pas d'établir un classement général.

Grok 4.7 a-t-il corrigé le circuit ?

La réponse à la question d'ouverture est oui, dans le cadre des cinq contrôles du vérificateur. Le tableau condense les constats précédents en une vue.

• Image et exigences
  • Apport : inspection visuelle
  • Résultat : confirme ce que le schéma seul peut prouver
• Fiches techniques
  • Apport : limites fabricants
  • Résultat : convertit deux questions ouvertes en constats
• Exécution de code
  • Apport : calculs vérifiés
  • Résultat : mesure les problèmes de puissance et de filtre
• Recherche web
  • Apport : sources officielles à jour
  • Résultat : vérifie l'actualité des preuves jointes
• Vérificateur local
  • Apport : verdict Python réussite/échec
  • Résultat : n'accepte qu'une révision qui passe toutes les règles

Grok a corrigé les exigences encodées rédigées. Il n'a pas prouvé que la carte révisée était électriquement exhaustive ou prête pour la production.

Les documents décident si une inquiétude a des preuves. Python décide si une révision passe. Une belle prose ne remplace ni l'un ni l'autre.

Regardez la relecture dans Streamlit

Notre guide Streamlit présente l'interface utilisée ici. Elle s'appuie sur le streaming pour afficher les appels d'outils au fil de l'eau, puis montre les contrôles du vérificateur et le rapport final.