Templates and versions

A prompt is a part of the program

In the lessons before this one, each prompt was one long text. You made a new version with +. That works for a lesson. In a real program, it causes problems.

• The same sentence is in many places. You change it in one place, and you forget the other places.
• Nobody knows which text gave which result.
• A small edit goes to the users with no test.

Treat a prompt as you treat code.

Build the prompt from parts

Keep each part in one place: the task, each rule, each example. One function builds the complete text from the parts.

RULE = "A comment that asks something is a question."

prompt = build_prompt([RULE], [])

Now a new version is a new list of parts. You can try a version with one rule less, or with the rules in another order, and you do not copy any text.

Give each version a name

Store the versions in a dictionary, with a name for each. Store the result of the test set under the same name.

Version	What it has	Accuracy on the dev set
v1	The task and the form of the answer.	66.7
v2	And the rule about questions.	75.0

A table of this kind is the history of the prompt. It tells you and your team why each part is there. When a part does not make the result better, take it out. A shorter prompt costs less.

A change to the prompt is a change to the program

Run the test set before a new version goes to the users, as you run the tests of your code. Many teams keep their prompts in the repository of the code. Then each change to a prompt has a date, an author, and a review.

Your turn

main.py has the parts of the prompt, the functions run and accuracy, and the function example_block of lesson 5. The results come from the simulated model, as in the lessons before. Do the tasks in order.