[태그:] LLM

1. 서문

앞선 글에서는 Safety 정책과 폴백·쿠션멘트 설계를 다뤘습니다.
이번에는 이 요소들이 RAG 파이프라인 속에서 어떻게 연결되는지를 이야기하려 합니다.

먼저 간단히 복습하자면:

• LLM (Large Language Model): 대규모 언어 모델. 질문을 이해하고 답변을 생성하는 엔진
• RAG (Retrieval-Augmented Generation): LLM이 답변을 생성하기 전, 검색으로 근거 자료를 찾아 활용하는 최신화 프레임워크
  → 즉, “검색 기반 + 생성형”을 결합해 답변의 신뢰도를 높이는 방식입니다.

파이프라인 자체는 개발팀이 주도적으로 설계·구현했지만,
제가 맡은 역할은 그 흐름이 사용자 경험 차원에서 안정적으로 작동할 수 있도록 기준과 필요사항을 정의하는 것이었습니다.

2. RAG 파이프라인 개요

RAG는 보통 다음 단계를 거칩니다:

1. Input 처리 – 사용자 발화 전처리
2. Retriever – 검색 및 문서 매칭
3. Augment – 검색 결과 정제 및 후보 선택
4. Generator – LLM 응답 생성
5. Output Post-processing – 응답 후처리 및 검증

이 중 기획자의 역할은 각 단계에서 “어떤 경우를 어떻게 처리할지” 기준을 제공하는 것입니다.

3. 단계별 기획자의 터치포인트

각 단계는 개발팀이 주도적으로 구현했지만,
기획자는 사용자 경험 관점에서 기준을 정의하는 역할을 했습니다.

단순 요약이 아니라, 실제로 어떤 일이 일어나는지를 예시와 함께 풀어보겠습니다.

① Input (전처리 & Safety 1)

• 개발팀: 언어 탐지, 금칙어/개인정보(PII) 검출, 입력 포맷 정규화
• 기획:
  • 미지원 언어 → “현재 한국어만 지원합니다. 다시 입력해 주세요.”
  • 특수문자/형식 오류 → “입력하신 문구를 확인해 주세요.”
  • 금칙어/불법 발화/개인정보 → “안전한 서비스 제공을 위해 해당 내용은 안내드릴 수 없습니다.”
  • 계정/결제 등 사람 개입 필요 → 상담사 이관

👉 핵심은 차단/재시도/이관 플로우를 정의하는 것입니다. 이렇게 해야 사용자 경험을 보호하고 시스템 자원도 절약할 수 있습니다.

② Retriever (검색/매칭)

• 개발팀: 쿼리 빌드, 인덱스 검색, 스코어링, Top-K 후보 산출
• 기획:
  • IDK (도메인 안인데 답 없음) vs OOD (도메인 밖 질문) 구분
  • 검색 신뢰도 임계치(Threshold) → 기준 이상 = 답변 생성, 기준 이하 = 추천 리스트 제공
  • 소스 우선순위 = 공식 문서 > 공지 > 커뮤니티

👉 임계치는 초기엔 개발팀이 임의로 정했지만, 실제 운영에서는 “언제 답변을 막고 언제 추천으로 돌릴지”가 사용자 경험에 직결됩니다.

📦 Top-K & Score Threshold란?

• Top-K Retrieval: 검색 결과 중 상위 K개만 가져오는 방식.
  예: 200개 검색 → 상위 5개만 선택 = Top-5. (보통 K=3~10)
• Score Threshold(임계치): 검색 결과의 유사도 점수(score)가 기준 T 이상일 때만 “신뢰 가능”으로 간주.
  예: 0.85 ≥ 0.8 → 답변 생성
  예: 0.55 < 0.8 → “정확한 답변을 찾지 못했습니다. 대신 [추천 리스트]를 확인해 주세요.”
• 왜 기획자가 알아야 할까? 이 값들은 사용자 경험에 직접 영향을 주는 값이기 때문입니다.
  예: T가 너무 높으면 → 답변이 자주 막힘
  예: T가 너무 낮으면 → 엉뚱한 답변까지 노출

③ Augment (컨텍스트 구성)

• 개발팀: Top-K 결과 중 프롬프트에 넣을 자료 정제
• 기획:
  • 최신 자료/공식 자료 우선 순위 설정 (이번 달 공지 > 작년 글, 공식 FAQ > 커뮤니티)
  • 중복 제거 (비슷한 문서 여러 개일 경우 1개만 남김)
  • 신뢰도 낮음 → 다운그레이드 응답 (“정확한 답변은 제공되지 않습니다. 대신 [공식 문서]를 참고하세요.”)

👉 즉, 어떤 자료를 남기고/빼고, 불충분할 때 어떻게 보여줄지를 정하는 단계입니다.

④ Generator (LLM 생성)

• 개발팀: 프롬프트 구성 및 LLM 호출
• 기획:
  • 브랜드 톤·쿠션멘트 정의
    • 게임 = 친근/재밌게 (“이 부분은 아직 준비되지 않았어요 😅”)
    • 금융 = 단정/공식 (“현재 해당 정보는 제공되지 않습니다.”)
  • 신뢰도 낮음 → 정중 거절 + 대체 링크 안내
  • 프롬프트 가드레일
    • 범위 벗어난 질문은 거절
    • 모르면 IDK
    • 출처 없이 단정 금지

👉 답변 자체는 모델이 생성하지만, “어떤 톤과 규칙 안에서 말하게 할지”는 기획이 정합니다.

⑤ Output (후처리 & Safety 2)

• 개발팀: 최종 응답 필터링, 금칙어/민감정보 제거, 마스킹 처리
• 기획:
  • 차단 발생 시 대체 문구 정의
    • “안전한 서비스 제공을 위해 일부 내용은 표시되지 않습니다.”
  • 필요 시 공식 링크/상담 버튼 제공
  • 책임 문구/출처 표기 여부 결정

👉 Output은 마지막 안전망입니다. Input에서 걸러지지 않은 리스크가 여기서 최종적으로 검수됩니다.

5. 경험담 & 마무리

처음엔 “개발팀이 기술적으로 잘 만들겠지”라고 생각했습니다.
하지만 막상 업무를 진행하다 보니, 사용자 안내 기준이 빠진 채로는 파이프라인이 온전히 작동하지 않는다는 걸 알게 되었습니다.

결국 기획자의 역할은 직접 파이프라인을 설계하는 것이 아니라,
각 단계가 사용자 경험 차원에서 일관되게 동작하도록 기준과 필요사항을 정의하고 정리하는 것이었습니다.

겉으로 보면 RAG 파이프라인은 기술 중심 프로세스처럼 보입니다.
그러나 실제로는 Safety 정책, 폴백, 쿠션멘트 같은 사용자 경험 설계가 파이프라인 속에 녹아 있어야 비로소 서비스가 제대로 굴러갑니다.

결국 기획자는 기술의 빈 공간을 채우는 사람이 아니라,
서비스 전체가 일관된 경험을 주도록 연결해주는 역할을 맡습니다.

P.S. 

RAG 2.0이 아직 일반화되지도 않았는데, 벌써 RAG 3.0이 논의될 정도로
AI는 지금도 하루가 다르게 발전하고 있습니다.

따라서 지금의 RAG 파이프라인 구축은 어디까지나 하나의 프레임워크이자 레퍼런스일 뿐입니다.
앞으로 새로운 기술 트렌드에 맞춰 계속 진화할 것이고,
기획자는 급변하는 흐름 속에서 유연하게 기준과 해결책을 설계하는 태도를 가져야 할 것입니다.