누구도 이름 짓지 않는 검색 문제

모든 진지한 에이전트 시스템은 결국 메모리가 필요합니다: 유사한 상황이 이전에 어떻게 처리되었는지를 조회하고 일관되게 행동하는 능력입니다. 2026년의 기본 답변은 벡터 RAG입니다 — 모든 것을 임베드하고, 가장 유사한 상위 k개의 청크를 검색하여 컨텍스트 윈도우에 넣습니다.

문서의 경우, 그것은 작동합니다. 결정의 경우, 조용히 실패합니다. 그리고 그 실패는 구조적이며, 조정 문제는 아닙니다.

결정은 단락이 아니다. 그것은 작은 관계의 망이다: 제안, 찬반 논거, 각 논거가 의존한 증거, 예외를 승인한 사람, 그리고 어떤 과거 사례를 따랐는지. 이를 텍스트 조각으로 평탄화하고 삽입하면, 검색은 관계가 절단된 조각들을 반환한다. 반론 없이 결론을 얻고, 이유 없이 승인을 얻고, 선례를 언급하는 문장을 얻지만 그 선례 자체는 얻지 못한다.

이것이 실무자들이 "청크 수프."라고 부르는 것입니다. 이것이 벡터 전용 검색이 결정 로그에 대해 자신감 있게 느껴지지만 미묘하게 신뢰할 수 없는 이유입니다.

청크 수프 대 결정 패킷

규범적 경계가 모든 것을 변화시키는 이유

일반적인 지식 그래프는 설명적인 엣지를 저장합니다: "언급," "관련됨," "소유됨." 이들은 두 가지가 연결되어 있음을 알려주지만 왜 중요한지는 알려주지 않습니다.

결정 그래프는 규범적 엣지를 저장합니다 — 관계는 추론을 담고 있습니다:

왜 결정 그래프가 "GraphRAG-완벽한"가 되는가

일반 기업 그래프에서 GraphRAG를 시도하는 대부분의 팀은 포기합니다. 그 이유는 일관되며, 결정 그래프는 이 모든 이유를 피합니다:

하이브리드 검색 파이프라인

벡터와 그래프는 여기서 경쟁자가 아닙니다. 의사결정 검색은 진입점을 찾기 위해 벡터를 사용하고 전체 맥락을 가져오기 위해 그래프 구조를 사용합니다. AIAgentree에서는 이것이 다섯 단계의 파이프라인입니다(선행 검색 서비스에 포함됨):

에이전트를 위한 검색: MCP 및 A2A

메모리는 에이전트가 추론하는 동안 접근할 수 있을 때만 유용합니다. AIAgentree는 의사 결정 검색을 두 가지 방법으로 노출합니다:

코드에서 어떻게 보이는지

대리인이 내릴 결정을 위한 선례 검색:

# Find how similar cases were decided before acting
results = client.search_precedents(
    query="refund above auto-approve threshold, premium customer",
    filters={"category": "customer_service", "maturity": "validated"},
)

for packet in results:
    # Each packet is a complete decision: proposition, pro/con
    # arguments, evidence, approvals, outcome, and cited precedents
    print(packet.proposition, packet.outcome, packet.confidence)

원시 로그의 프롬프트 스터핑이 없습니다. 에이전트는 이전 결정에 대해 그들의 추론이 첨부된 상태로 추론합니다. 이 스니펫은 명확성을 위해 Python 클라이언트를 사용하지만, 동일한 검색(get_packet, search_precedents)이 SDK 없이 MCP를 통해 제공되므로, MCP 네이티브 에이전트는 도구로서 결정을 소비합니다.

풀 스택이 배송되었습니다.

우리는 인상적이기보다는 정확한 것이 더 낫다고 생각합니다. 오늘 진행 중인 내용은 다음과 같습니다:

이것이 대체하지 않는 것