dayoon/LiveLedger-4B

LiveLedger-4B

LiveLedger-4B is the ledger-update module of LiveLedger, an epistemic agent framework for answering multi-constraint questions with iterative web search and structured evidence tracking.

LiveLedger decomposes a question into atomic constraints and maintains an Epistemic Ledger — a (candidate × constraint) table whose cells record whether a candidate satisfies a constraint and the evidence for that verdict. Keeping this bookkeeping in an explicit structure, rather than in the agent's context window, is what lets the agent stay coherent over long search trajectories.

Running the ledger update with the frontier search model is expensive: it is called after every search step. LiveLedger-4B is a small, distilled specialist that takes over exactly that step. It is supervised-fine-tuned on ledger-update trajectories produced by gpt-oss-120b, so a large model drives search while this 4B model does the per-step evidence bookkeeping.

This is not a general-purpose chat or search model. It is trained for one job: read search results and emit an update_ledger tool call. Used outside that harness, its behaviour is undefined.

Model details

The base checkpoint is multimodal and the vision tower is carried over unmodified — only the language-model weights were fine-tuned. LiveLedger is a text-only pipeline; the vision weights are kept solely so the checkpoint stays loadable as a stock Qwen3.5-4B.

Training

Full-parameter SFT (no LoRA) with DeepSpeed ZeRO-3 + optimizer offload.

Data. Tool-calling trajectories distilled from gpt-oss-120b LiveLedger rollouts on HDS-QA and MultiConIR-books: 2,885 update_ledger examples and 1,393 constraint-extraction examples. After dropping examples over 8,192 tokens the corpus is ~3.7K, split 90/10 into train/validation.

Released checkpoint. The run was scheduled for 10 epochs (260 steps) but validation loss bottoms out early and rises steadily afterwards, so the released weights are step 52 (epoch 2):

Step 26 has a marginally lower loss, but step 52 has higher token accuracy and is the checkpoint used for every reported LiveLedger result.

Usage

vLLM (how it is actually served)

The ledger model runs as its own endpoint alongside the search model. Tool-call and reasoning parsers are required — the agent reads the structured update_ledger call, not free text.

vllm serve dayoon/LiveLedger-4B \
  --port 8100 \
  --tensor-parallel-size 1 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3 \
  --max-num-seqs 16

Transformers

import torch
from transformers import AutoTokenizer, Qwen3_5ForConditionalGeneration

model_id = "dayoon/LiveLedger-4B"
tok = AutoTokenizer.from_pretrained(model_id)
model = Qwen3_5ForConditionalGeneration.from_pretrained(
    model_id, dtype=torch.bfloat16, device_map="auto"
)

tools = [{
    "type": "function",
    "function": {
        "name": "update_ledger",
        "description": (
            "Record evidence in the ledger based on search results.\n\n"
            "Each entry records evidence for ONE constraint of ONE candidate.\n"
            "Only include entries where new evidence was found."
        ),
        "parameters": {
            "type": "object",
            "properties": {
                "entries": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "properties": {
                            "candidate":    {"type": "string"},
                            "constraint":   {"type": "string"},
                            "obj":          {"type": "boolean"},
                            "obj_evidence": {"type": "string"},
                        },
                        "required": ["candidate", "constraint", "obj", "obj_evidence"],
                    },
                }
            },
            "required": ["entries"],
        },
    },
}]

messages = [
    {"role": "system", "content": "You are a careful and thorough ledger update assistant."},
    {"role": "user", "content": (
        "Constraints:\nC1: Directed by Christopher Nolan\nC2: Released in 2010\n\n"
        "Current ledger: {}\n\n"
        "Search results: 'Inception is a 2010 science fiction film written and "
        "directed by Christopher Nolan.'\n\nUpdate the ledger."
    )},
]

text = tok.apply_chat_template(messages, tools=tools, tokenize=False, add_generation_prompt=True)
inputs = tok(text, return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=512, do_sample=False)
print(tok.decode(out[0][inputs.input_ids.shape[1]:], skip_special_tokens=False))

The model reasons about the search results, then emits an update_ledger call whose entries set obj: true/false per (candidate, constraint) pair with a supporting obj_evidence quote.

Intended use and limitations

Intended use. The ledger-update step of a LiveLedger-style agent: given constraints, the current ledger, a search query and its retrieval results, decide which (candidate, constraint) cells the new evidence settles.

Limitations.

• —Narrow specialist. Fine-tuned on a single tool-calling format. It is not a chat assistant and will not behave like the Qwen3.5-4B it came from on general tasks.
• —Trained in English on English web content.
• —Evidence is extracted, not verified. The model reports what retrieved text asserts. Wrong, stale or adversarial sources propagate into the ledger as confident verdicts.
• —Distillation ceiling. Behaviour is bounded by the gpt-oss-120b trajectories it learned from, including their errors.
• —Small training corpus (~3.7K examples) drawn from two source datasets; out-of-domain constraint types are less reliable.
• —Vision inputs are untested. The vision tower is inherited, never fine-tuned, and never exercised in LiveLedger.

License

Apache 2.0, inherited from `Qwen/Qwen3.5-4B`. The bundled LICENSE file is the base model's.