The Assistant Boundary: Instruction Tuning, Safety, and Deployment
Code Llama - Instruct is a different kind of specialization from the Python and long-context branches: it changes how the model participates in a human interaction. This chapter traces the added instruction and self-instruct data, then examines what the paper’s safety benchmarks, red-team exercises, and model card reveal about the boundary between a capable code generator and a dependable assistant. The practical judgment is cautious by design: safer measured behavior is valuable, but it does not remove the need to test code, prompts, refusals, and deployment conditions in the application that will use the model.
A base Code Llama model can generate code when the prompt and output format are arranged for it. An assistant must do more. It must infer what a person means, follow a requested format, decide how to respond when a request is ambiguous or risky, and avoid turning a plausible answer into an unjustified claim of correctness. These behaviors are not guaranteed by the fact that the underlying model has seen a great deal of code.
Instruction tuning changes the assistant’s objective
Code Llama - Instruct is based on Code Llama and receives approximately 5 billion additional instruction-tuning tokens. The paper describes two major sources. One is the instruction dataset used for Llama 2, containing supervised fine-tuning and rejection-sampling examples with both helpfulness and safety data. The other is a coding-oriented self-instruct dataset made with model-generated questions, tests, and solutions. A small rehearsal share of code and natural-language data is retained to reduce regression in general coding and language understanding.
The self-instruct process is best understood as a selection loop rather than as a pile of automatically trusted answers. The authors first prompt Llama 2 70B to create about 62,000 interview-style programming questions and deduplicate them to about 52,000. For each question, Code Llama 7B generates unit tests and ten Python solutions. The tests are run against those candidates, and the first solution that passes is retained with its question and tests. The final dataset contains about 14,000 question-test-solution triplets.
This sequence adds an important signal. The model is not trained only on an instruction followed by a stylistically acceptable response; it also receives examples that survived an execution check. That can encourage the requested output format and make it more likely that an answer resembles a runnable solution. In the reported ablation, removing the self-instruct data lowers HumanEval and MBPP performance and makes the requested format for the zero-shot MBPP task less reliable.
The reduction from roughly 52,000 deduplicated questions to roughly 14,000 retained triplets is part of the method’s meaning. The final examples are not a random sample of all generated questions; they are questions for which the chosen generation procedure found a passing candidate. That makes execution feedback useful as a selection signal, but it also means the retained set reflects the tests that were generated and the order in which candidates were tried. The model learns from a curated subset shaped by those choices. It is therefore more accurate to say that the process filters for test-passing examples than to say that it automatically creates a complete curriculum of programming knowledge.
The use of ten candidates per question also illustrates why the data pipeline and evaluation loop should not be confused. Searching over candidates can find a solution that a single greedy generation would miss.