Quartz 4

Locally AI 파이프라인 테스트 결과

12 min read

Locally AI 파이프라인 테스트 결과

단일 프롬프트 API vs 암묵지 청크 기반 파이프라인 비교 테스트 모델: GLM-4.7 / 테스트일: 2026-03-24

📑 목차

1. 왜 이 파이프라인이 기술적 해자인가

핵심 명제

단순 API 프롬프트는 “알려진 정보”만 생성한다. 우리 파이프라인은 “경험에서만 나오는 정보”를 생성한다.

해자의 본질 — 벡터 인덱스가 곧 자산

단순 API 호출 방식의 한계:

유저 질문 → GLM → 학습 데이터 기반 일반론 생성

상용 AI는 인터넷에 이미 존재하는 정보의 압축본이다. 네이버 블로그, 트립어드바이저에 있는 내용을 다시 뽑아줄 뿐이고, 경쟁사가 같은 API를 호출하면 동일한 결과가 나온다. 복제 가능.

우리 파이프라인:

유저 질문
    ↓
벡터 유사도 검색 (우리 인덱스)
    ↓
현지인 암묵지 청크 retrieval
    ↓
GLM이 청크를 근거로 생성

이 인덱스는 우리 유저들의 경험이 쌓인 것이다. 경쟁사가 같은 API를 써도 이 인덱스는 복제할 수 없다.

해자가 강해지는 메커니즘

팁 100개 인덱스
    → 검색 커버리지 낮음, 추천 정확도 낮음

팁 10,000개 인덱스
    → 커버리지 높음, 유사 팁 클러스터링, 신뢰도 산출 가능
    → 같은 API를 써도 절대 따라올 수 없는 품질

팁이 쌓일수록 자동으로 강해진다. API를 바꿔도 인덱스는 남는다.

단순 프롬프트가 절대 못 하는 것 3가지

  1. 암묵지 표현 불가 한국인에게 당연해서 인터넷에 없는 정보는 GLM 학습 데이터에도 없다. “테이블 아래 숨겨진 수저 서랍”은 블로그에 없으니 프롬프트로 못 나온다.

  2. foreigner_trap 구조화 불가 “외국인이 어떤 상황에서 어떻게 실패하는가”는 외국인 경험자의 제보가 쌓여야만 패턴이 보인다. 프롬프트는 이 패턴 데이터가 없다.

  3. 신뢰도 calibration 불가 “점포마다 다를 수 있으며, 47명 제보 중 31명 성공” 이 문장은 데이터 없이 생성 불가능하다. 프롬프트는 항상 자신감 있게 틀린다.

네이버 블로그 vs Locally 비교

항목네이버 블로그Locally
관점한국인이 한국인에게현지인이 외국인에게
형식3000자 후기상황 1개 → 행동 1개
함정 정보없음 (당연하니까 안 씀)foreigner_trap 필드로 명시
실시간성작성자 의지에 달림유저 제보로 지속 축적
검색 방식키워드상황 기반 시맨틱
언어한국어 단일다국어 확장 가능

2. 테스트 개요

배경

외국인 여행자 대상 로컬 꿀팁 앱 “Locally”의 AI 파이프라인 설계 검토. 핵심 질문: 단순 API 프롬프트 호출 대비 청크+벡터 구조가 실제로 더 나은 결과를 내는가?

테스트 구성

구분방식설명
방식 A단일 프롬프트질문을 GLM에 그대로 전달
방식 B암묵지 청크 기반현지인 제보 팁을 구조화해 컨텍스트로 주입

팁 데이터 구조

{
  "situation": "어떤 상황에서 쓰는 팁인지",
  "action": "정확히 뭘 해야 하는지 (동사 1개)",
  "why": "왜 이게 통하는지",
  "success_condition": "이럴 때 잘 됨",
  "fail_condition": "이럴 때 안 됨",
  "foreigner_trap": "외국인이 보통 뭘 잘못하는지",
  "category": "transport | food | manner | daily"
}

3. 테스트 1 — 단일 프롬프트 vs 청크 기반 (식당 팁)

쿼리

“한국 식당에서 처음 방문한 외국인이 당황하지 않으려면 뭘 알아야 해?”

방식 A 응답 (단일 프롬프트)

600자 이상, 5개 섹션. 주요 내용:

  • 반찬은 서비스예요! (공짜이며 리필 가능)
  • 물과 식기는 내가 가져온다 (셀프 서비스)
  • 수저 사용법과 밥 공기 매너
  • “여기요!” 호출 방법
  • 계산은 카운터에서
  • 필수 생존 한국어 3가지

