Tutorial de la API Grok 4.7: crea un revisor de diseño de circuitos con IA

Un esquema de circuito es un diagrama que muestra cómo se conectan los componentes electrónicos. Revisarlo implica comprobar si los componentes y sus valores cumplen los requisitos de diseño. ¿La fuente de alimentación puede suministrar suficiente corriente? ¿El procesador puede leer toda la señal del sensor? Las respuestas salen del esquema, de las hojas de datos de los componentes y de unos cuantos cálculos.

Quería ver si Grok 4.7 podía completar toda esa revisión. La guía de Grok 4.7 dice que el modelo se entrenó para tareas largas y para comprobar su propio trabajo con más cuidado. Un circuito también nos da números que el Python normal puede verificar, así que no hace falta otro modelo de IA para juzgar el resultado.

Para el experimento, construí EnviroNode Rev A, una pequeña placa de sensores alimentada por USB, y planté tres fallos en su diseño. Grok no sabe cuántos fallos hay. Tiene que encontrarlos, respaldar cada hallazgo con documentación de componentes, proponer correcciones y someter los valores corregidos a comprobaciones en Python.

No necesitas formación en ingeniería electrónica para seguirlo. Explico cada regla de circuito cuando aparece por primera vez. Aprenderás a:

• Enviar una imagen del esquema a Grok 4.7 mediante la Responses API

• Adjuntar datasheets con la Files API y dejar que Grok las busque

• Comprobar cálculos con ejecución de código y límites con búsqueda web

• Dar a Grok una función local verify_design() que decida si pasa o falla

• Mantener una conversación larga y llena de documentos dentro del límite de contexto del modelo

• Devolver un formato de revisión coherente y luego comparar niveles de razonamiento

La misma placa permanece en escena desde la primera revisión de imagen hasta la comprobación final en Python.

Resumen

Grok 4.7 identificó todos los fallos plantados cuando tuvo las hojas de datos, y el diseño corregido superó las comprobaciones en Python. Eso dice algo sobre estos tres fallos, no sobre las revisiones de circuitos en general.

• Sin documentos, Grok no se aventuró a adivinar: la imagen por sí sola dio un defecto confirmado, y los límites del regulador y del convertidor analógico-digital (ADC) quedaron en "requiere evidencia".
• Las hojas de datos convirtieron la sospecha en evidencia: cada hallazgo citó un valor de documento, sin señalar piezas correctas como defectuosas.
• Las iteraciones con muchos archivos pueden agotar el contexto: tras búsquedas repetidas en PDFs, una continuación superó la ventana de 500K; el bucle corregido compacta antes del siguiente turno.
• Low pasó el verificador pero dejó ver un punto ciego: sus valores de filtro cumplieron las comprobaciones escritas, dejando sin probar el comportamiento con carga capacitiva y el asentamiento.

Es una placa pequeña, no un benchmark. Una placa con una docena de hojas de datos generará un contexto mayor y puede dar resultados distintos.

¿Qué es la API Grok 4.7?

La API Grok 4.7 ofrece a las apps en Python entrada de texto e imagen, salida de texto y una ventana de contexto de 500.000 tokens mediante el ID de modelo grok-4.7. La guía oficial enumera niveles de razonamiento low, medium, high (por defecto) y xhigh; el razonamiento no se puede desactivar. La API también admite llamadas a funciones, salidas estructuradas, búsqueda web, búsqueda en X y ejecución de código.

Nuestro resumen de Grok 4.7 cubre el lanzamiento y los benchmarks. SpaceXAI marca Chat Completions como heredado, así que todos los ejemplos usan la Responses API.

¿Cuánto cuesta Grok 4.7?

Por debajo de 200.000 tokens de prompt, Grok 4.7 cuesta 2 $ por millón de tokens de entrada, 0,50 $ por millón de tokens de entrada en caché y 6 $ por millón de tokens de salida. Cuando un prompt alcanza 200.000 tokens, todos los tokens de esa petición se facturan a 4 $, 1 $ y 12 $.

