Small Language Models for Analysis of RF Spectrum Samples

Executive summary

“Small language models” (SLMs) are compact transformer language models (often ~100M–5B parameters) intended for resource-constrained or edge deployment.¹ Recent surveys characterize SLMs as a distinct design space, emphasizing efficiency tactics such as distillation, quantization, pruning, and parameter-efficient tuning for deployment constraints.² For RF work, SLMs are rarely the best first-choice for raw I/Q classification or fine-grained signal processing (specialized DSP and signal-domain neural networks still dominate those tasks). However, SLMs are increasingly effective as an analysis layer that sits on top of conventional DSP/ML pipelines:

• Triage and explanation: turn peak lists, occupancy metrics, and “waterfall” summaries into operator-ready findings.
• Reasoning over context: integrate spectrum samples with band plans, device configs, station logs, and standards via RAG.
• Workflow automation: drive toolchains (FFT, STFT, demod, direction finding) and keep a reproducible audit trail.
• Edge viability: with quantization and careful prompting, SLMs can run locally and support near-real-time monitoring use cases.

Beyond direct sample interpretation, language models are also being applied to downstream spectrum workflows (e.g., compliance reporting, regulatory filing triage, and policy documentation), which often must be linked back to measured captures and derived features.¹²

Research directions are converging on two complementary paradigms: (1) converting signal or spectrum time series into compact text-like representations for language models (e.g., anomaly detection pipelines), and (2) “reprogramming” or fusing radio features into transformer token spaces for cognitive radio tasks (classification, denoising, allocation). Examples include SigLLM-style time-series-to-text anomaly detection approaches and RadioLLM-style hybrid prompt/token reprogramming for cognitive radio tasks.³⁴

Where SLMs fit in RF spectrum analysis

In practice, spectrum “samples” arrive in multiple forms: (a) power spectral density vectors from FFT/Welch, (b) spectrograms/waterfalls (time–frequency matrices), and (c) raw complex I/Q (time-domain). SLMs are natively designed for text tokens, not numeric sequences or complex-valued arrays. As a result, the highest-yield pattern is:

1. DSP/feature extraction first (FFT/STFT, peak finding, occupancy, cyclostationary cues, burst metrics, etc.).
2. Encode results into structured text (JSON schema, tables, short descriptors) suitable for a language model.
3. Use an SLM for reasoning, summarization, and decision support (and to call tools when a deep numeric step is required).

This division of labor addresses a widely observed limitation: tokenizers and prompt formats are not inherently designed to preserve numeric and temporal structure, so “naively” passing long numeric sequences to a language model is inefficient and can degrade performance.¹¹

Representing RF spectrum samples for SLM consumption

1) Peak-and-burst summaries (recommended default)

Convert each scan (or time window) into a compact list of detected emissions: center frequency, bandwidth, max/mean power, SNR proxy, duty cycle, and “shape” descriptors (e.g., flat-top vs narrow spike). This is highly token-efficient and maps well to operator reasoning.

2) Quantized “symbolic” spectra

For wider-band scans, quantize power into coarse bins (e.g., 1 dB steps, or “low/medium/high”), then encode only significant regions (run-length encoding). This supports qualitative reasoning (“the 2.4 GHz band is saturated; a new emitter appears at 2437 MHz with 25% duty cycle”).

3) Spectrogram descriptors and thumbnails

If you have an RF spectrogram image (waterfall), multimodal approaches can be used, but even without full multimodality you can extract shape descriptors (chirps, bursts, periodic combs) and pass these as textual features. RF-focused RAG systems such as RFSensingGPT explicitly combine technical Q&A, code retrieval, and spectrogram analysis to improve RF-domain performance.⁵

4) Raw I/Q tokenization (specialized; research-heavy)

Directly mapping I/Q to tokens is possible but usually requires bespoke architectures, “token reprogramming,” or hybrid fusion modules. RadioLLM proposes hybrid prompt and token reprogramming plus frequency-attuned fusion to integrate radio features and expert knowledge for tasks such as radio signal classification, denoising, and spectrum allocation.⁴

Examples of SLM-assisted RF spectrum analysis

Example A: Spectrum monitoring with anomaly detection (SLM as a detector)

Many RF monitoring problems are naturally time-series problems: channel power vs time, occupancy vs time, or “peak count” vs time. SigLLM-style pipelines convert a time series into a compact text representation and then either (1) directly prompt a language model to locate anomalies, or (2) use the model as a forecaster and flag anomalies via prediction error (often outperforming the direct-prompt method).³

