AI 메모리 신뢰성의 핵심인 스키마

Schema as the Core of Reliability in AI Memory Most AI memory systems are still built around one core assumption: memory is mainly a retrieval problem. Sometimes that takes the form of classic vector RAG - store text, embed it, retrieve similar chunks later. Sometimes it shows up in agentic systems that “remember” by endlessly appending observations, tool outputs, prior decisions, and working context into prompts, then compacting or summarizing that history when the context window fills up. And sometimes it appears in more advanced Graph RAG systems that add structure to retrieval by making relationships explicit. These are different approaches, and some are meaningfully better than others. But they still share the same underlying pattern: memory is stored largely as unstructured or semi-structured context, and correctness is reconstructed later. That works well for one class of memory requests: thematic recall. What were we discussing about this project? What direction were we leaning? What was the general context around this decision? For those questions, approximate retrieval is often enough. But operational memory is not just thematic recall. Once memory becomes an input to decisions, workflows, or automation, the requests change. Now the system is being asked: What timeout did we set? Which vendor did we choose? What is the latest status? Which users reported an issue after release X? Which entities are related to this incident? Which expected facts are missing? How many times has this happened in the last month? These are not all the same kind of query. Some are exact lookups. Some are state queries. Some are aggregations. Some are relational. Some depend on exclusions, constraints, or explicit unknowns. And that is the real dividing line: different memory request types demand more than semantic similarity. Search can recover context. Memory must support facts. Section titled “Search can recover context. Memory must support facts.”The problem is not that retrieval is useless. It is that retrieval alone is not enough. If memory is stored as text, summaries, or compacted prompts, every read becomes a fresh act of interpretation. The model has to parse prose, infer what matters, resolve ambiguity, and reconstruct the facts from narrative. The same history can produce slightly different answers depending on what was retrieved, how it was compressed, or how the model interprets it in that moment. That is the core weakness of both vector-style memory and prompt-compacted memory. Agentic systems often appear different because they do not always rely on semantic search. Instead, they carry memory forward by repeatedly appending context and compressing it over time. But the underlying issue is the same. Memory is still living as text. Low-salience but high-importance details can be merged, blurred, or dropped during summarization. Then later, the model is expected to recover exact facts from an approximate narrative trace. Reliable memory cannot depend on repeated reinterpretation. It has to be able to retrieve facts as facts. Graph RAG is a real step forward - but not the endpoint Section titled “Graph RAG is a real step forward - but not the endpoint”It is also important to be fair about what already exists. The world is not just simple vector databases and chunk retrieval anymore. Graph RAG and related approaches add meaningful structure. They make relationships more explicit, improve multi-hop reasoning, reduce some ambiguity, and often outperform flat retrieval when questions depend on connected entities or linked context. That matters. But Graph RAG still usually improves how the system navigates memory more than how memory itself is governed. In many graph-based systems, the nodes or leaves still resolve to text fragments, summaries, or embeddings. The graph helps the system find related information, but it does not necessarily define what must be remembered, what counts as a valid fact, whether two records should be merged, whether a missing value is truly unknown, or whether a retrieved answer violates a constraint. In other words, it brings more structure to retrieval, but not enough structure to guarantee reliable factual memory. That is the gap schema fills. If memory is going to answer operational questions reliably, facts cannot remain buried inside text. They need structure. A memory system has to know when two things are the same thing. It needs deduplication so the same customer, decision, incident, or requirement is not stored in slightly different forms across time. It needs types so a date is understood as a date, a state as a state, and an identifier as an identifier. It needs relations so facts connect to the entities and events they belong to. And it needs constraints so the system can reject ambiguity instead of smoothing over it with a plausible guess. This is what turns memory from stored language into usable knowledge. Without structure, ambiguity is not an edge case. It is the defau