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 → validated answers
      │
      ▼
Student: question only → adapter weight updates
      │
      ▼
Validate without source → save candidate → activate

The diagram describes the implemented Convex workflow and Tinker execution 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 workflow 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 a new memory, the teacher checks each generated answer against the source before training starts. The student learns concise answers in both plain text and JSON, with only the question in its prompt. Training also teaches the model where its visible answer begins and ends.

Updates to an existing memory use a separate refinement recipe: the teacher answers with access to the new source, and the student learns its answer distribution without that source. Both paths use a rank-16 LoRA adapter. These 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 workflow 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 workflow 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.