{
  "window": "2026-01-08T00:00:00Z to 2026-01-08T06:00:00Z",
  "band": "150-174 MHz",
  "features_per_minute": [
    {"t":"00:00","noise_floor_dbm":-103,"peak_count":2,"max_peak_mhz":162.55,"max_peak_dbm":-62,"occupancy_pct":5},
    {"t":"00:01","noise_floor_dbm":-103,"peak_count":2,"max_peak_mhz":162.55,"max_peak_dbm":-61,"occupancy_pct":5},
    {"t":"02:13","noise_floor_dbm":-95,"peak_count":17,"max_peak_mhz":155.23,"max_peak_dbm":-48,"occupancy_pct":42}
  ],
  "instrument": {"rbw_hz":5000,"antenna":"discone","location":"site-3"}
}

Note: The SLM is not being asked to “do FFT math.” It is being asked to interpret structured summaries and relate them to context (band plans, schedules, prior baselines). This keeps the model in its comparative advantage: reasoning and narrative synthesis.

Example B: Cognitive radio decision support (SLM as a policy/reasoning engine)

Cognitive radio workflows often require combining: real-time sensing, policy constraints, and optimization objectives. RadioLLM is representative of the emerging approach that adapts language-model machinery to cognitive radio tasks by fusing radio features with “expert knowledge” through hybrid prompts and token reprogramming, with evaluations on benchmark datasets for tasks such as signal classification and spectrum allocation.⁴

Example C: RF-domain RAG + spectrogram interpretation (SLM as an expert assistant)

A recurring pain point in RF work is that “what I see” in a spectrogram often requires cross-referencing standards, prior captures, and code snippets. RFSensingGPT demonstrates an RF-tailored architecture that combines retrieval-augmented generation with RF-specific technical corpora and spectrogram analysis, addressing domain knowledge gaps and supporting tasks that include spectrum monitoring and interference detection.⁵

The immediately transferable pattern for spectrum work is: (1) store captures and annotations in a durable, tool-friendly format (e.g., SigMF), (2) index relevant standards, band plans, and internal notes for retrieval, and (3) constrain the model to produce claims that are grounded in retrieved text plus measured features.

Data management for RF samples (why it matters for SLM pipelines)

SLM-enabled analysis is only as reproducible as the data packaging around it. SigMF (Signal Metadata Format) is designed to describe recorded digital signal samples using JSON metadata, including capture system characteristics and annotations, in a portable format suitable for real-time and memory-limited environments.⁶ The SigMF project maintains a versioned public specification (v1.2.6 at the time of writing).⁷

For dataset building and modeling, open toolchains frequently combine SigMF with augmentation frameworks. For example, IQT Labs’ RFML pipeline describes a workflow for labeling I/Q data using SigMF and training models with TorchSig-based augmentations.⁹ TorchSig itself provides domain transforms and datasets for RF ML research and is actively maintained as an open-source toolkit.⁸

Implementation patterns that work well with small models

Pattern 1: “Tool-using” SLM (preferred)

Keep the SLM responsible for orchestration and explanation; keep numeric heavy lifting in deterministic tools. This approach is aligned with how prompt-to-tool datasets are being generated for SDR workflows, including the construction of prompt-context-completion tuples from tool traces for GNU Radio flowgraph construction and related tasks.¹⁰

Pattern 2: Schema-first prompts

Define a stable JSON schema for spectrum features and insist the model output conforms to a report schema (e.g., “observations,” “hypotheses,” “recommended tests,” “confidence”). This improves evaluability and reduces hallucinated parameter values.

Pattern 3: RAG over your RF “ground truth”

Retrieval-augmented generation is especially valuable for RF because “correctness” is often anchored in standards, band plans, and device configuration. When the model can cite retrieved text and measured features, you can build an auditable, reproducible analysis workflow.⁵

Limitations and controls

• Numeric brittleness: treat the SLM as an interpreter, not the calculator; keep DSP numeric steps outside the model.¹¹
• Token budgets: prefer peak lists, occupancy tables, and quantized summaries over raw arrays.
• Grounding and auditability: require citations to retrieved sources or measured artifacts; log prompts and tool outputs.
• Performance expectations: in anomaly detection studies, LLM-based approaches can be useful out of the box but still trail specialized SOTA deep models in performance, suggesting that hybrid pipelines are the pragmatic near-term approach.³

Recommended starting point (practical)

1. Standardize captures using SigMF (or a comparable, versioned schema) and keep annotations with the data.
2. Implement deterministic feature extraction (FFT/STFT, peak finder, occupancy) and store derived features alongside raw captures.
3. Adopt a schema-first SLM prompt that consumes only derived features plus context, not raw arrays.
4. Add RAG over your standards, band plans, and internal baselines; require the model to cite retrieved snippets in its own output.
5. Validate with replay: run the same captures through the pipeline and confirm stable outputs across model versions.