Josh Clemm이 말하는 Dash의 knowledge graph, MCP, DSPy 활용법

Dropbox Dash는 여러 SaaS와 사내 콘텐츠를 한곳에 모아 검색과 답변, 에이전틱 질의를 가능하게 하는 context engine 위에 구축됐다.

핵심은 먼저 connectors로 외부 앱을 연결하고, 문서·이미지·PDF·오디오·비디오를 정규화한 뒤 제목, 메타데이터, 링크, 임베딩을 추출해 인덱싱하는 흐름이다. 문서는 텍스트 추출로 끝날 수 있지만, 이미지와 비디오는 멀티모달 이해가 필요하고, 특히 영상은 장면 단위로 이해를 만들어 저장해야 한다.

이렇게 만든 정보는 knowledge graph로도 묶는다. 회의, 문서, 사람, transcript, 이전 메모를 연결해 교차 앱 컨텍스트를 만들고, 사람 ID를 canonical ID로 정규화해 검색과 관련성 향상에 활용한다.

저장 계층은 BM25 기반 lexical index와 vector store를 함께 쓰는 hybrid retrieval이다. 여러 단계의 ranking을 거쳐 사용자별 ACL을 적용하고, 결과를 개인화한다.

Retrieval 전략은 federated retrieval보다 index-based retrieval를 택했다. federated 방식은 빠르게 시작할 수 있지만 API나 MCP 서버 품질에 의존하고, company-wide connector 접근이 어렵고, 결과를 온더플라이로 합치고 재정렬해야 하며, 토큰 소모도 커진다. 반대로 index-based 방식은 회사 전체 커넥터를 활용하고 오프라인 실험과 고급 enrichment가 가능하지만, 커스텀 connector와 freshness, 저장 비용 문제를 감당해야 한다.

MCP는 Dash 규모에서 그대로 쓰기엔 부담이 컸다. tool definition이 컨텍스트 윈도우를 많이 차지하고, retrieval 결과까지 더해지면 100,000 tokens 수준의 상한을 금방 채우며, 간단한 쿼리도 최대 45초까지 느려질 수 있다.

이를 줄이기 위해 Dash는 다음과 같이 설계했다.

• 인덱스를 감싼 하나의 super tool로 여러 retrieval tool을 단순화
• knowledge graph로 필요한 정보만 더 압축해 전달
• tool result의 큰 컨텍스트는 LLM 컨텍스트에 넣지 않고 로컬 저장
• 복잡한 쿼리는 sub-agent로 나누고 classifier가 더 좁은 도구 집합을 가진 에이전트를 선택

LLM as a judge도 중요한 축이다. 검색의 클릭 신호처럼 직접적인 인간 피드백이 없는 채팅 환경에서, 관련성을 1~5로 평가하는 judge를 만들고 인간 라벨과의 disagreement를 줄이는 방식으로 품질을 개선했다. 초기 프롬프트에서는 **8%**가 불일치했지만, 프롬프트 개선과 OpenAI o3로의 모델 업그레이드로 더 낮아졌고, 약어 같은 사내 맥락을 보완하기 위해 judge가 직접 컨텍스트를 가져오는 RAG as a judge까지 사용했다.

마지막으로 그는 prompt optimizer인 DSPy를 포함해, Dash가 대규모 업무 문맥에서 retrieval, routing, evaluation을 어떻게 체계화하는지 설명했다.