Las herramientas del lado del servidor tienen tarifas aparte: la página de precios cobra 5 $ por cada 1.000 llamadas de búsqueda web o ejecución de código. Las búsquedas en documentos adjuntos cuestan un céntimo cada una, y los documentos almacenados tienen un cargo diario por GiB. Usa una prompt_cache_key estable para peticiones relacionadas, pero reserva presupuesto para entrada no cacheada.

Lee el coste facturado de usage.cost_in_usd_ticks. La documentación de seguimiento de costes indica que incluye la caché y las herramientas. Divide el valor entre 10^10 para obtener dólares.

¿Por qué probar Grok 4.7 con diseño de circuitos?

El diseño de circuitos pone a prueba lectura de documentos, cálculos, uso de herramientas y verificación en una sola tarea. SpaceXAI reporta un 64,0 % para Grok 4.7 en EEBench. La metodología EEBench usa simulaciones y comprobaciones de la BOM en lugar de un juez LLM, y EnviroNode sigue la misma idea.

Qué vamos a construir: la revisión del circuito EnviroNode Rev A

EnviroNode Rev A es un nodo de sensores alimentado por USB. Puedes descargar el proyecto completo desde GitHub.

El esquema incluye todos los valores que Grok necesita para la revisión. Cada requisito tiene un ID como PWR-002 o BW-001, así que cada hallazgo puede referirse a una regla concreta.

Esquema de EnviroNode Rev A con valores. Imagen del autor.

Antes de que Grok revise la placa, expón todas las reglas que usará el verificador. La función devuelve cinco comprobaciones de pasa/no pasa construidas a partir de estos ocho requisitos:

• PWR-001: La entrada USB se mantiene entre 4,75 V y 5,25 V
• PWR-002: El regulador cubre la carga pico
• PWR-003: Las cargas que no son del MCU usan un presupuesto de 10 mA
• SIG-001: La escala completa del sensor es 1,0 V
• ADC-001: La entrada del ADC se mantiene en o por debajo de 2.250 mV
• ADC-002: La entrada del ADC alcanza al menos 1.500 mV
• BW-001: Las señales hasta 100 Hz pierden menos de 1 dB
• BW-002: La frecuencia de corte del filtro se mantiene en o por debajo de 500 Hz

El modelo recibe el mismo conjunto de requisitos. Ningún límite del verificador aparece sólo después de que Grok proponga una solución.

¿Cuáles son los tres defectos plantados?

Tres fallos se pueden comprobar con números. Su cantidad no aparece en el prompt.

• Regulador insuficiente (PWR-002): el TI TLV700 está nominal a 200 mA, mientras que la datasheet del ESP32-C3 indica un pico de transmisión Wi‑Fi de 335 mA y la lista de comprobación de esquemas de Espressif pide al menos 500 mA.

• ADC fuera de rango (ADC-001): una ganancia de 3 pone 3,0 V en el ADC, pero el rango efectivo de la hoja de datos llega a 2.500 mV, y el requisito permite el 90 % de eso.

• Filtro demasiado lento (BW-001): 10 kΩ y 1 µF dan un corte de 15,9 Hz, mientras que las señales hasta 100 Hz pueden perder como mucho 1 dB.

El defecto del ADC afecta al rango de medida, no a dañar el pin. Las elecciones correctas, como la resistencia del LED y el retardo de CHIP_EN, hacen medibles los falsos positivos.

¿Cómo funciona el bucle de revisión?

La revisión necesita un límite claro: Grok propone cambios, mientras que Python decide si pasa o falla. El diagrama muestra dónde entran documentos y herramientas en ese bucle.

El bucle de revisión separa propuesta y verificación. Imagen del autor.

Define el éxito antes de la primera llamada a la API. Cuenta un defecto sólo cuando Grok lo vincula a un requisito y a evidencia de apoyo. Cuenta una corrección sólo cuando verify_design() devuelve all_pass = true.

Cómo configurar la API Grok 4.7 en Python

