📚 Retrieval

이전 글을 통해, VectorDB(Elastic)에 문서를 Vector 색인 하여 저장하였습니다.

이번에는, 사용자의 질문에 유사한 문서를 찾아내는 Retrieval(검색) 과정을 진행하겠습니다.

목표

사용자의 질문과 관련 있는 문서를 검색

적용

전체 코드는, Github 에서 확인할 수 있습니다.

질문 End-point 추가

Controller - Service 를 추가하여, 사용자의 질문을 받아 응답하는 Endpoint 를 하나 생성합니다.

추후, 챗봇과 연관되어 사용 될 예정입니다.
따라서, 현재 응답은 SseEmitter 로 되어있습니다.
코드에 Swagger 관련이 들어가있는데, 제거하셔도 무관합니다.

AiController

@RestController
@RequiredArgsConstructor
@RequestMapping("/ai")
@Tag(name = "Ai Controller", description = "Ai 관련 테스트 컨트롤러")
public class AiController {

	private final AiService aiService;

	@PostMapping("/stream/search")
	@Operation(summary = "[AI] 관련 블로그 포스트 찾아주기")
	public SseEmitter searchPosts(
		@Valid @RequestBody AiRequest.AiSearchPost request
	) {
		SseEmitter emitter = new SseEmitter(60_000L);
		aiService.searchPosts(request, emitter);
		return emitter;
	}
}

AiService

@Slf4j
@Service
@RequiredArgsConstructor
public class AiService {

	private final EmbeddingService embeddingService;
	private final StreamingChatModel streamingChatModel;

	public void searchPosts(AiRequest.AiSearchPost request, SseEmitter emitter) {
		EmbeddingSearchResult<TextSegment> searchResult =
			embeddingService.searchRetrievalPost(request.getSentence(), request.getFilter());
	}

AiRequest(dto)

여기서 사용되는 filter는, Optional 로, 검색 조건에 추가로 활용 될 요소입니다.
vector db 에 검색을 할 때, metadata 에 들어있는 요소들을 추가로 활용할 때 사용됩니다.

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public class AiRequest {

	@Getter
	@AllArgsConstructor(access = AccessLevel.PRIVATE)
	@NoArgsConstructor(access = AccessLevel.PROTECTED)
	public static class AiSearchPost {
		@NotBlank
		private String sentence;
		private List<String> filter = new ArrayList<>();

		public static AiSearchPost of(String sentence, List<String> filter) {
			return new AiSearchPost(sentence, filter);
		}
	}
}

다음은 실제로 Langchain4J 의 추상화 된 EmbeddingStore 을 통해서 ELK 에서 관련된 문서를 가져오도록 하겠습니다.

Retrieval 구현

기존에 만들어 둔, EmbeddingOpenAiService 에, 다음과 같은 sentence 로, 관련 있는 문서를 검색합니다.

입력으로 들어오는, 질문을 Embedding 처리해서 사용합니다.

❗ 필수적으로 원문을 저장할 때 사용한 Embedding 모델과 차원수를 동일하게 맞춰야 합니다.

EmbeddingOpenAiService

위에서 입력된 filter 는 metadata 내, CATEGORY 항목에서 필터링에 사용됩니다.
이렇게 처리하면, 조금 더 정확한 문서를 찾을 확률이 높아집니다.

@Slf4j
@Service
@RequiredArgsConstructor
public class EmbeddingOpenAiService implements EmbeddingService {
     // 기존 bean 그대로

     //createEmbeddingPost 그대로

     /**
	 * 입력 문장과 관련있는, 문서 조회
	 * @param sentence 문서
	 */
	@Override
	public EmbeddingSearchResult<TextSegment> searchRetrievalPost(String sentence, @NonNull List<String> filter) {
		log.debug("Searching for: '{}', filter: {}", sentence, filter);

		try {
			// 1. 질문 문장 임베딩 화
			Embedding queryEmbedding = embeddingModel.embed(sentence).content();

			// 2. EmbeddingSearchRequest 생성
			EmbeddingSearchRequest.EmbeddingSearchRequestBuilder requestBuilder = EmbeddingSearchRequest
				.builder()
				.queryEmbedding(queryEmbedding)
				.maxResults(10)
				.minScore(0.6);

			// 2-1. Filter 추가
			if (!filter.isEmpty()) {
				log.debug("add keyword filed : {}", filter);
				List<String> lowerCaseFilter = filter.stream().map(String::toLowerCase).toList();
				Filter categoryFilter = MetadataFilterBuilder.metadataKey(CATEGORY).isIn(lowerCaseFilter);
				requestBuilder.filter(categoryFilter);
			}
			EmbeddingSearchRequest searchRequest = requestBuilder.build();

			// 3. Vector DB 에 조회 후 반환
			return embeddingStore.search(searchRequest);
		} catch (Exception e) {
			log.error("Search failed details:", e);
		}

		return null;
	}
}

(Optional) 수동 Embedding 이 필요하다면?

바로 다음에, 검색을 진행할 것 입니다.

이때 vector db 에 저장된 내용이 없으면 검색 결과가 나오지 않을 것 입니다.

따라서 필요하다면 다음과 같이 수동으로 특정 post 를 embedding 해주는 end-point 를 만들어 미리 데이터를 만들어 두시기 바랍니다.

AiController

@RestController
@RequiredArgsConstructor
@RequestMapping("/ai")
@Tag(name = "Ai Controller", description = "Ai 관련 테스트 컨트롤러")
public class AiController {

