Why ERP retrieval is a hard problem
When we started building retrieval agents for SAP, we assumed the hardest part would be the language model. We were wrong. The hard part is the data. SAP systems accumulate decades of configuration spread across thousands of tables, transport requests, and customizing entries. No single view of the system tells you why a process behaves the way it does.
Standard retrieval-augmented generation approaches designed for document corpora break down quickly in this environment. Embedding a flat export of SAP configuration into a vector store loses all the relational structure that gives the data meaning. A material master record only makes sense in the context of the plant, valuation class, and pricing procedure it participates in.
Ticket history compounds the problem. Support tickets are written in a mix of functional SAP language, internal jargon, and abbreviated shorthand that changes from client to client. Off-the-shelf embeddings struggle to connect "GR not posting" to the specific movement type and account determination configuration that caused it.
A graph-first retrieval architecture
Our answer was to stop treating ERP data as a document corpus and start treating it as a graph. Every SAP object—transaction, table entry, process step, ticket—becomes a node. The edges encode the dependencies: which configuration drives which behavior, which tickets cluster around which process areas, which changes preceded which incidents.
Retrieval then becomes a graph traversal problem. Given an incoming ticket or user query, the agent identifies a set of anchor nodes and expands outward, collecting the configuration context, historical precedents, and related process steps that are most likely to be relevant. This produces a compact, structured context window rather than a ranked list of text chunks.
- Anchor extraction: entity recognition tuned on SAP terminology pulls transaction codes, table names, and process identifiers from the query.
- Graph expansion: a multi-hop traversal collects first- and second-degree neighbors weighted by historical co-occurrence with similar incidents.
- Context assembly: the retrieved subgraph is serialized into a structured prompt that preserves relationships, not just individual facts.
This approach cuts hallucination rates significantly compared to flat vector retrieval. When the model can see that a configuration value is linked to three recent incidents with the same symptom, it reasons differently than when it sees three disconnected text chunks that happen to mention the same table name.
What we learned building for production
Several lessons only became clear once we started deploying against real client systems. The first is that graph coverage matters more than graph depth. A shallow graph that reliably covers the configuration areas that actually generate tickets outperforms a deep graph built from a complete SAP schema export. We now build coverage incrementally, starting from the process areas with the highest ticket volume.
The second lesson is about confidence signals. The agent needs to know when it does not have enough context to act and should escalate instead. We calibrate this using a combination of retrieval density (how many relevant nodes were found) and historical resolution similarity (how closely the retrieved precedents match the current case). A low-confidence retrieval that triggers escalation is far less costly than a high-confidence retrieval that produces a wrong fix.
The third lesson is that client-specific fine-tuning of the embedding layer compounds quickly. Even a small set of client-labeled examples—tickets annotated with the root cause configuration—meaningfully improves retrieval precision within a few weeks of deployment. We now treat this annotation pipeline as a first-class part of onboarding.
Where this gets us
Graph-first retrieval is not a solved problem. SAP systems are large, heterogeneous, and change continuously. Our current architecture handles the majority of high-frequency incident types well, and we are actively extending coverage to less common configuration areas.
The practical outcome is that agents can now triage and resolve routine tickets with enough contextual precision to act autonomously — not by pattern-matching on ticket text, but by reasoning from the actual system state and history behind each issue. That is the foundation everything else in Dodge AI is built on.