Necesitarás una clave de API de xAI con créditos prepago, Python 3.10 o superior y el SDK de Python de OpenAI apuntando a la URL base de xAI. Crea la clave en la xAI Console y luego instala los paquetes usados abajo.

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

Los ejemplos de la API usan el primer grupo de paquetes; el segundo sirve para diagramas del repositorio y tests. Los probé con Python 3.11.9, openai 3.19.2, pydantic 2.13.5, streamlit 1.64.0 y httpx 0.28.1. Guarda la clave en la variable de entorno XAI_API_KEY y cárgala con python-dotenv en vez de ponerla en el código fuente; nuestra guía de entornos virtuales explica la configuración si es nueva para ti.

Haz tu primera llamada a la API de Grok 4.7

Si tu clave ya funciona con la Responses API, salta al Paso 1. Si no, esta petición comprueba la clave, la URL base y el ID de modelo de una vez.

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)

Una respuesta en una frase significa que la configuración funciona. El timeout largo importa más adelante, porque las peticiones con razonamiento y herramientas pueden tardar varios minutos.

Paso 1: ¿Puede Grok 4.7 revisar un circuito a partir de una imagen?

Sí, Grok 4.7 puede revisar un esquema sólo con una imagen, siempre que el prompt deje claro que no habrá herramientas. La línea base envía el PNG como una URL de datos base64 junto con el texto de requisitos.

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},
    ]}],
)

El prompt pide tres secciones: confirmado, requiere más evidencia y revisado y aceptable. No menciona el número de defectos ni una pieza sospechosa.

¿Qué encontró la revisión sólo con imagen?

Indícale explícitamente al modelo cuando no hay herramientas ni datasheets disponibles. De lo contrario, podría terminar la respuesta diciendo que buscará una especificación a la que no puede acceder.

Como se señala en el resumen, Grok confirmó el defecto del filtro con un corte de 15,9 Hz y 16,1 dB de pérdida a 100 Hz. Colocó el regulador y el ADC en "requiere más evidencia" en lugar de adivinar sus límites.

Paso 2: cómo añadir hojas de datos con la Files API

Los documentos adjuntos convierten una preocupación vaga en una afirmación respaldada por números. Sube cada documento una vez y haz referencia por su 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}]

Como este tutorial fija expires_after en siete días, los IDs en caché sólo son válidos en esa ventana. Sin expires_after, xAI conserva los archivos subidos hasta que los borres.

En las respuestas del SDK de OpenAI capturadas aquí, la búsqueda en adjuntos apareció como elementos custom_tool_call llamados pdf_search y pdf_browse, mientras que el uso los contaba bajo document_search_calls. Eso es comportamiento observado, no el contrato general de tipos de herramientas, así que el bucle también comprueba el contador documentado de uso.

¿Cómo cambian las datasheets la revisión?

Los documentos resolvieron las dos dudas del Paso 1 y respaldaron los hallazgos de potencia, ADC y filtro. El hallazgo del regulador citó la nominal de 200 mA del TLV700, el pico de 335 mA del ESP32-C3 y la recomendación de 500 mA.

Para el filtro, Grok calculó qué valores de condensador cumplirían ambas reglas de ancho de banda dejando R5 igual: aproximadamente entre 32 y 81 nF. Cada señuelo quedó en "revisado y aceptable" con su motivo.

Paso 3: cómo verificar cálculos con la ejecución de código de Grok 4.7

La ejecución de código es el sandbox de Python del lado del servidor de xAI, que se añade a tools como {"type": "code_interpreter"} cuando usas el cliente de OpenAI. El prompt añade una regla: toda afirmación con un número debe calcularse antes de contar como confirmada.

La guía de ejecución de código enlazada indica que el sandbox no tiene acceso a red y no mantiene estado entre peticiones. Para unos pocos números de datasheet, es suficiente.

¿Qué cálculos debe comprobar Grok?

Pídele a Grok que compruebe presupuesto de potencia, rango del ADC y ancho de banda del filtro en un único script. Si los circuitos no son lo tuyo, omite la salida; el mensaje clave va después.

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

