makeitwork-1 (v13)

A 500M parameter decoder-only transformer (LLaMA-style architecture) fine-tuned for codebase information retrieval with multi-hop search reasoning and tool-calling.

Model Details

  • Architecture: Retriever500M (custom LLaMA-style decoder)
  • Parameters: ~497M
  • Hidden dim: 1,280
  • Layers: 23
  • Attention heads: 20
  • FFN dim: 3,456 (SwiGLU)
  • Positional encoding: RoPE
  • Normalization: RMSNorm
  • Tied embeddings: Yes
  • Vocab size: 32,009 (with special tokens)
  • Checkpoint: sft_v13 (step 1000, EMA loss 0.1500)

Capabilities

The model acts as an autonomous code search agent. Given a natural language query about a codebase, it:

  1. Reasons about the query using <|reasoning|> to decompose it into subqueries
  2. Searches the codebase using <|search|> tokens β€” can perform multi-hop search (search β†’ inspect results β†’ refine search)
  3. Analyzes <|result|> blocks returned by the retrieval system
  4. Returns curated <|evidence|> with the relevant code snippet, file path, and symbol name
  5. Terminates cleanly with <|finish|>

The multi-hop capability allows the model to handle vague queries (e.g. "find a function that does something"), indirect queries (e.g. "function that calls X", "function involving testing"), and stemmed queries (e.g. "function involving parsing" β†’ searches "parse") by first searching a broad keyword, extracting the specific symbol name from the results, and then searching for that exact name.

Special Tokens

Token ID Purpose
`< system >`
`< user >`
`< assistant >`
`< search >`
`< result >`
`< evidence >`
`< reasoning >`
`< finish >`
`< end >`

Benchmark: Code Search Eval v5

Overview

The model is evaluated on a held-out test set of 50 code search queries spanning multiple programming languages and query types. The eval set was constructed from 20 open-source repositories covering Python, Rust, Go, C, TypeScript, Java, and JavaScript.

Query Types

The benchmark includes the following query categories, designed to test different aspects of code search:

Category Description Example
Exact name Query contains the exact symbol name "Find testMergeIntoEmptyAccumulator"
Definition lookup Ask for definition of a known symbol "Show me the definition of BufferEmbedding"
Interface/Type Look up an interface or type "Look up the interface MsObjectPattern"
Vague No specific name in query "I'm looking for a function that does something"
Stemmed keyword Query uses -ing form, name uses base "function involving testing" β†’ test*
Returns/Calls X Find function that calls/returns X "function returns builder.startObject"
Near-miss Very similar names, must discriminate test_establish_connection_using_3_levels_config vs ..._types_config

Evaluation Protocol

Each query is evaluated by running the full agent loop:

  1. The model receives the system prompt + user query
  2. It generates tokens autoregressively (greedy decoding)
  3. When it emits <|search|>...<|end|>, a retrieval result is injected as <|result|>...<|end|>
  4. The model can perform up to 3 search hops (multi-hop reasoning)
  5. Generation continues until <|finish|> or max 600 tokens

Metrics

Metric Definition
Search accuracy The expected symbol name appears in any of the model's search queries (not just the first). This rewards multi-hop reasoning.
Evidence rate The model emits a valid `<
Finish rate The model terminates with `<

Results (v13)

Metric Score
Search accuracy 92.0%
Evidence rate 100.0%
Finish rate 100.0%

Progression Across Training Rounds

Version Search Accuracy Evidence Finish EMA Loss Dataset Size Steps
v6 62.0% 96.0% 100.0% 0.2985 19K 800
v8 74.0% 98.0% 100.0% 0.2680 42K 800
v9 78.0% 100.0% 100.0% 0.2520 78K 800
v10 82.0% 100.0% 100.0% 0.2409 106K 800
v11 86.0% 100.0% 100.0% 0.2251 106K 800
v12 90.0% 100.0% 100.0% 0.1871 138K 1000
v13 92.0% 100.0% 100.0% 0.1500 193K 1000

Remaining Failure Modes (4/50)