	// ...

	@PostMapping("/post/embedding")
	@Operation(summary = "수동 post embedding 후, vector db 에 저장")
	public void embeddingPost(
		@RequestBody EmbeddingPostRequest request
	) {
		aiService.embeddingPosts(request);
	}
}

AiService

@Slf4j
@Service
@RequiredArgsConstructor
public class AiService {

    //....

	/**
	 * 수동으로, 특정 포스팅 임베딩 후 db 저장
	 * elk 신규 업데이트 후, 기존 document 가 누락되어 있는 경우 사용
	 * @param request
	 */
	@Transactional
	public void embeddingPosts(EmbeddingPostRequest request) {
		for (Long id : request.postIdList()) {
			Optional<PostEntity> findOptionalPost = postRepository.findById(id);
			if (findOptionalPost.isEmpty())
				continue;
			PostEntity findPost = findOptionalPost.get();

			List<PostTagEntity> findPostTagList = postTagRepository.findAllByPost(findPost);
			List<TagEntity> findTagList = findPostTagList.stream().map(PostTagEntity::getTag).toList();

			try {
				embeddingService.createEmbeddingPost(findPost, findTagList);
			} catch (Exception e) {
				EmbeddingFailureEntity failure =
					EmbeddingFailureEntity.of(findPost.getId(), e.getMessage(), EmbeddingJob.CREATE);
				embeddingFailureRepository.save(failure);
			}
		}
	}
}

Retrieval 확인

Breakpoint 를 걸어, 재대로 문서를 찾아오는지 확인합니다.

현재 api 가 문서를 응답하지 않기 떄문에, debug 로 확인합니다.

searchPosts에 embeddingService.searchRetrievalPost 부분을 확인합니다.

현재 db 에 멀티쓰레드와 관련된 정보가 있기 때문에, 질문으로 "멀티 쓰레드란?" 라고 물어보겠습니다.

이렇게 관련 있는 포스트 들이 score 에 따라 응답이 되면 성공입니다.

Custom 하기

EmbeddingOpenAiService 의 searchRetrievalPost 메서드는 사용자가 입력한 문장을 임베딩(Embedding)으로 변환하고, 이를 기반으로 벡터 DB에서 유사한 문서를 검색하여 반환하는 역할을 수행합니다.

현재 구현에서는 최대 10개의 검색 결과를 반환하도록 하고 있으며, 유사도 점수는 최소 0.6 이상인 데이터만 걸러지도록 설정되어 있습니다.

이렇게 검색된 문서는 이후 LLM 호출 시 함께 제공되어, 생성 모델이 보다 정확한 결과를 만들어낼 수 있도록 참고 문서(Retrieval Document)로 활용됩니다.

검색 결과 수가 많아질수록 더 풍부한 정보가 LLM으로 전달되어 답변 품질 향상에 도움이 될 수 있습니다.

하지만 결과 문서가 늘어나는 만큼 토큰 사용량이 증가하게 되고, 이는 모델의 컨텍스트 제한을 빠르게 소모하게 됩니다.

특히 RAG 방식에서는 “입력 프롬프트 + 검색된 문서 + 모델이 생성하는 출력” 이 총합으로 컨텍스트 한도 내에 있어야 하므로, 검색 결과 개수와 문서 길이는 적절히 균형 잡는 것이 중요합니다.

실제 사용하는 모델의 허용 토큰 수와, 각 문서가 split 되어 저장된 토큰 수, 등을 적절히 잘 고려해야 합니다.

(Optinal) 토큰 수 계산해보기

현재 코드에서는, DocumentSplitters.recursive(1500, 300) 으로 원본 문서를 쪼개어 사용하고 있습니다.

저는 현재 GPT-5 모델을 사용하고 있고, 이 모델은

입력(input) 최대 272,000 tokens
출력(output) 최대 128,000 tokens
합산 총 400,000 tokens 컨텍스트 창을 허용하고 있습니다. (링크)

한국어의 경우, 영어보다 토큰을 조금 더 많이 사용합니다.

넉넉하게 한글자 = 1토큰 정도의 범위를 가진다고 생각하면 좋습니다.

현재, 한 Document 는 최대 1500자로 split 하고 있습니다.

즉 보수적으로 1문서당 1500 Token 으로 치환하여 생각하겠습니다.

10개의 Document 를 검색하여 가져오도록 하고 있기 때문에, Retrieval 시 조회 되는 Token 은 최대 15,000 Token 만큼 사용합니다.

또한 추후에 사용될 프롬프트가 최대 1000자를 넘지 않을 것이고, 질문 또한 100자를 넘길 이유가 없기 때문에 매우 널널한 설정이라고 보시면 됩니다.

하지만 널널하다는 정보가 관련 문서를 더 많이 찾아와도 된다는 것은 아닙니다.
관련이 없는 문서가 나올 가능성도 있기 때문에 적절한 조정이 필요합니다.

다음으로

다음으로는, 찾아온 문서를 바탕으로 프롬프트를 작성해, LLM 에게 질문하는 RAG 과정을 마무리 하겠습니다.

🤖 [RAG 구현] Langchain4J 를 활용한 Vector DB 저장 (Retrieval 구현) #2

스택 시리즈LLM & RAG with Langchain4J