El corte mínimo de 196,5 Hz es el número del que depende la corrección del filtro, y el código lo calcula en lugar de dejarlo a la aritmética del modelo. Incluso en la esquina de tolerancias de menor atenuación se pierde más de 15 dB a 100 Hz, así que el veredicto se mantiene.

Paso 4: ¿puede Grok 4.7 buscar en la web mediante la API?

Sí. La búsqueda web comprueba si los documentos adjuntos siguen vigentes, ya que los fabricantes revisan datasheets tras la fecha de corte de entrenamiento del modelo. Restringe a dominios oficiales para que la evidencia sea de primera mano.

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

La guía de búsqueda web enlazada permite hasta cinco allowed_domains, incluidos subdominios como docs.espressif.com. Mantendría este paso incluso cuando las datasheets adjuntas estén al día, porque puede detectar una revisión publicada después de tu subida.

¿Qué demuestran las citas?

Grok debería citar la página actual del producto de TI, la documentación del ESP32‑C3, la checklist de hardware y cualquier errata relevante. Trata esas citas como evidencia de la fuente, no como prueba de que la conclusión de ingeniería es correcta.

Los filtros por dominio pueden devolver una página irrelevante. Comprueba que cada cita respalda exactamente el componente y el límite usados en el cálculo.

Grok busca en archivos, calcula y contrasta fuentes. Imagen del autor.

Paso 5: cómo añadir un verificador con llamadas a funciones de Grok 4.7

verify_design() es una función de Python que se ejecuta en tu máquina, y es la única que decide si una revisión pasa. Grok propone valores de diseño mediante function calling, y la función los contrasta con límites fijos.

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 capacidad de potencia debe cumplir max((335 + 10) mA × 1.25, 500 mA). Para el ADC, 1.0 V × (1 + Rf/Rg) debe quedar entre 1.500 y 2.250 mV. Las comprobaciones del filtro miden la pérdida a 100 Hz y limitan el corte a 500 Hz; cada check devuelve un valor, un límite y si pasa o falla.

El esquema de la herramienta sólo le dice a Grok qué valores enviar. La lógica central de pasa/no pasa es Python normal:

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 función completa también rechaza valores no válidos y devuelve mediciones con cada resultado. Pruébala con un diseño bueno conocido, uno malo, un componente desconocido y un caso al límite.

¿Por qué debe calificar la corrección el código y no el modelo?

Mantén las nominales de componentes fuera del control del modelo. Yo no dejaría que el modelo aportara su propia corriente nominal. Grok envía una referencia de pieza y la función consulta la nominal en el catálogo de la aplicación.

Un agente no debería proponer una solución y decidir si es correcta cuando el código puede comprobar la respuesta. Sustituye verify_design() por una batería de tests o una validación de esquema si cambia la tarea. Escribir el verificador lleva trabajo extra, pero su resultado de pasa o falla no depende de la opinión del modelo.

Paso 6: cómo rediseñar y verificar el circuito

Dale a Grok un único objetivo: arreglar todas las violaciones confirmadas con el conjunto mínimo razonable de cambios y no dar el diseño por terminado hasta que pase la comprobación definida antes. Proporciona la evidencia y herramientas de los Pasos 3 a 5 y fija un límite de peticiones.

Aquí es donde importa la advertencia de contexto del resumen. Resuélvelo antes de añadir más turnos.

¿Por qué los bucles con muchos archivos necesitan compactación de contexto?

Una petición continuada incluye resultados de herramientas anteriores, y las búsquedas en documentos pueden devolver mucho texto. En el prototipo fallido, la siguiente continuación alcanzó 1.116.321 tokens y superó la ventana de 500.000 de Grok 4.7.

La compactación de contexto no puede salvar una petición que ya está por encima del límite. El bucle corregido compacta cada turno exitoso de búsqueda en documentos antes de enviar la siguiente petición.

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)

