시맨틱 검색 (Semantic Search)의 문제점

당신은 RAG 시스템을 구축했습니다. 사용자가 질문을 하면, 이를 임베딩 (Embedding)하고, 벡터 유사도 검색 (Vector Similarity Search)을 실행하여 상위 5개의 청크 (Chunk)를 검색한 뒤, 이를 컨텍스트 (Context)에 집어넣고 LLM이 답변하게 합니다. 단순한 조회형 쿼리에는 아주 훌륭하게 작동합니다.

그런 다음 누군가 이렇게 질문합니다: "데이터베이스 마이그레이션 (Migration) 이후에 왜 배포가 실패했나요?"

당신의 에이전트 (Agent)는 배포 오류에 관한 청크를 검색합니다. 아마 마이그레이션에 관한 또 다른 청크도 검색할 것입니다. 하지만 마이그레이션이 컬럼 타입을 변경했고, 이것이 서비스 레이어 (Service Layer)의 의존성을 깨뜨렸으며, 그 결과 배포가 실패했다는 사실은 완전히 놓칩니다. 이것은 당신의 벡터 스토어 (Vector Store)가 연결할 수 없는 세 단계의 추론 (Reasoning) 과정입니다.

멀티 홉 (Multi-hop) 질문에 대한 정확도가 32%에서 86%로 차이 나는 것은 프롬프트 엔지니어링 (Prompt Engineering)의 문제가 아닙니다. 그것은 아키텍처 (Architecture)의 문제입니다.

벡터 검색이 실제로 제공하는 것

벡터 임베딩 (Vector Embeddings)은 시맨틱 유사도 (Semantic Similarity) 측면에서 경이롭습니다. 단어가 다르더라도 동일한 주제에 관한 문서들을 찾아낼 것입니다. 하지만 **사실 간의 관계 (Relationships between facts)**를 표현하는 데는 형편없습니다.

"서비스 A는 서비스 B에 의존한다"와 같은 문장을 임베딩하면, 이 방향성 있는 관계는 1536차원의 부동 소수점 배열 (Float Array)로 평탄화 (Flattened)됩니다. 임베딩은 이 서비스들이 서로 관련되어 있다는 것은 알지만, 어떻게 또는 어느 방향으로 관련되어 있는지는 알지 못합니다.

"어떤 서비스가 서비스 B에 의존하나요?"라고 물으면 두 서비스를 모두 언급하는 청크들을 검색할 수도 있습니다. "서비스 A는 무엇에 의존하나요?"라고 물어도 유사한 청크들을 얻게 될 것입니다. 벡터 스토어는 관계가 보존되지 않고 단지 근접성 (Proximity)만 유지되기 때문에 이러한 쿼리들을 구분할 수 없습니다.

실제 운영 환경에서의 검색 격차 (Retrieval Gap)

실제 시스템에서 문제가 발생하는 지점은 다음과 같습니다:

시나리오: 당신의 AI 에이전트가 마이크로서비스 아키텍처 (Microservices Architecture)를 관리합니다. 문서는 Notion에 있고, 장애 보고서는 Jira에 있으며, 설정은 GitHub에 있습니다.

쿼리: "인증 (Auth) 서비스를 중단시키면 영향 범위 (Blast Radius)가 어떻게 되나요?"

벡터 검색이 가져다주는 결과:

• 인증 (Auth) 서비스에 관한 청크 (Chunks)
• 인증을 언급하는 서비스들에 관한 일부 청크
• 인증 실패를 언급하는 사고 보고서 (Incident reports) 가능성

실제로 당신에게 필요한 것:

• 인증을 직접 호출하는 서비스들
• 해당 서비스들에 의존하는 서비스들 (2단계 홉 (second hop))
• 사용자 대상 기능에 미치는 다운스트림 영향 (3단계 홉 (third hop))
• 실제 영향 패턴을 보여주는 과거 사고 기록

벡터 검색 (Vector search)은 _문서 (documents)_를 검색합니다. 하지만 시스템에 대해 추론 (reasoning)하려면 **관계의 그래프 (graph of relationships)**를 탐색해야 합니다.

하이브리드 검색 (Hybrid retrieval)이 중요한 이유

해결책은 벡터 검색을 포기하는 것이 아니라, 벡터 검색을 유일한 검색 메커니즘으로 취급하는 것을 멈추는 것입니다.

