“대화”와 “검색”은 다르다 — RAG 설계를 바꾼 기준 (feat.설명끝~)

https://honge1122.tistory.com/144

질문을 그대로 검색하지 않는 이유 - 질문 재정의 단계

애진작에 끝났는데 이제서야 업로드..ㅎㅎ

 

1. 서비스 설명을 준비하다 든 생각

서비스 구조 설명을 준비하면서 한 가지 고민이 들었다.

Azure AI Search의 filter를 설명하다 보니
“이거 PostgreSQL의 WHERE 절과 같은 개념 아닌가?”라는 생각이었다.

(참고로 다른 팀원분들은 PostgreSQL을 사용한다)

 

기능적으로 보면 크게 다르지 않다

WHERE → 조건에 맞는 row만 남김
filter → 조건에 맞는 document만 남김

결국 둘 다

검색 결과에서 조건에 맞지 않는 데이터를 제외하는 역할이라는 점에서는 동일하다

 

그래서 PostgreSQL을 사용하는 팀원들에게는

filter는 WHERE와 같은 개념이라고 설명하는 것이 가장 직관적이었다.

 

 

2. 설명은 구조보다 화면부터.

막상 설명을 시작해보니
팀원 중 일부는 이 서비스 자체를 처음 접하는 상태였다.

 

이 상황에서 구조부터 설명하면
전체 맥락을 잡기 어렵다고 판단했다.

 

그래서 순서를 바꿨다:

1. 실제 서비스 화면
2. 서비스 간 차이
3. 내부 구조
4. 질문 재정의 관련 로직

 

결과적으로 이 흐름이 훨씬 이해가 빨랐다

이게 어떤 서비스인지”를 먼저 보여주고
“왜 이렇게 설계됐는지”를 설명하는 방식이 더 효과적이었다.

 

3. 두 서비스의 가장 큰 차이

질문 방식이 완전히 다르다.

구분	서비스A	서비스B
사용자	통화 중인 사람	검색하는 사람
질문 형태	이어지는 질문	단일 질문
맥락	있음	없음

 

쉽게 말해

하나는 대화형, 다른 하나는 검색형이다

 

 

4. 중요: 그래서 내부 구조도 다르다

질문 방식이 다르면
처리 구조도 자연스럽게 달라진다.

구분	서비스A	서비스B
처리	히스토리 기반	x
대화 흐름	유지	x

등등..(여기까지만 정리하겠다.. ㅎㅎ)

 

아무튼 이 차이 때문에 다음 요소들도 분리된다:

1. 히스토리 적재 인덱스

2. RAG 참조 데이터

3. 사용 프롬프트

 

실제 설명할 때 가장 강조한 부분이기도 하다

 

 

5. 결론

이 경험을 통해 느낀 건
LLM 서비스를 설명할 때는 모델이나 인덱스보다 먼저 “질문 유형”을 설명해야 한다는 점이다.

서비스의 구조는 결국 질문 구조에서 시작되기 때문이다.