====== Introduction to Generative AI: Prompt Engineering ======

**Note:** the commonly used term is **prompt engineering** (not "engenering"). This article introduces prompt engineering for generative AI models and is written for a technical audience (hackers, builders, and curious tinkerers). It explains core concepts, practical techniques, example patterns, tooling, evaluation strategies, and ethical/security considerations — all formatted for DokuWiki.

===== What is Prompt Engineering? =====
Prompt engineering is the craft of designing, structuring, and tuning inputs (prompts) for generative models to steer their outputs toward desired behavior. For text LLMs it includes:
  * phrasing user instructions,
  * providing context and constraints,
  * seeding the model with examples (few-shot),
  * controlling generation parameters (temperature, max tokens),
  * organizing multi-turn interactions (system/user/assistant roles),
  * and building prompt chains or pipelines for complex tasks.

Good prompt engineering reduces iteration time, increases reliability, and helps align outputs with safety and quality requirements.

===== Core principles and mental models =====

  * **Be explicit.** Models follow instructions literally. If you need a format, example, or constraint, state it.
  * **Fix the output format.** When you need predictable parsing, require JSON / CSV / tabular output and supply an exact example.
  * **Provide context, not noise.** Give necessary background, but keep prompts concise — too-long, irrelevant context can cause drift.
  * **Use few-shot examples for behavior.** Demonstrate desired inputs → outputs to bias style and content.
  * **Break hard tasks into smaller steps.** Use decomposition: plan → act → verify (chain-of-thought or tool-chained pipeline).
  * **Specify evaluation criteria.** Tell the model how you will judge the answer (e.g., accuracy, brevity, source citation).
  * **Iterate quickly and measure.** Small edits often produce outsized changes; treat prompts as code under version control.
  * **Prefer constraints over heuristics.** Use tokens, headings, and explicit rules rather than vague language like "be concise".

===== Typical prompt anatomy =====
A robust prompt generally contains:
  * **System / high-level instruction** (model role & constraints)
  * **Context / background** (short facts, relevant data)
  * **Task / instruction** (clear desired action)
  * **Format / output spec** (exact structure, examples)
  * **Optional examples** (few-shot demonstrations)
  * **Evaluation rules** (how to handle unknowns or hallucinations)

<code>
Example skeleton (pseudocode):
System: You are a concise assistant that answers factually.
User: Context: <short facts>
User: Task: <what to do>
User: Output: return JSON with keys ["summary","confidence","sources"]
User: If unknown, respond with {"error":"unknown"}.
</code>

===== Common prompt patterns (with use-cases) =====

  * **Instruction + Constraints** — for deterministic outputs.
    <code>
    Summarize the following text in <=50 words. Use bullet points. Do not invent facts.
    </code>

  * **Few-shot (Examples)** — for style mimicry or structured outputs.
    <code>
    Example 1:
    Q: What is a rabbit?
    A: A small mammal that hops.
    Example 2:
    Q: What is a crow?
    A: A black bird known for mimicry.
    Now answer: Q: What is a fox?
    </code>

  * **Chain-of-Thought prompting** — ask model to reason step-by-step then give answer.
    *Use cautiously: increases transparency but may leak model internal reasoning and increases token usage.*
    <code>
    Think step-by-step, list assumptions, then give the final answer.
    </code>

  * **Role / Persona** — make the model adopt a viewpoint.
    <code>
    You are a senior security engineer. Review this architecture and list 5 potential attack vectors.
    </code>

  * **Output-constrained (machine-friendly)** — for downstream parsing.
    <code>
    Output must be valid JSON: {"vulns":[{"name":...,"severity":...}], "notes":"..."}
    </code>

  * **Refusal / safety policy** — instruct the model what NOT to do.
    <code>
    If the task requests personally identifiable info (PII), refuse with "I cannot provide PII".
    </code>

===== Practical workflow (iterate like a hacker) =====

  1. **Define success criteria.** What does "good" look like? (precision, format, speed)
  2. **Start minimal.** Create the shortest prompt that could work.
  3. **Test with representative inputs.** Use real or edge-case examples.
  4. **Add constraints and examples** to fix misbehaviors.
  5. **Measure outputs.** Use automatic checks (parsing, unit tests) where possible.
  6. **Version prompts.** Track prompt changes and performance.
  7. **Automate A/B testing.** Compare prompt variants on a dataset.
  8. **Monitor for drift.** Models or data distribution can change; re-evaluate prompts periodically.

===== Important model knobs explained =====

  * **Temperature** — controls randomness. 0.0 = deterministic, 0.7 = creative, higher = more variance.
  * **Top_p (nucleus sampling)** — alternative to temperature that samples from top cumulative probability mass.
  * **Max tokens / length** — cap output size.
  * **Stop sequences** — tell the model where to stop generation.
  * **System message** — high-level persona/instruction that often has highest priority.
  * **Few-shot examples** — seed behavior via examples in the prompt.

===== Advanced techniques =====

  * **Prompt chaining (pipelines):** Break tasks across multiple specialized prompts. Example: extraction → transformation → summarization.
  * **Tool use & grounding:** Combine LLM output with deterministic tools (calculators, regex, search) to avoid hallucinations.
  * **Self-ask and verification:** Ask model to generate an answer and then verify it against constraints or a reference model.
  * **Tree of thought / multi-path search:** Branch on multiple candidate reasoning paths (advanced research technique).
  * **In-context retrieval:** Supply relevant chunks from a vector DB or knowledge store and instruct model to use only those chunks.
  * **Response voting / ensemble:** Generate N outputs and pick best via a scoring function or a verifier model.
  * **Instruction tuning patterns:** Use examples to show desired format and penalties for undesirable elements.

