Szablon • Projektowanie interakcji

Matryce i szablony promptów

Jak utrzymywać promptowanie jak inżynierię: matryca doboru wzorca, kontrakt formatu, wersjonowanie i testy regresji.

Powiązane: Biblioteka promptów Powiązane: Golden set

Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Projektowanie interakcji i ma formę Szablon. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

Ustal cel i kryteria poprawności (co znaczy „dobry wynik”).
Zamknij format wyjścia (JSON / tabela / sekcje) i przygotuj walidację.
Ogranicz przestrzeń odpowiedzi: instrukcje, słownik terminów, limity.
Dodaj kontrolę jakości: self-check, sanity-checks, fallback, „no-answer”.
Zapisz jako szablon (prompt_template) i wersjonuj jak kod.
Wprowadź testy regresyjne (golden set) i przeglądy po zmianach.

Najczęstsze pułapki

Mieszanie instrukcji z danymi wejściowymi (brak separacji „co” vs „na czym”).
Format wynikowy „opisowy” bez kontraktu – brak automatycznej kontroli.
Zbyt ogólne polecenia („napisz mądrze”) bez parametrów i ograniczeń.
Brak strategii na niepewność: model zaczyna „zgadywać” zamiast eskalować.

Artefakty w Luage

prompt_template output_contract policy:language.standard trace_id golden_set

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

W skrócie

Matryca wybiera szablon na podstawie zadania i ryzyka.
Szablon to kontrakt: instrukcja + format + kryteria + no‑answer.
Wersjonowanie (SemVer) i testy regresji są równie ważne jak treść promptu.
Jeden repozytorium prawdy: biblioteka promptów + changelog + owner.

1. Po co matryce i szablony

W firmie prompt nie jest „tekstem”. Jest interfejsem pomiędzy intencją biznesową a mechaniką modelu. Bez matryc i szablonów promptowanie szybko zamienia się w kolekcję przypadków.

Skalowalność: nowy zespół dostaje gotowy wzorzec zamiast „tajemnej wiedzy”.

Jakość: ten sam kontrakt formatu można walidować i testować.

Bezpieczeństwo: łatwiej wbudować bramki (citations, DLP, no‑answer).

2. Matryca doboru szablonu

Typ zadania	Szablon (kontrakt)	Kryteria sukcesu	Ryzyko / bramki
Ekstrakcja danych formularze, faktury, CRM	JSON Schemanull‑safe	poprawne typy • kompletność • brak ozdobników	DLP • walidacja • retry z naprawą formatu
Q&A z wiedzy helpdesk, dokumentacja	citationsno‑answer	atrybucja • zgodność • styl firmowy	RAG/GraphRAG • gating dowodowy • eskalacja
Redakcja / styl teksty, e‑maile, polityki	style‑lintdiff	zgodność ze standardem • spójność • brak skrótów	approval (dla high‑stakes) • rejestr wyjątków
Planowanie z narzędziami agent, workflow	tool contractReAct	bezpieczne wywołania • deterministyka	Tool Gateway • allowlist • timeouts

3. Zestaw bazowych szablonów

Poniżej jest generator, który wybiera jeden z bazowych kontraktów. W praktyce każdy szablon powinien mieć: owner, wersję, testy i changelog.

Generator szablonu

Zachowaj jako prompt@ver w bibliotece.

Szablon (prompt)

Kontrakt odpowiedzi

4. Wersjonowanie i testy

Szablony są wartościowe wtedy, gdy da się je utrzymać. Minimum:

SemVer: patch/minor/major zgodnie z wpływem na konsumentów (workflow, narzędzia, dokumenty).

Golden set: zestaw przypadków, które muszą przechodzić zawsze.

Regresje: porównanie jakości i kosztu (tokeny, latencja) po zmianie.

Changelog: jawny opis zmiany i decyzji.