평가: 네이버 블로그, 트립어드바이저와 동일한 내용. 외국인이 이미 어디선가 읽었을 정보. 일반론.

방식 B 응답 (암묵지 청크 기반)

5줄, 실제 함정 중심:

  1. 주문이나 도움이 필요할 때 — 손 들고 눈 맞추며 기다리면 영원히 기다려야 해. 테이블 모서리 호출벨을 눌러야 직원이 반응함
  2. 수저와 포크가 안 보일 때 — 직원에게 가져다 달라고 하지 말고 테이블 상판 아래 숨겨진 서랍을 당겨 확인
  3. 물과 반찬이 안 나올 때 — ‘Self’ 표시 있으면 식당 한구석 정수기와 반찬통에서 직접 담아와야 함
  4. 고깃집에서 고기를 구울 때 — 직원이 불 켜주고 바로 나가면 직접 구워야 함. 직원이 구워주겠다고 하면 집게를 놓아야 함
  5. 계산할 때 — 자리에서 카드 들고 기다리면 서로 어색해짐. 식사 후 바로 일어나 계산대로 걸어가야 함

평가: 블로그에 없는 내용. “테이블 아래 숨겨진 서랍”, “호출벨 vs 눈 맞추기” 등 실제 당황 포인트 직격.

핵심 차이

항목방식 A방식 B
분량600자+5줄
정보 출처GLM 학습 데이터 (일반론)실제 현지인 제보
차별성없음 (블로그와 동일)있음 (경험 기반 함정 중심)
외국인 관점없음foreigner_trap 필드 직접 반영
네이버 블로그 대비동일차별화

4. 테스트 2 — 잘못된 정보 주입 취약점

쿼리

편의점 달러 환전 가능하다는 허위 청크 3개 주입 후 응답 확인

주입한 허위 청크

  • “GS25에서 달러 환전 가능”
  • “ATM에서 외국 카드로 달러 현금 출금 가능”
  • “은행보다 수수료 저렴함”

GLM 응답

허위 정보를 사실로 수용하여 자신감 있게 생성:

“GS25 등 주요 편의점에서 달러 현금 환전이 가능하며…”

평가: GLM은 청크 출처의 신뢰도를 판단하지 못함. 유저 제보를 날 것으로 파이프라인에 투입하면 오정보 생성 위험.

필요한 신뢰 게이트 구조

유저 제보
    ↓
[1차] GLM 팩트체크 — 일반 상식과 충돌하는가?
    ↓ 의심 → 격리 큐
    ↓ 통과 → 임시 인덱스 (낮은 가중치)
[2차] 커뮤니티 검증 — N명 이상 동의
    ↓
정식 인덱스 (높은 가중치)

카테고리별 신뢰 임계값 (안)

팁 유형최소 제보 수이유
문화/예절3개변화 느림, 경험 기반
음식/장소5개폐업/변경 가능
금융/교통10개오정보 위험 높음

5. 결론 및 파이프라인 방향

해자가 되는 이유

단순 API 프롬프트는 다음을 못 함:

  • GLM 학습 데이터 밖의 “당연한 것들” 표현 불가
  • foreigner_trap 필드처럼 외국인 관점의 실패 시나리오 구조화 불가
  • 팁 축적으로 인한 검색 품질 자동 향상 불가
  • 긍정/부정 제보 비율 기반 신뢰도 점수 산출 불가

MVP 파이프라인 (16시간 기준)

유저 제보 (자유 텍스트 1줄)
    ↓
GLM 4.7 enrichment → 구조화 JSON
    ↓
Qdrant (Docker) 벡터 저장
    ↓
시맨틱 검색 → 카드 형태로 제공

6. 현재 데이터셋 현황

수집 현황

  • Gemini: 10개
  • GPT: 10개
  • Claude: 10개
  • 중복 제거 후: 19개

카테고리 분포

카테고리개수
transport6개
food5개
daily5개
manner3개

AI별 강점 비교

AI강점
Gemini구체적 상황 묘사 (화장실 휴지, 수저 서랍 등 디테일)
GPT간결함 (why가 짧아서 청크로 쓰기 좋음)
Claudeforeigner_trap이 생생함 (“밖에서 쪼그리고 먹음”)

파일 위치

locally-frontend/src/data/
├── tacit_tips_test.json   # 초기 시드 7개
├── merged_tips.json       # 머지 완료 19개
└── merge_tips.py          # 머지 스크립트

그래프 뷰