===== Safety, ethics, and security =====

  * **Hallucination risk:** LLMs can invent facts. Mitigate by constraining outputs, requiring citations, and verifying with authoritative sources.
  * **Data leakage:** Don’t include secrets, private PII, or proprietary data in prompts unless the environment is controlled and secure.
  * **Adversarial inputs:** Be aware that attackers can craft prompts or inputs to induce unsafe behaviors. Validate and sanitize user inputs.
  * **Misuse potential:** Access control and usage policies are essential; consider rate limits, auditing, and human-in-the-loop gating for dangerous outputs.
  * **Bias and fairness:** Model outputs can reflect training data bias. Test prompts across demographic variations and add fairness constraints where needed.
  * **Legal/regulatory:** Treat outputs as assistance; for high-stakes domains (medical, legal, financial) enforce human validation and cite sources.

===== Common pitfalls and how to avoid them =====

  * **Vague instructions** → give examples and precise format.
  * **Over-long prompts** → keep necessary context; use retrieval for long contexts.
  * **Relying on implied knowledge** → explicitly state assumptions and definitions.
  * **Using chain-of-thought to extract secrets** → chain-of-thought can reveal internal model behavior; avoid when privacy is a concern.
  * **No validation** → always validate outputs for format, safety, and factuality.

===== Example prompts with annotations =====

1) Simple summarization (human-friendly)
<source lang="text">
Task: Summarize the following article in 5 bullet points, each <= 20 words.
Article: <paste article here>
Constraint: Do not add facts not present in the article.
</source>

2) JSON-constrained vulnerability scan (machine-friendly)
<source lang="text">
System: You are a security assistant.
User: Given the text below, extract potential security issues and return valid JSON only with keys:
{ "issues": [{"id":1,"title":"", "description":"", "severity":"low|medium|high", "evidence":"" }], "meta":{"source":""} }
If none, return {"issues":[], "meta":{"source":""}}.
Text: <paste architecture notes>
</source>

3) Few-shot style mimicry
<source lang="text">
You are a copywriter. Match the tone and brevity of these examples.

Example 1:
Q: What is X?
A: X is the smallest useful unit.

Example 2:
Q: What is Y?
A: Y helps make Z faster.

Now: Q: What is "prompt engineering"?
Answer:
</source>

4) Multi-step decomposition (planning + execution)
<source lang="text">
Step 1: List 3 approaches to clean noisy logs.
Step 2: For the best approach, provide a 5-step implementation plan with commands.
Only after Step 1 is done, show Step 2.
</source>

===== Testing & evaluation strategies =====

  * **Automatic checks:** parse JSON, validate schema, run regex checks, measure length limits.
  * **Ground-truth comparison:** compute BLEU/ROUGE or exact-match against a labeled dataset where available.
  * **Human evaluation:** have raters score outputs for accuracy, style, and usefulness.
  * **Regression tests:** keep failing examples as tests and prevent prompt changes from re-introducing failures.
  * **Edge-case fuzzing:** feed weird/contradictory inputs to find fragile behavior.

===== Tooling & workflow integration =====

  * **Local iteration:** use small, fast models or sandboxed endpoints for dev iteration before scaling to production models.
  * **Versioning prompts:** treat prompts like code — store in git with tests and changelogs.
  * **Monitoring:** capture model outputs and user feedback; log hallucinations and refusals.
  * **Human-in-the-loop:** route uncertain or high-risk outputs to a human reviewer.
  * **RAG:** connect to a vector DB to fetch grounding passages and pass them as context for factual answers.

===== Templates & cheat sheet =====

  *Summarize template (short):*
<source lang="text">
System: You are a concise summarizer.
User: Summarize the text below into 3 bullet points (each <=25 words). If the text contains no factual claims, reply "No facts".
Text: <paste here>
</source>

  *Extract template (JSON):*
<source lang="text">
System: You are a structured extractor.
User: Extract "name", "date", "amount" from this receipt. Output JSON only. If a field is missing, put null.
Receipt: <paste here>
</source>

  *Critic / reviewer template:*
<source lang="text">
System: You are an expert reviewer in <domain>.
User: Provide 5 numbered critiques, each with a suggested fix and a severity (low/med/high).
Text: <paste here>
</source>

===== Glossary (short) =====
  * **Prompt** — the input given to a model.
  * **System message** — high-level instruction that sets model behavior.
  * **Few-shot** — including examples in the prompt.
  * **Temperature / top_p** — sampling hyperparameters.
  * **Hallucination** — fabricated statements not grounded in data.
  * **RAG** — retrieval-augmented generation (grounding responses via external content).

===== Final notes for hackers =====
Prompt engineering is both art and engineering. Treat prompts as software: minimal reproducible examples, tests, version control, CI for prompts, and monitoring in production. Combine LLM creativity with deterministic tools for reliability. Keep safety and privacy at the core of any deployment.

===== Appendix: quick checklist before shipping a prompt =====
  * Does the prompt have a clear task and output format?
  * Are hallucination risks minimized by grounding or verification?
  * Do we handle missing / unknown data explicitly?
  * Are there automated validators for expected output?
  * Is logging, access control, and rate limiting in place?
  * Are we compliant with privacy/regulatory requirements for the domain?

===== Want more? =====
If you want, I can:
  * Provide a set of real-world test cases (CSV) you can use to benchmark prompts.
  * Convert templates above into a tiny prompt-testing harness (Python + requests).
  * Produce attack examples that show common prompt-injection risks (for red-team testing).