그래프 기반 메모리 (Graph-based memory)는 정보를 **엔티티 (entities)와 엣지 (edges)**로 저장합니다. 에이전트 (agent)가 문서를 처리할 때 다음과 같은 정보를 추출합니다:

• 엔티티 (Entities): 서비스, API, 데이터베이스, 팀, 사고
• 관계 (Relationships): depends_on (의존함), calls (호출함), deploys (배포함), owns (소유함), caused_by (~에 의해 발생함)

이제 "영향 범위 (blast radius)" 쿼리는 그래프 탐색 (graph traversal)이 됩니다:

# 하이브리드 검색을 위한 의사코드 (Pseudocode)
def answer_query(query):
    # 1단계: 초기 재현 (initial recall)을 위해 벡터 검색 사용
...

당신은 의미론적 재현 (semantic recall, "인증 서비스와 관련된 모든 것을 찾아줘")을 위해 벡터를 사용한 다음, 명시적인 관계를 따라 바깥쪽으로 확장하기 위해 그래프를 사용합니다.

실제로 이것이 필요한 경우

모든 에이전트에게 그래프가 필요한 것은 아닙니다. 만약 "X를 어떻게 설정하나요?"라는 질문에 답하는 문서 Q&A 봇을 만들고 있다면, 벡터 검색만으로도 충분할 것입니다.

다음과 같은 경우에는 하이브리드 검색이 필요합니다:

• 질문이 여러 사실을 연결해야 하는 경우 ("왜 X가 발생했나요?")
• 명시적인 관계(의존성, 계층 구조, 워크플로우)를 가진 시스템에 대해 추론하는 경우
• 복잡한 쿼리에 대한 정확도가 단순함보다 더 가치 있는 경우
• 검색 점수 (retrieval scores)는 높지만 최종 답변이 틀리는 경우

빠른 진단: 에이전트에게 서로 다른 문서의 정보를 연결해야 하는 세 가지 질문을 던져보세요. 만약 에이전트가 모든 관련 청크를 검색할 수 있음에도 불구하고 여전히 불완전한 답변을 내놓는다면, 그것은 검색 (retrieval)의 문제가 아니라 관계 (relationship)의 문제입니다.

실제 적용 사례

하이브리드 검색 (hybrid retrieval)을 구현하는 것이 결코 간단하지는 않지만, 그렇다고 아주 생소한 것도 아닙니다.

1. 엔티티 (entities) 및 관계 (relationships) 추출: 문서 수집 (ingestion) 단계에서 추출합니다 (LLM 또는 NLP 파이프라인 사용).
2. 기존 벡터 DB에 벡터 저장: (Pinecone, Weaviate 등)
3. 그래프를 별도로 저장: (Neo4j, 또는 재귀적 CTE를 사용하는 관계형 DB)
4. 검색 시 두 가지 모두 쿼리: 그리고 결과를 병합합니다.

멀티홉 추론 (multi-hop reasoning)에서 86%의 정확도 향상을 경험하는 팀들은 마법을 부리는 것이 아닙니다. 그들은 단지 임베딩 (embeddings)이 본래 포착하도록 설계되지 않은 정보까지 보존할 것이라는 기대를 버렸을 뿐입니다. 벡터 전용 검색 (vector-only retrieval)에 관한 연구는 이러한 격차를 명확히 보여줍니다.

단순히 유사한 텍스트를 검색하는 것을 넘어 관계에 대해 추론해야 하는 프로덕션 AI 시스템을 구축하고 있다면, 결국 이 벽에 부딪히게 될 것입니다. 그래프 메모리 (Graph memory)는 있으면 좋은 기능 (nice-to-have)이 아닙니다. 그것은 의미론적 유사성 (semantic similarity)과 실제 추론 사이의 간극을 메우는 방법입니다.

견고한 에이전트 아키텍처 구축에 대해 더 자세히 알고 싶다면, 이러한 하이브리드 접근 방식을 심도 있게 다루는 AI 자동화 및 소프트웨어 개발 (AI automation and software development) 리소스를 확인해 보세요.

결론

벡터 검색은 관련 문서를 찾는 데는 탁월합니다. 하지만 사실들이 어떻게 연결되는지 이해하는 데는 형편없습니다. 만약 당신의 에이전트가 "왜" 또는 "만약 ~한다면 어떻게 되는가"라는 질문에 답해야 한다면, 코사인 유사도 (cosine similarity) 그 이상의 것이 필요합니다. 당신에게는 그래프가 필요합니다.