RAG를 3개월 공부했지만 설계하지 못했던 이유

들어가기 전에

: 내가 처음에 착각했던 것.

 

 나는 RAG를 공부하면서 벡터 DB를 붙이면 RAG가 완성된다고 생각했다.
그래서 청킹을 하고 임베딩을 저장하고 검색까지 구현했다.
하지만 막상 서비스 질문을 떠올려보니, 모든 질문이 의미 유사도 검색을 필요로 하지는 않았다.

 

내 서비스는 초기 기반이 되는 데이터는 서울시 API 기반 구조화 데이터다.
그런데 나는 PDF 기반 RAG 사례만 보고 청킹 전략을 고민하고 있었다.
구조화 데이터인데도 문장 단위 분해를 먼저 고민한 것이다.

 

 나는 구현은 했지만 Retrieval 전략을 먼저 정의하지 않았다.
그래서 기능은 동작했지만, 이게 맞는 구조인지 확신이 없었다.

---

GPT왈 '설계는 이 질문부터 시작해야 합니다.

 

1단계 : RAG를 기술이 아니라 서비스 흐름으로 다시 정의할 것.

"그래서... 내 서비스는 무엇을 검색해야 하는가?"

 

1) 사용자는 어떤 질문을 할 것인가?
ex) 오늘 엄마랑 아빠랑 오후 2시에 인전 집에서 출발할 것 같은데 남양주에 가고 싶어.
우리는 드라이브를 좋아하고 식사에는 많은 돈을 쓰고 싶진 않아
커피는 7천원 내에서 경치가 좋은데서 먹고 싶어.
부모님이 음식이 맛 없으면 하루종일 불평불만이 많아서 만하면 어른들이 좋아하는 곳에서 저녁을 먹고싶어.

2) 그 질문은 어떤 데이터 구조를 필요로 하는가?

3) 그 데이터는 문장 검색인가? 필드 검색인가?

4) 유사도 검색이 진짜 필요한가?
: 분기문이 필요할 수도 있겠군.

5. 아니면 필터링 + 요약이 필요한가?

서비스 질문 유형 정리
유형 A : 
유형 B :
유형 C :

---

RAG의 사전적 정의는 다음과 같다.

RAG = LLM에게 넘길 컨텍스트를 내가 어떻게 만들 것인가?

 

: 핵심은 LLM보다 컨텍스트 설계이다.

---

2단계 : RAG를 4단계로 쪼개서 사고할 것.

1) 데이터 구조 정의

    - 원본 데이터는 무엇인가?

    - 구조화 데이터 인가?(API/JSON)

      : 문장 청킹이 아니라, 레코드 단위 설계가 핵심.

    - 비정형 데이터인가(PDF, 텍스트)?

 

2. 질문별 Retrieval 전략

: 가장 중요한 부분으로,

   RAG는 무조건 벡터 검색이 아니라 다음과 같은 질문에 따라 전략을 달리 세워야 한다.

질문	유형전략	비고
“이번 주 전시 뭐 있어?”	필터링 + 날짜 조건	필터기반
“아이랑 가기 좋은 공연 추천”	태그 기반 + 유사도	벡터기반
“덕수궁 관련 문화행사”	키워드 + 임베딩	하이브리드

 

벡터를 쓴다면

- 정말 의미 유사도가 필요한가?

- 아니면 필터링이 더 정확한가?

  : 조합

청킹을 한다면

- 청킹단위

  1) 왜 그렇게 나누는가?

  2) 메타데이터는 무엇인가?

 

3. Context 조립 전략

: 앞에서 검색된 결과를 그냥 던져서는 안되고,

  이 결과를 LLM에게 어떻게 줄 것인지

  어떻게 구조화해서 줄지를 설계 해야한다.

[전시 1]
- 이름:
- 장소:
- 기간:

[전시 2]
...

 

4) LLM 역할 정의

- 단순 요약
- 비교
- 추천(O)
- 재구성(O)

 

: LLM이 결정하게하는 것이 아닌, 역할을 제한해야 한다.