원문: Why DoorDash, Instacart, and Uber Eats Integrated LLMs Into Search Three Different Ways 링크: https://blog.bytebytego.com/p/why-doordash-instacart-and-uber-eats
요약 정리
문제의식: 세 회사 모두 같은 시기, 비슷한 연구 기반을 참고하며 검색에 LLM을 도입했지만 완전히 다른 아키텍처에 도달했다. 핵심 질문은 "어떤 LLM을 쓸까"가 아니라 "LLM이 런타임에 얼마나 깊이 들어가야 하는가"이며, 답은 각자 이미 가진 인프라가 결정했다.
음식 검색이 어려운 이유: 동의어("soda"/"soft drink"), 오타("Mozzarela"), 줄임말("Gf pizza"), 언어 혼용(스페인어 "pan"=빵 vs 영어 "pan"=냄비), 다의어("Apple") 같은 표면적 문제에 더해, 더 근본적인 두 문제가 있다 — ① 롱테일: 희귀 질의는 정의상 학습 데이터가 부족하다. ② 제약 조건: "vegan chicken sandwich" 같은 질의는 유사도 검색으로는 걸러낼 수 없는 하드 제약(dietary restriction, 알레르기, 수량)을 포함한다.
DoorDash — LLM은 오프라인 주변부에
- 이미 있던 지식 그래프(요리 종류·식이 선호·요리 문화·브랜드·맛 속성)를 LLM으로 오프라인 보강, 런타임에는 질의를 그래프에 연결할 조각으로 파싱만 LLM이 담당.
- 예: "small no-milk vanilla ice cream" → 수량(small)/식이(no-milk→dairy-free 하드필터)/요리종류(ice cream)/맛(vanilla, 소프트 랭킹)으로 분해.
- 핵심 트릭: RAG를 생성기가 아니라 가드레일로 뒤집어 사용 — 근사 최근접 이웃으로 상위 100개 분류체계 후보를 먼저 뽑고, LLM은 그 목록 안에서만 고르게 함(새 라벨 생성 금지). RAG가 출력 공간 자체를 제한.
- 효과: 인기 요리 캐러셀 트리거율 약 30% 상승. 런타임은 여전히 고전적 검색 중심.
Instacart — 파편화된 모델 군을 LLM으로 통합
- 기존엔 FastText 분류, 별도 재작성 엔진, 철자교정·태깅·통로분류 모델이 각자 파이프라인으로 난립 — 유지보수 부담 크고 롱테일 취약.
- 3단계 전략: 컨텍스트 엔지니어링(RAG로 전환율 높은 카테고리 등 Instacart 고유 맥락을 프롬프트에 주입) → 후처리 가드레일(의미 유사도 필터로 원 질의에서 벗어난 출력 제거) → 파인튜닝(Llama-3-8B를 자체 데이터로 파인튜닝, 고난도 작업용).
- 서빙은 헤드/테일 분리: 헤드 질의=오프라인 RAG+캐시(지연 허용), 테일 질의=실시간 파인튜닝 Llama-3-8B(어댑터 병합+H100+오토스케일링으로 300ms 이내).
- 효과: 질의 재작성 커버리지 50%→95%+(정밀도 90%+), 하위 2% 테일 질의 스크롤 깊이 6% 감소, 관련 불만 절반 감소.
Uber Eats — LLM이 임베딩 백본 그 자체
- 다중 버티컬(레스토랑/그로서리/리테일)·다중 시장·다국어라는 추가 난이도. 기존엔 버티컬별 BERT 임베딩이 파편화.
- 투 타워(two-tower) 구조 채택, 양쪽 타워 모두 파인튜닝된 Qwen을 백본으로 사용. 질의 타워=온라인 실시간 임베딩, 문서 타워=오프라인 사전 임베딩 후 HNSW 벡터 인덱스에 적재(수십억 문서 규모라 매 질의마다 무거운 LLM을 돌리는 건 불가능하므로).
- Qwen 자체의 교차언어 능력이 스페인어 "pan" 같은 문제를 해결, 자체 질의-문서 데이터 파인튜닝이 도메인 정합성 부여.
- 최적화 스택: Matryoshka 표현학습(1536→256차원 축소, 리콜 손실 0.3% 미만), int7 양자화(지연 절반 추가 감소), 헥사곤/도시/이행유형 사전 필터.
- 효과: ANN 파라미터 k 튜닝으로 지연 34%·CPU 17% 감소, 양자화로 지연 절반(리콜 0.95 이상 유지), MRL로 저장공간 거의 50% 절감.
통합 깊이 스펙트럼과 결론
세 회사를 "LLM이 런타임에 얼마나 깊이 있는가" 축 위에 놓으면 DoorDash(왼쪽, 오프라인 중심) — Instacart(중간, 질의이해 계층) — Uber Eats(오른쪽, 임베딩 자체가 LLM) 순. 이 위치는 모델 성능이 아니라 이미 보유한 인프라(지식 그래프 vs 파편화된 특화 모델 vs 투 타워 임베딩)가 결정했다. 실무 교훈: "어떤 LLM을 쓸까"보다 "기존 스택 어디에 LLM을 꽂아야 하는가"를 먼저 물을 것. 세 아키텍처를 관통하는 공통 원칙 세 가지 — ① 하이브리드가 기본값(고전적 검색·지식그래프·ANN 인덱스가 여전히 대부분의 일을 함), ② 사전학습 모델의 세계 지식은 출발점일 뿐, 도메인 맥락은 RAG나 파인튜닝으로 별도 주입해야 함, ③ 제약된 어휘·유사도 필터·분류체계 강제 같은 가드레일이 프로덕션 LLM 시스템의 정합성을 좌우함.
핵심 요약 (20줄)
- DoorDash·Instacart·Uber Eats는 같은 시기, 비슷한 연구를 참고하며 검색에 LLM을 도입했지만 서로 완전히 다른 아키텍처에 도달했다.
- 핵심 질문은 어떤 LLM을 쓰느냐가 아니라 LLM이 런타임에 얼마나 깊이 들어가야 하는가였다.
- 그 답은 각 회사가 이미 갖고 있던 인프라가 결정했다.
- 음식 검색은 동의어·오타·줄임말·언어혼용·다의어 문제에 더해, 롱테일 질의와 제약 조건 처리라는 근본적 어려움을 동시에 안고 있다.
- DoorDash는 기존 지식 그래프를 LLM으로 오프라인 보강하고, 런타임에는 질의 파싱에만 LLM을 썼다.
- RAG를 생성기가 아니라 가드레일로 뒤집어 써서, LLM이 기존 분류체계 안에서만 답하도록 제한했다.
- 그 결과 인기 요리 캐러셀 트리거율이 약 30% 상승했다.
- Instacart는 파편화된 여러 특화 모델(FastText 등)을 유지보수하다가 LLM 통합 전략으로 전환했다.
- 컨텍스트 엔지니어링(RAG)·후처리 유사도 필터·Llama-3-8B 파인튜닝을 층층이 결합했다.
- 헤드 질의는 오프라인 캐시로, 테일 질의는 실시간 파인튜닝 모델(300ms 이내)로 분리 서빙했다.
- 질의 재작성 커버리지가 50%에서 95% 이상으로 뛰었고 테일 질의 불만이 절반으로 줄었다.
- Uber Eats는 다중 버티컬·다국어라는 추가 난제를 안고 있었다.
- 투 타워 구조 양쪽 모두에 파인튜닝된 Qwen을 임베딩 백본으로 썼다.
- 질의 타워는 실시간, 문서 타워는 오프라인 사전 임베딩으로 나눠 비용을 감당 가능하게 만들었다.
- Matryoshka 임베딩·양자화·사전 필터링으로 지연 시간과 저장 비용을 크게 절감했다.
- 세 회사를 통합 깊이 축에 놓으면 DoorDash-Instacart-Uber Eats 순으로 LLM이 점점 더 핵심부로 들어간다.
- 이 위치는 모델 성능이 아니라 기존에 보유한 인프라가 결정한 결과다.
- 실무 교훈은 "어떤 LLM을 쓸까"보다 "기존 스택 어디에 LLM을 꽂을까"를 먼저 물어야 한다는 것이다.
- 세 아키텍처 모두에서 하이브리드 시스템이 기본값이고, 사전학습 지식은 출발점일 뿐 도메인 맥락 주입이 필수였다.
- 제약된 어휘·유사도 필터 같은 가드레일이 프로덕션 LLM 시스템의 신뢰성을 좌우하는 공통 요소로 확인됐다.
📁 Study/뉴스레터/2026-07-28-ByteByteGo.md