Prompt Engineering met 3CX: Deel 1

Je AI Agent heeft geen manifest nodig. Hij heeft een duidelijke, ondubbelzinnige specificatie nodig. Zo schrijf je die.

Onlangs hebben we de systeemprompt van onze AI Receptionist volledig herschreven. De vorige versie was 450 regels lang, prachtig gestructureerd en gevuld met zorgvuldig uitgewerkte beleidsregels. Het probleem? De prompt gebruikte zoveel van het contextvenster dat de agent minder ruimte had om daadwerkelijk naar de beller te luisteren. Om te voorkomen dat jij dezelfde fout maakt, leggen we in dit blog uit hoe je stopt met het schrijven van poëzie en begint met het schrijven van instructies. Dit is Deel 1 van een tweeluik; Deel 2 volgt binnenkort.

De fout die iedereen als eerste maakt

Wij zijn niet de enigen die deze fout maakten. Vrijwel iedere 3CX-klant die voor het eerst een systeemprompt bewerkt, doet hetzelfde: de prompt behandelen als een beleidsdocument, juridisch contract of – nog erger – een creatieve schrijfopdracht.

Daar zit de valkuil. Omdat prompts in gewone taal worden geschreven, vergeten mensen dat ze in feite code schrijven. Ze schrijven lange paragrafen, voegen bijvoeglijke naamwoorden toe, definiëren termen die het model al begrijpt en herhalen dezelfde instructie vijf keer omdat die belangrijk voelt.

Maar een AI-model leest tekst niet zoals mensen dat doen. Elk woord in je prompt kost context, aandacht en vaak ook consistentie. Een lange prompt is niet zorgvuldiger. Meestal is hij juist minder effectief.

Deze gids bevat de lessen die wij hebben geleerd tijdens het herschrijven van onze eigen prompt. Als je de systeemprompt van een 3CX AI Agent aanpast, lees dit dan voordat je op Opslaan klikt.

De valkuil van natuurlijke taal

Toen prompt engineering nog betekende dat je instructies in ruwe JSON naar een API stuurde, werd het gezien als een technische discipline. Nu instructies in gewone taal worden geschreven, behandelen veel mensen ze alsof ze een berichtje sturen naar een nieuwe collega.

Neem bijvoorbeeld deze passage uit onze oude prompt:

“The caller’s reason is required before handoff, but it must not be used to identify, narrow, rank, disambiguate, replace, or override the requested destination.”

Grammaticaal correct, zorgvuldig geformuleerd en vrijwel onmogelijk om consequent te volgen tijdens een echt gesprek. Zes bijna synonieme termen. Twee bijzinnen. Een ontkenning verpakt in een vereiste. Tegen de derde interactie interpreteert het model de zin anders dan bij de eerste.

Dit werd uiteindelijk:

“Do not use information search to decide who should receive a call.”

Eén zin. Eén instructie. Geen ambiguïteit. Hetzelfde gedrag.

Regel 1: Engels is de interface, niet het genre. Je schrijft nog steeds instructies. Kort. Duidelijk. Testbaar. Als een zin klinkt alsof hij uit algemene voorwaarden komt, verwijder hem dan en probeer het opnieuw.

Stop met dingen definiëren voor het model

Onze oude prompt bevatte ooit deze parel:

“A handoff is any permitted next step executed via one of the actions listed below.”

Het model weet al wat een handoff is. Het begrijpt ook termen als *transfer*, *voicemail* en *email*. Het opnieuw definiëren van alledaagse begrippen is een gewoonte uit technische documentatie voor mensen. In een prompt verspilt het alleen tokens en creëert het extra ruimte voor misinterpretatie.

Hetzelfde geldt voor formele sectiekoppen zoals:

• Mandatory Enforcement
• Priority Order
• Base Schema
• Action Selection Rules

Dit klinkt alsof het uit een RFC-document komt, maar het verandert niets aan het gedrag van het model. In de nieuwe prompt gebruiken we eenvoudige koppen zoals: Style, Routing en Hostility.  Korte labels die aangeven waar de sectie over gaat, zonder overdreven gewicht toe te kennen.

Regel 2: Als een regel het gedrag van het model niet verandert, verwijder hem.

Zeg het één keer

Een van de grootste problemen bij lange prompts is dat dezelfde regel op meerdere plaatsen terugkomt. In onze oude versie verscheen de regel *”do not hand off if the destination is ambiguous”* in verschillende varianten onder:

• Destination Ambiguity Rule
• Handoff Action Gate
• Directory Rules
• Confidential Output Contract

Voor een mens zijn dit vier formuleringen van hetzelfde idee. Voor een AI-model zijn het vier afzonderlijke regels. En als ze niet exact hetzelfde zijn, moet het model kiezen welke regel voorrang krijgt. Soms maakt het die keuze anders in gesprek drie dan in gesprek één.

Regel 3: Elke regel hoort op precies één plaats thuis. Als je een regel moet versterken door hem ergens anders te herhalen, heb je geen extra sectie nodig. Je hebt een betere eerste formulering nodig.

Stop met stapelen van verboden

Kijk naar deze instructie:

“Do not pick the first result, best result, available result, or most relevant result.”

Dat zijn vier negatieve instructies terwijl één positieve instructie voldoende is.

Wat de regel eigenlijk bedoelt:

“If lookup returns multiple matches, ask the caller to clarify.”

Positieve instructies vertellen het model wat het moet doen.

Negatieve instructies vertellen alleen wat het niet mag doen, waardoor de vraag open blijft wat het dan wél moet doen. Het model zal vervolgens zelf een antwoord bedenken.

Regel 4: Geef de voorkeur aan positieve instructies. Gebruik “niet doen” alleen als er geen positief alternatief bestaat.

Let op tegenstrijdigheden

Dit is de stille moordenaar van prompt engineering.

Onze oude prompt bevatte twee regels die afzonderlijk logisch waren, maar samen voor verwarring zorgden:

• Routing op basis van reden: wanneer de beller een reden geeft, gebruik het adresboek om een bestemming te bepalen.
• Routing op basis van gewenste bestemming: wanneer de beller expliciet om een persoon of afdeling vraagt, gebruik de reden niet voor de routering.

Beide regels zijn correct. Beide zijn redelijk. Maar in een lange prompt met overlappende voorbeelden en aanvullende subregels wordt het voor het model onduidelijk welke regel van toepassing is. Dat resulteert in inconsistent gedrag dat klanten vaak niet reproduceerbaar krijgen.

Gebruik bijvoorbeeld de OpenAI Tokenizer om te zien hoe een model je prompt daadwerkelijk opsplitst in tokens. Lees vervolgens de prompt opnieuw alsof je niets weet van je bedrijf. Als twee regels mogelijk op dezelfde situatie van toepassing zijn en tot verschillende acties leiden, dan heb je een tegenstrijdigheid – zelfs als jij kunt uitleggen waarom ze volgens jou niet conflicteren.

Regel 5: Een prompt is pas consistent wanneer geen twee regels tegelijk van toepassing kunnen zijn én verschillende uitkomsten opleveren. Niet wanneer jij het verschil kunt rationaliseren.

Binnenkort: Deel 2

In de komende dagen publiceren we Deel 2 van deze serie. Daarin gaan we dieper in op wat AI-modellen wel en niet kunnen, delen we praktische tips voor beginnende prompt engineers en bespreken we hoe je betere resultaten haalt uit je AI Agents. Blijf ons volgen!

Praat mee

Neem deel aan de discussie in onze speciale Partner– of Klanten Forums. Volg ons op X en LinkedIn om op de hoogte te blijven van het laatste nieuws, productupdates en nieuwe functies.