The 4 remaining failures at 92% accuracy fall into two categories:

  1. Multi-hop not executed (3 cases): The model correctly identifies the target symbol name in its reasoning but goes to <|evidence|> instead of issuing a second <|search|>. This affects vague queries ("Where is the function defined?") and indirect queries ("function returns builder.startObject").

  2. Character-level near-miss (1 case): The model performs two searches but both are near-misses of the target name (test_establish_connection_using_3_types vs expected test_establish_connection_using_3_levels_config).

Training

Dataset

  • Dataset version: v11 (192,703 traces)
  • Source code: 628,100 code chunks from 20 open-source repositories
  • Trace types:
    • Multi-hop vague queries (15K) β€” search generic keyword β†’ extract name β†’ search name
    • Multi-hop returns/calls queries (28K) β€” search called method β†’ extract caller β†’ search caller
    • Multi-hop stemming queries (7K) β€” "involving testing" β†’ search "test" β†’ extract name β†’ search name
    • Multi-hop involving queries (7K) β€” search keyword β†’ extract name β†’ search name
    • Near-miss discrimination (8K) β€” search wrong name β†’ compare suffixes β†’ search correct name
    • Code-to-name extraction (8K) β€” extract function name from code snippet β†’ search it
    • Exact copy (44K) β€” single-hop: search exact name from query
    • Inherited from v10 (137K) β€” prior multi-hop + single-hop traces

Training Configuration

  • Method: Supervised Fine-Tuning (SFT)
  • Base checkpoint: sft_v12 (90% accuracy)
  • Optimizer: AdamW (betas=0.9, 0.95, weight_decay=0.1)
  • Learning rate: 5e-5 with cosine schedule
  • Batch size: 4 (effective 32 with gradient accumulation 8)
  • Sequence length: 1024
  • Precision: BF16
  • Gradient clipping: 1.0
  • Steps: 1000
  • Hardware: NVIDIA H100 80GB
  • Training time: ~21 minutes
  • Final EMA loss: 0.1500

Training Progression

The model was trained iteratively across 7 SFT rounds (v6β†’v8β†’v9β†’v10β†’v11β†’v12β†’v13), with each round:

  1. Analyzing remaining failures from the previous checkpoint
  2. Generating targeted training traces for those failure modes
  3. Fine-tuning from the previous checkpoint (warm start)
  4. Re-evaluating on the held-out test set

Usage

import torch
import sys
sys.path.insert(0, ".")  # model.py in repo root

from model import ModelConfig, Retriever500M
from safetensors.torch import load_file
from tokenizers import Tokenizer

# Load config
import json
with open("config.json") as f:
    cfg = json.load(f)

config = ModelConfig(
    vocab_size=cfg["vocab_size"],
    d_model=cfg["d_model"],
    n_layers=cfg["n_layers"],
    n_heads=cfg["n_heads"],
    d_ff=cfg["d_ff"],
    max_seq_len=cfg["max_seq_len"],
    dropout=0.0,
    tie_embeddings=True,
)

model = Retriever500M(config)
state_dict = load_file("model.safetensors")
model.load_state_dict(state_dict)
model.eval()

tokenizer = Tokenizer.from_file("tokenizer_agent.json")

Agent Loop Example

# System prompt
SYSTEM = (
    "You are a code search agent. Given a query from a reasoning model, "
    "decompose it into subqueries, search the codebase, inspect results, "
    "and return curated evidence. Use <|search|> to issue searches, "
    "<|reasoning|> to analyze, and <|evidence|> to return findings. "
    "Be concise. Extract only the relevant facts. End with <|finish|>."
)

# Build input: [system] SYSTEM [end] [user] "Find parseBoolean" [end] [assistant]
# Then generate autoregressively, injecting retrieval results after each <|search|>...<|end|>

License

MIT

Downloads last month
326
Safetensors
Model size
0.5B params
Tensor type
F32
Β·
Inference Providers NEW
This model isn't deployed by any Inference Provider. πŸ™‹ Ask for provider support

Model tree for Akahsizrr/makeitwork-1

Finetuned
(1)
this model