Self-Training-LLM boundary

Type: agentic-system-analyses/types/agentic-system-boundary.md

Boundary and evidence

The target is the repository's model-improvement workflow, not a general agent runtime. It is in scope because its shipped generation and evaluation stages issue model calls, and its training stage consumes the resulting data to produce model checkpoints. Its intended use is to build and compare Wikipedia-grounded SFT and DPO models. The class is builder or improvement plane; the boundary is whole-system, covering the shipped source workflow from topic/document selection through persisted data, filtering, training, checkpoint consumption and evaluation. This classification does not imply an autonomous, continuously scheduled improvement loop. Operators launch the separate shell/Python stages and, for TGI, select and serve the model (SRC-1, README.md, script/wiki_ques_gen.sh, script/train.sh, script/testing.sh, script/tgi.sh).

The repository explicitly connects data generation with model training:

• wiki_ques_gen.sh- generates both SFT and DPO dataset as well as performing knowledge filtering
• train.sh - SFT and DPO --- README.md

The producer persists scored answer records; the training driver reloads them and selects preference samples. The training implementation saves a checkpoint, and the response-generation driver selects configured SFT/DPO checkpoint paths for subsequent inference. These are shipped responsibilities inside the target, not excluded callers (SRC-1, uncertainty/wiki_generation.py, uncertainty/train.py, uncertainty/self_learning_training.py, uncertainty/generate_response.py). Two implementation anchors establish the persisted-data handoff:

all_scored_instances = get_scored_ds(ans_dict,'raw_answer_sample') with open(answer_path,'wb') as f: pickle.dump(all_scored_instances,f) --- uncertainty/wiki_generation.py

with open(dataset_path,'rb') as f: dataset = pickle.load(f) --- uncertainty/train.py

Evaluation is included: generated responses are saved as JSONL, then paired with baseline responses and source documents for a model judge; judge decisions have a reloadable disk cache (SRC-1, uncertainty/generate_response.py, uncertainty/pairwise_eval.py, uncertainty/scorer.py). The evaluator's model selection is explicit:

llm_judge = LLMJudge(engine = "gpt-4o") --- uncertainty/pairwise_eval.py

Shipped-path coverage

The table accounts for every top-level tracked file or directory. Inclusion describes the functional evidence boundary, not a claim that every line has already been analysed. Initial inspection traced all four shipped shell entry points, their Python drivers, retained-data consumers and evaluation consumer. Helper algorithms and prompt/example bodies remain available for detailed analyst inspection at the same pin.

Frozen evidence and limits

The source is the acquired Git checkout at 97839b29d0fd8bb474f5549fa3e9d6ca504732e0, verified against checkout HEAD. The applicability cutoff is 2026-10-15, the supplied run date; it is not a claim that the source is current upstream. Overall evidence is code-grounded: source inspection plus attributed repository documentation, with no target execution or causal experiment.

External dependencies include Wikipedia data obtained through Hugging Face datasets, pretrained language models and tokenizers, NLI models, OpenAI generation/judging, optional TGI serving, and training frameworks/GPU infrastructure. Their internal implementations and live behavior are excluded. This prevents attributing provider reliability, dataset truth, pretrained capabilities or trainer internals to this repository. The repository's adapters, prompts, configuration and launcher remain included (SRC-1, requirements.txt, configs/data/wiki.yaml, uncertainty/data_utils.py, uncertainty/wiki_generation.py, uncertainty/scorer.py, script/tgi.sh). External URLs mentioned by the README are not separately acquired sources.

No model weights, generated datasets, evaluation outputs, provider transcripts or execution traces were supplied as frozen run evidence. Their absence prevents claims of successful end-to-end execution, measured improvement, factual accuracy, reproducibility or observed deployment behavior. A complete boundary therefore means the functional source boundary has been established, not that operational success has been demonstrated.

Source register