Should organisations prioritise knowledge graphs or model upgrades for SOC AI?

Why retrieval structure usually beats a model refresh in SOC AI

For SOC AI, the first question is rarely which model is smartest. It is whether the assistant can consistently find the right alerts, assets, identities, logs, and enrichment sources before it reasons about them. If the retrieval layer is unstable, the system can produce confident output from incomplete or mismatched evidence, which makes tuning the model look effective when the real fault is in data selection and entity linking. ENISA’s threat reporting is useful background here because many modern security failures begin with poor visibility, fragmented telemetry, and weak context rather than with a lack of analytic horsepower alone: ENISA Threat Landscape.

In practice, many security teams discover retrieval defects only after analysts start challenging the system’s source traceability, rather than through intentional model evaluation.

How SOC workflows break when the knowledge layer is thin

A SOC AI workflow depends on several linked steps: selecting the right source, normalising the event, resolving entities, and then generating a response. If any of those steps are weak, a larger model can still sound persuasive while relying on the wrong alert, the wrong host, or a stale enrichment record. That is why a knowledge graph, asset graph, or similarly structured context layer often creates more immediate value than a model upgrade. It helps the system understand that two differently named logs may refer to the same endpoint, or that a user, service account, and ticket should be treated as part of one investigation thread.

Model upgrades matter when the core problem is reasoning quality, summarisation, or instruction following. They matter less when the problem is that the system cannot reliably identify what it is looking at. A strong model can improve triage wording and correlation logic, but it cannot reliably recover missing relationships or compensate for inconsistent taxonomy. If the source map is unstable, the assistant may retrieve plausible but irrelevant context, and that creates a dangerous illusion of accuracy.

• A knowledge graph helps when the pain point is entity resolution, provenance, and cross-source correlation.
• A model upgrade helps when the pain point is interpretation, ranking, or explanation over already reliable context.
• If analysts keep correcting source selection, the issue is usually context architecture, not prompt quality.

The guidance breaks down when the environment has no stable telemetry taxonomy at all, because then even a good graph will simply organise bad inputs.

When the answer is not either-or

Tighter context engineering often increases upfront data work, requiring organisations to balance faster experimentation against a more disciplined source model. That tradeoff becomes sharper in SOC AI because a shallow knowledge layer can make early demonstrations look impressive while hiding weak governance over schemas, asset naming, and trust boundaries.

There are two common edge cases. First, if the SOC use case is narrow and text-heavy, such as summarising alerts from one platform with consistent fields, a model upgrade may deliver a faster win than a full graph build. Second, if the use case is investigation-heavy and spans many tools, the graph usually becomes the higher-leverage investment because the bottleneck is not language quality but relationship quality. Industry consensus is still uneven on how much ontology structure is enough, so organisations should treat that as a design choice, not a settled rule.

Where this matters most is agentic SOC tooling. Once an AI system can trigger actions or open investigations, incorrect relationships become operationally expensive because they can push response into the wrong queue, misattribute ownership, or hide a real chain of events behind a cleaner summary. The smarter model may sound better, but the better map is what keeps the workflow grounded.

For teams comparing investments, the practical test is simple: if users keep asking whether the system looked at the right data, prioritise the knowledge layer; if they trust the data but dislike the answer quality, prioritise the model.

Practitioner Guidance

What to prioritise: Start with the failure mode that most often causes analyst distrust. If the tool is pulling the wrong entities, flattening relationships, or mixing sources, fix the context layer first. If source selection is already dependable, model work can move faster because it is being measured against stable inputs.

What to verify: Before approving a model upgrade as the main investment, verify whether current SOC errors are caused by retrieval, schema drift, or entity mismatch. If analysts are repeatedly correcting provenance, the bottleneck is structural and a better model will only hide it temporarily.

Decision rule: Treat model improvements as secondary when the system cannot explain why a specific alert, host, or identity was selected. Treat context engineering as secondary only when the data map is already stable and the remaining gaps are clearly about reasoning quality.

Practitioner takeaway: In SOC AI, the safest sequencing is to make the system trustworthy about facts before making it better at talking about them.

Related resources from NHI Mgmt Group

• When should organisations prioritise runtime guardrails over model-focused AI controls?
• When should organisations prioritise AI cost governance over more model experimentation?
• When should organisations prioritise an AI gateway for multi-model deployments?
• When should organisations prioritise tiered access over broad model access for AI applications?