How learning works

Internalize uses context distillation to train an adapter for GLM 5.3. A teacher sees a source passage and demonstrates how to answer questions about it. A student is trained on those questions without seeing the source in its prompt. The resulting adapter carries the learned behavior into later inference.

The learning pathCopy Anchor Link

Source knowledge
      │
      ▼
Grounded questions + held-out checks
      │
      ▼
Teacher: source + question → answer distribution
      │
      ▼
Student: question only → adapter weight updates
      │
      ▼
Validate without source → save candidate → activate

The diagram describes the implemented worker pipeline. It is not a live execution trace or a claim about an example's measured accuracy. Hosted execution availability is tracked separately.

1. Build a grounded curriculumCopy Anchor Link

The worker compiles training questions and held-out questions from the submitted passage. Each generated example includes an expected answer and a supporting excerpt. The compiler checks that evidence is an exact substring of the source and that questions are not duplicated.

Questions are intended to cover recall, paraphrases, applications, and combinations of supplied facts. A passage with contradictions or missing definitions can make this stage fail. The service does not fetch a linked website or infer missing pages on your behalf: the content string is the learning source.

2. Learn from the teacherCopy Anchor Link

For each training question, the teacher receives the source and question. Its answer is checked against the grounded example. The worker scores the answer distribution and trains the student with the question but without the source passage in the student prompt.

The current implementation uses a rank-16 LoRA adapter and a top-20 distribution distillation recipe. Those are implementation details, not customer-tunable request fields. The public API accepts knowledge and an activation choice; it does not accept optimizer settings, rank, or an arbitrary training dataset.

For a new subject, the adapter starts from base. For an existing subject, the worker loads the selected parent version's weights into a fresh training client. This preserves an explicit version lineage while avoiding shared optimizer state between subjects.

3. Save and validateCopy Anchor Link

The worker saves private inference and training checkpoints, verifies their ownership and retention, and evaluates held-out questions against the candidate without the source in context. A passing candidate can be registered as a version; a rejected candidate does not replace the active model.

The job exposes the validation decision and counts. The threshold and curriculum size belong to the deployed recipe, so read the returned totals rather than assuming a fixed number of checks. Generated validation is a useful gate, but your product should also have its own evaluation set.

4. Route subsequent inferenceCopy Anchor Link

After activation, a new inference request for the same subject resolves to the adapter. The messages you submit are the inference context. Internalize does not retrieve or append the original learning passage to make the answer work.

An adapter is learned model state, not a lossless document store. It can generalize, misremember, or answer outside the source. Keep exact records in your own system when you need citations, authoritative wording, or current transactional data. Use evaluation to measure the behavior that matters to your application.

For the state transitions around this pipeline, read Job lifecycle. For rollout and rollback, read Versions and routing.