> For the complete documentation index, see [llms.txt](https://ai.mrw0l05zyn.cl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ai.mrw0l05zyn.cl/general/prompt-engineering.md).
# Prompt engineering
## Introducción
La calidad de las respuestas de un LLM depende directamente de la calidad del prompt. Un prompt vago, incompleto o ambiguo puede generar respuestas especulativas, inconsistentes o poco útiles. En cambio, un prompt bien estructurado permite obtener resultados más precisos, verificables y alineados con el objetivo de la tarea.
## Componentes clave de un prompt efectivo
No existe un único orden válido para todos los modelos, pero una estructura común y efectiva es:
{% code overflow="wrap" %}
```mermaid
flowchart LR
A["Rol
Quién responde"] --> B["Instrucción
Qué debe hacer"]
B --> C["Restricciones
Bajo qué límites"]
C --> D["Ejemplos
Qué formato imitar"]
D --> E["Datos
Qué debe analizar"]
```
{% endcode %}
Esta estructura permite definir quién debe "ser" el modelo, qué debe hacer, bajo qué límites debe trabajar, qué formato debe imitar y sobre qué información debe basarse.
### **Rol (role)**
El rol define la perspectiva desde la cual debe responder el modelo. Asignar un rol ayuda a activar patrones de conocimiento específicos y a ajustar el tono, nivel de detalle y profundidad de la respuesta.
{% code overflow="wrap" %}
```
Eres un especialista en pentesting que está llevando a cabo una fase de reconocimiento.
Eres un analista de ciberseguridad que revisa los resultados de una herramienta durante un "security assessment".
```
{% endcode %}
{% hint style="info" %}
Un rol efectivo debe ser específico. No es lo mismo decir "eres un experto en seguridad" que "eres un penetration tester realizando una fase de reconocimiento sobre servicios expuestos". **Mientras más claro sea el rol, más alineada será la respuesta.**
{% endhint %}
### **Instrucción (instruction)**
La instrucción define la tarea concreta que el modelo debe realizar. Debe ser clara, directa y sin ambigüedad.
{% code overflow="wrap" %}
```
Analiza el siguiente escaneo de Nmap e identifica los posibles riesgos de seguridad en función de los servicios y las versiones de software.
Revisa la siguiente respuesta HTTP y sugiere los siguientes pasos de enumeración en función de las tecnologías identificadas.
```
{% endcode %}
{% hint style="info" %}
Una buena instrucción debe responder a la pregunta: **¿Qué quiero que haga exactamente el modelo?**
{% endhint %}
### **Restricciones (constraints)**
Las restricciones delimitan el alcance de la respuesta, el formato esperado y las reglas que el modelo debe seguir. Son especialmente importantes para reducir alucinaciones y evitar que el modelo invente información.
{% code overflow="wrap" %}
```
Los vectores de ataque de denegación de servicio (DoS) quedan fuera del alcance de este análisis.
Distingue claramente entre los datos confirmados y las suposiciones.
Mantén la respuesta concisa y estructurada.
Utiliza únicamente los datos proporcionados. No hagas suposiciones.
Si no hay datos disponibles, indica "Unknown".
```
{% endcode %}
### **Ejemplos (examples)**
Los ejemplos muestran al modelo cómo debe responder. Son especialmente útiles cuando la tarea requiere un formato específico, una estructura estricta o una forma particular de razonar.
Un ejemplo puede incluir una entrada y una salida esperada. Esto permite que el modelo imite el patrón presentado.
```markdown
# INPUT
[ARTIFACT] Nmap scan
- Target: 10.0.0.1
- Content:
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.5
[/ARTIFACT]
# OUTPUT
[EXPECTED_OUTPUT]
{
"services": [
{
"asset": "10.0.0.1",
"port": 21,
"protocol": "tcp",
"state": "open",
"service": "ftp",
"version": "vsftpd 3.0.5",
"risk": [
"FTP may transmit credentials in plaintext unless protected with TLS",
"Verify whether anonymous access is permitted"
],
"evidence": [
"21/tcp open ftp vsftpd 3.0.5"
]
}
]
}
[/EXPECTED_OUTPUT]
```
{% hint style="info" %}
Los ejemplos deben ser consistentes, breves y representar correctamente el formato esperado. **Un mal ejemplo puede afectar negativamente la calidad de la respuesta.**
{% endhint %}
### **Datos (data)**
Los datos son el artefacto que el modelo debe analizar. Pueden ser salidas de herramientas, respuestas HTTP, logs u otro tipo de información técnica. Es recomendable que incluyan metadatos asociados, como nombre del artefacto, objetivo y contenido, y que estén claramente delimitados mediante YAML, XML o encabezados de texto para evitar ambigüedad, especialmente cuando se entregan múltiples artefactos.
{% code overflow="wrap" %}
```markdown
[ARTIFACT] Nmap scan 1
- Target: 10.0.0.1
- Content:
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.5
[/ARTIFACT]
[ARTIFACT] Nmap scan 2
- Target: 10.0.0.2
- Content:
PORT STATE SERVICE VERSION
80/tcp open http
[/ARTIFACT]
```
{% endcode %}
## In Context Learning (ICL)
Es una técnica en la que el modelo aprende cómo responder a una tarea usando ejemplos incluidos dentro del mismo prompt. Es decir, no se entrena nuevamente al modelo, sino que se le muestran patrones de entrada y salida para que los imite en la respuesta. ICL es útil cuando queremos guiar el comportamiento del modelo, mejorar la precisión y reducir errores de formato.
### Zero-shot prompting
Consiste en pedirle al modelo que realice una tarea sin darle ejemplos previos. El prompt solo incluye el rol, la instrucción, las restricciones y los datos que debe analizar. Es útil para tareas simples o flexibles, como resumir texto, generar ideas o crear listas. Sin embargo, puede producir respuestas menos consistentes, especialmente si se requiere un formato de salida estricto.
### One-shot / few-shot prompting
**One-shot prompting** significa darle al modelo un solo ejemplo de cómo debe responder antes de pedirle que resuelva la tarea real. **Few-shot prompting** es similar, pero incluye varios ejemplos. Estas técnicas ayudan al modelo a entender mejor el formato esperado, el estilo de respuesta y cómo manejar casos especiales. Son especialmente útiles cuando se necesita una salida consistente, estructurada o fácil de validar, como JSON, tablas Markdown o reportes con secciones específicas.
## Ejemplo de prompt efectivo
{% code overflow="wrap" %}
```markdown
You are a penetration tester performing reconnaissance.
Analyze the following Nmap scan output and identify:
- Open ports and associated services.
- Potential security risks based on service versions.
- If a field is not explicitly present, output null.
- Provide evidence for each claim.
- Use only the information provided. Do not make assumptions.
Output only the results in a JSON object adhering to the following schema:
{
"services": [
{
"asset": "",
"port": 0,
"protocol": "",
"state": "",
"service": "",
"version": null,
"risk": [],
"evidence": []
}
]
}
---
# EXAMPLE 1
## INPUT
[ARTIFACT] Nmap scan
- Target: 10.0.0.1
- Content:
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.5
[/ARTIFACT]
## OUTPUT
[EXPECTED_OUTPUT]
{
"services": [
{
"asset": "10.0.0.1",
"port": 21,
"protocol": "tcp",
"state": "open",
"service": "ftp",
"version": "vsftpd 3.0.5",
"risk": [
"FTP may transmit credentials in plaintext unless protected with TLS",
"Verify whether anonymous access is permitted"
],
"evidence": [
"21/tcp open ftp vsftpd 3.0.5"
]
}
]
}
[/EXPECTED_OUTPUT]
---
# EXAMPLE 2
## INPUT
[ARTIFACT] Nmap scan
- Target: 10.0.0.2
- Content:
PORT STATE SERVICE VERSION
80/tcp open http
[/ARTIFACT]
## OUTPUT
[EXPECTED_OUTPUT]
{
"services": [
{
"asset": "10.0.0.2",
"port": 80,
"protocol": "tcp",
"state": "open",
"service": "http",
"version": null,
"risk": [
"Unencrypted HTTP traffic"
],
"evidence": [
"80/tcp open http"
]
}
]
}
[/EXPECTED_OUTPUT]
---
# TASK
Analyze the following Nmap scan output:
[ARTIFACT] Nmap scan 1
- Target: 10.0.0.3
- Content:
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.5
80/tcp open http nginx 1.30.3
443/tcp open ssl/http nginx 1.30.3
[/ARTIFACT]
[ARTIFACT] Nmap scan 2
- Target: 10.0.0.4
- Content:
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.68 (Ubuntu)
443/tcp open ssl/http Apache httpd 2.4.68 (Ubuntu)
[/ARTIFACT]
```
{% endcode %}
## Refinamiento iterativo de respuestas
El refinamiento iterativo consiste en mejorar progresivamente una respuesta generada por AI mediante revisiones y solicitudes de ajuste específicas. En lugar de aceptar la primera salida del modelo como definitiva, se analiza si contiene errores, suposiciones, afirmaciones sin evidencia, problemas de formato o desviaciones del alcance. Luego, se le pide al modelo que corrija esos puntos para obtener una respuesta más clara, precisa, verificable y alineada con el objetivo de la tarea.
El ciclo básico es:
1. Ejecutar un prompt inicial.
2. Revisar la respuesta.
3. Identificar qué falta o qué está mal.
4. Pedir una versión refinada.
5. Repetir si es necesario.
Ejemplos de refinamiento:
```
¿Qué suposiciones hiciste en tu respuesta?
¿Qué información está directamente respaldada por la evidencia y cuál corresponde a inferencias?
Para cada afirmación, indica el nivel de confianza: alto, medio o bajo.
Propón 3 explicaciones alternativas y pasos concretos para verificar o descartar cada hipótesis.
```