Conserva ese último append. La compactación elimina la salida prolija de herramientas, así que reiterar el resultado del verificador ayuda a la siguiente respuesta a evitar checks inventados o confusos. Compactar tras cada turno cargado de documentos es un ritmo conservador; un sistema mayor puede usar un umbral de tokens de entrada.

¿Pasó Rev B la verificación?

Sí. Grok cambió una pieza en cada subsistema que fallaba: potencia, ganancia del ADC y ancho de banda del filtro. El diagrama muestra los valores exactos de Rev A y Rev B.

Tres cambios de componentes corrigen Rev A. Imagen del autor.

Los valores revisados van después a verify_design(). Devuelve un resultado por cada requisito.

El diseño revisado supera todas las comprobaciones. Imagen del autor.

Un resultado fallido vuelve como function_call_output, así que Grok puede revisar el diseño hasta que las comprobaciones pasen o se alcance el límite de peticiones.

Paso 7: cómo devolver una revisión de circuito estructurada

Las salidas estructuradas devuelven un objeto que cumple un esquema en lugar de un texto que tengas que parsear. Llama a client.responses.parse() con un modelo de Pydantic en la misma conversación, con las llamadas a herramientas desactivadas.

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 esquema válido no prueba que el contenido sea correcto, así que incluye los resultados del verificador y pide a Grok que base verifier_result en ellos. El JSON puede alimentar un gestor de incidencias o una cola de aprobación humana.

¿Qué informó la revisión estructurada?

El informe estructurado debe marcar cada defecto original como resuelto, citar el valor medido devuelto por el verificador y mantener preocupaciones no probadas en open_risks. En este diseño, esas preocupaciones incluyen un regulador justo en el umbral de 500 mA y un condensador del ADC distinto a la recomendación de Espressif.

¿Mejora la revisión de circuitos un mayor esfuerzo de razonamiento en Grok 4.7?

Un mayor esfuerzo no mejoró la puntuación del verificador, pero sí cambió la calidad de la corrección del filtro. Cada nivel recibió el mismo esquema, prompt, herramientas y límite de peticiones.

low redujo la resistencia y mantuvo el condensador de 1 µF, dejando fuera del verificador el comportamiento con carga capacitiva y el asentamiento. La guía sobre cargas capacitivas de Microchip dice que una resistencia en serie puede mejorar la estabilidad, así que este resultado no prueba que la corrección sea inestable; pide analizar la respuesta en frecuencia, la respuesta al escalón o pruebas de banco. high cambió el condensador, mientras que xhigh eligió los mismos valores finales que high tras una llamada extra al verificador.

¿Cuándo merece la pena el razonamiento xhigh?

En esta comparación, high dio el mejor equilibrio. Evitó la preocupación por la carga no modelada sin la llamada extra al verificador que hizo xhigh. Una ejecución por nivel no establece un ranking general.

¿Arregló Grok 4.7 el circuito?

La respuesta a la pregunta inicial es sí, dentro de las cinco comprobaciones del verificador. La tabla resume los hallazgos anteriores en una sola vista.

• Imagen y requisitos
  • Aporta: inspección visual
  • Resultado: confirma lo que el esquema por sí solo puede demostrar
• Datasheets
  • Aporta: límites del fabricante
  • Resultado: convierte dos dudas en hallazgos
• Ejecución de código
  • Aporta: cálculos verificados
  • Resultado: mide los problemas de potencia y filtro
• Búsqueda web
  • Aporta: fuentes oficiales actuales
  • Resultado: comprueba si la evidencia adjunta está al día
• Verificador local
  • Aporta: pasa o falla desde Python
  • Resultado: acepta sólo una revisión que pase todas las reglas

Grok corrigió los requisitos codificados. No demostró que la placa revisada estuviera eléctricamente completa ni lista para producción.

Los documentos deciden si una preocupación tiene evidencia. Python decide si una revisión pasa. La prosa fluida no sustituye a ninguno de los dos.

Mira la revisión en Streamlit

Nuestra guía de Streamlit explica la interfaz usada aquí. Utiliza streaming para mostrar las llamadas a herramientas en tiempo real y luego los checks del verificador y el informe final.