📚 Vector DB

앞선 글을 통해, RAG 의 필요성에 대해서 알아보았습니다.

이번 글부터는, 쭉 RAG 를 구현하는 작업을 진행해 보겠습니다.

내용 길어요!! 주의!!

목표

전체적인 해당 시리즈의 전체 목표는 저희 도메인(백과 기술 블로그)의 글을 바탕으로 응답을 생성하는 Chat봇을 만드는 것이 목표입니다.

FE 는 전문적으로 학습한 사람이 아니라, 제외 될 수도 있습니다...

따라서 다음과 같은 절차로 진행됩니다.

블로그 글을 Vector 화 시켜, Embedding Vecotr Database 에 저장
저장한 Vector DB 에 질문과 관련이 있는 블로그 글(Document) 조회
LLM 모델에 찾아온 Document 를 기반으로 질문 및 응답 생성 (Stream)

사용하게 될 기술은 다음과 같습니다.

Spring
3.5 ↑
VectorDB
ELK : 9.2
LangChain4J
1.8 (latest)
가상화
Docker / docker-compose
Open AI Embedding Model
text-embedding-3-large

Embedding Vector

해당 글은 기술에 대한 소개 보다는, 적용 하기를 지향하므로, 간단한 설명과 함께 더 알아 볼 수 있는 링크를 함께 제공하겠습니다.
물론, 저는 취미로 학습을 하는 것 이기 때문에, 전문 서적으로 학습 하기 보다는 공식 문서와 여러 Documents 들을 확인하므로 전문성이 조금 떨어질 수 있습니다.

Embedding Vector 란?

Elastic사 에서는, Embedding Vector 를 다음과 같이 정의 하고 설명합니다. (링크)

벡터 임베딩(Vector Embedding)은 텍스트, 이미지, 오디오와 같은 복잡한 데이터를 기계가 이해할 수 있는 숫자 리스트(배열)로 변환한 것을 의미합니다.
쉽게 말해, "사람의 언어를 AI가 이해하고 계산할 수 있는 좌표 값으로 번역하는 것"입니다.

좌표(숫자)로 바꾸는 이유는 명확합니다.

컴퓨터는 "사과" 와 "Apple" 이 같은 뜻인지, "자동차"와 "배" 가 [탈것] 이라는 공통 관심사에 묶여있는지 알 수 없습니다.

하지만 이 단어를 벡터로 변환하면 의미 적으로 가까운 좌표에 있는 것을 확인할 수 있습니다.

Embedding Projector 에 접속하면, TensorFlow 에서 제공하는 임베딩(벡터) 데이터의 유사도를 간략하게 확인해 볼 수 있습니다.

Car 를 검색하면, 유사한 의미를 가진 Boat 가 같이 검색되는 것을 확인할 수 있습니다.

유사도 확인

임베딩 된 벡터는 거대한 다차원 공간(지도) 위의 좌표라고 생각하면 됩니다.

임베딩된 벡터는 거대한 다차원 공간(지도) 위의 좌표라고 생각하면 됩니다.

비슷한 의미를 가진 단어들은 지도상에서 가깝게 위치합니다. (예: 학교 ↔ 학생)
전혀 다른 의미를 가진 단어들은 멀리 떨어져 위치합니다. (예: 학교 ↔ 바나나)

RAG에서는 바로 이 원리를 이용해, 사용자의 질문과 '거리가 가장 가까운(의미가 가장 유사한)' 블로그 글을 찾아내는 것입니다.

적용 시작

ELK 설치
Open AI Embedding 모델 준비
글 Embedding Vector 처리 및 저장

ELK 설치

본 글은, ELK 를 전문적으로 다루는 글이 아니기 때문에, 정말 필요한 설명만 추가됩니다.
ELK 관련 내용은, Elastci Search! 를 참고하시기 바랍니다.
~~사실 여기보다 공식 문서가 더 좋아요!~~

elk-docker-compose.yml

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:9.2.0
    container_name: elasticsearch
    networks:
      - baekgwa-network
    ports:
      - "9200:9200"
    volumes:
      - es-data:/usr/share/elasticsearch/data
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms1g -Xmx1g
      - xpack.security.enabled=false
      - xpack.security.http.ssl.enabled=false
    restart: always

  kibana:
    image: docker.elastic.co/kibana/kibana:9.2.0
    container_name: kibana
    networks:
      - baekgwa-network
    ports:
      - "5601:5601"
    volumes:
      - kibana-data:/usr/share/kibana/data
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    restart: always
    depends_on:
      - elasticsearch

#  logstash:
#    image: docker.elastic.co/logstash/logstash:9.2.0
#    container_name: logstash
#    networks:
#      - baekgwa-network
#    ports:
#      - "5044:5044" #Logback TCP 입력 포트
#    volumes:
#      - ./logstash/pipeline:/usr/share/logstash/pipeline:ro
#    environment:
#      - LS_JAVA_OPTS=-Xms1g -Xmx1g
#    restart: always
#    depends_on:
#      - elasticsearch

volumes:
  es-data:
    driver: local
  kibana-data:
    driver: local

networks:
  baekgwa-network:
    external: true

Logstash 는 현재 구조에서 필요하지 않기 때문에 Up 하지 않아도 됩니다.
혹시, 필요하신 분이 계실까봐 (로그에 활용 또는 기존 ELK 에 사용...?) 같이 올려놓습니다.

OpenAi 준비

데이터를 Embedding 하기 위해서는, 임베딩 모델이 필요합니다.

OpenAI 사의 최신 Embedding 모델인 text-embedding-3-large 을 사용해서 처리하겠습니다. (embedding-3-large)

저희가 사용할 Langchain4J 에서는, 자체적인 경량화 된 임베딩 모델을 로컬에서 사용하여 돌릴 수 있도록 구성해 놓았습니다.
다만, 다국어를 지원하지 않고, (특히 한국어 성능 매우 떨어짐)
GPU 를 사용하는 등, 제 클라우드 환경과 도메인 상황에는 맞지 않아 채택하지는 않았습니다.
궁금하신 분은, GIthub 를 참고하시기 바랍니다.

~~사실 엄청 대용량이 아닌 이상, OpenAi 의 Embedding 모델또한 엄청 저렴합니다.~~

OpenAi Platform 에 접속해, 로그인 후 프로젝트 생성 하고, API 키를 만들어 줍니다.

가이드는 wikidocs 를 참고하시거나, 서치를 통해 아무 블로그 글을 따라해도 상관없습니다.

중요!!
발급받은 키는 생성 당시에만 보이고, 그 이후로는 다시 확인할 수 없습니다! 복사해서 잘 저장해 놓아주세요!

다음으로, spring 프로젝트의 .env 등에 변수로 등록하고 yml 에서 꺼내서 쓸 수 있도록 구성해줍니다.

.env

# Open Ai
OPENAI_API_KEY=여기에 API 키를 넣어주세요! #발급 받은 API 키 넣기
OPENAI_EMBEDDING_MODEL_NAME=text-embedding-3-large #여기엔 모델이 들어가면 됩니다!

application.yml

...
open-ai:
  apiKey: ${OPENAI_API_KEY}
  embeddingModelName: ${OPENAI_EMBEDDING_MODEL_NAME}
...

다음으로, Langchain 프레임워크를 위해, 의존성을 추가 해 줍니다.

{    
    ....
    // LangChain4J
    implementation 'dev.langchain4j:langchain4j:1.8.0'
    implementation 'dev.langchain4j:langchain4j-open-ai:1.8.0'
    implementation 'dev.langchain4j:langchain4j-elasticsearch:1.8.0-beta15'
    ....
}

각각 Langchain 의 메인 모듈과, open ai 를 위한 모듈, 그리고 elk 에 access 하기 위한 모듈 입니다.

별도의 Config 파일을 만들어, 추상화된 EmbeddingModel 을 Bean 등록하여 사용할 수 있도록 합니다.

해당 파트는, langchain4J 의 공식 문서 를 참고하여 작성하였습니다.

OpenAiConfig

@Configuration
@RequiredArgsConstructor
public class OpenAiConfig {

	private final OpenAiProperties openAiProperties;

	@Bean
	public EmbeddingModel embeddingModel() {
		return OpenAiEmbeddingModel.builder()
			.apiKey(openAiProperties.getApiKey())
			.modelName(openAiProperties.getEmbeddingModelName())
			.user("baekgwa")
			.build();
	}
}

OpenAiProperties?
이건 제가 별도로 편하게 yml 의 변수를 가져오기 위해 만든 클래스 입니다.
@Value 나 다른 다른 방법을 통해 application.yml 의 변수를 가져오셔도 무관합니다.
@Setter
@Getter
@Component
@ConfigurationProperties(prefix = "open-ai")
public class OpenAiProperties {
	private String apiKey;
	private String embeddingModelName;
	private String llmModelName;
}

Embedding Store 생성

Embedding Store 은, Langchain4J 에서, 임베딩 벡터에 접근할 수 있도록 추상화 해놓은 인터페이스 입니다.

현재 저희는 ElasticSearch 를 Vector DB 로 활용할 예정입니다.

공식문서 와 예제 를 통해 진행하였습니다.

ElasticsearchConfig

@Slf4j
@Configuration
@RequiredArgsConstructor
public class ElasticsearchConfig {

	private final ElasticSearchProperties elasticSearchProperties;

	@Bean
	public EmbeddingStore<TextSegment> embeddingStore() throws IOException {
		RestClient restClient = RestClient
			.builder(HttpHost.create(elasticSearchProperties.getUrl()))
			.build();

		ensureIndexExists(restClient, elasticSearchProperties.getEmbeddingIndexName());

		return ElasticsearchEmbeddingStore
			.builder()
			.indexName(elasticSearchProperties.getEmbeddingIndexName())
			// .dimension() // deprecated
			.restClient(restClient)
			.build();
	}

	private void ensureIndexExists(RestClient client, String indexName) throws IOException {
		try {
			Response response = client.performRequest(new Request("HEAD", "/" + indexName));
			int statusCode = response.getStatusLine().getStatusCode();
			if (statusCode == 200) {
				log.debug("Elasticsearch index [{}] already exists.", indexName);
				return;
			}
		} catch (ResponseException e) {
			if (e.getResponse().getStatusLine().getStatusCode() != 404) {
				throw e;
			}
		}

		log.info("Creating Elasticsearch index [{}] with custom settings...", indexName);
		Request createRequest = new Request("PUT", "/" + indexName);
		createRequest.setJsonEntity("""
			{
			  "settings": {
			    "index.mapping.exclude_source_vectors": false
			  },
			  "mappings": {
			    "properties": {
			      "text": { "type": "text" },
			      "metadata": { "type": "object" },
			      "vector": {
			        "type": "dense_vector",
			        "dims": 3072,
			        "index": true,
			        "similarity": "cosine"
			      }
			    }
			  }
			}
			""");
		client.performRequest(createRequest);
		log.debug("Elasticsearch index [{}] created successfully.", indexName);
	}
}

기본적으로 Index 가 없다면 (Elastic 에서 document 를 저장하는 단위? rdb 에서 table 이라고 생각하시면 됩니다) 자동으로 생성하게 되는데, 여기서 별도의 버그가 있어, 수동으로 index 를 생성하도록 하였습니다.

현재, 버그 사항은 Langchain4J 에 이슈로 제보 되어 있고, Maintainer 에게 contribute 제안을 받아 시간날 때 기여 예정입니다...
GITHUB
처리되면 해당 부분을 별도의 포스트로 다루거나, 내용을 추가하도록 하겠습니다.

중간에, Index 를 만드는 과정 중, 차원(Dimension) 지정하는 부분이 있는데, 사용하는 Embedding 모델에 따라 다르니, 잘 검색해보고 적용하시기 바랍니다.

text-embedding-3-large 은 차원을 지정할 수 있지만, 지정하지 않는다면 기본 3072 입니다.
https://openai.com/index/new-embedding-models-and-api-updates/ 참고

Embedding 처리

별도의 임베딩 처리를 위한 Service 로직을 생성해주도록 하겠습니다.

본 글에서는, 의존성 역전을 고려하여 (OpenAi 말고 다른 Embedding 모델이나, ELK 등을 사용할 수도 있다는 가정을 하고 진행) interface 로 적용하였습니다.

EmbeddingService (interface)

public interface EmbeddingService {

	void createEmbeddingPost(PostEntity post, List<TagEntity> tagList);
}

EmbeddingOpenAiService

@Slf4j
@Service
@RequiredArgsConstructor
public class EmbeddingOpenAiService implements EmbeddingService {

	private final EmbeddingModel embeddingModel;
	private final EmbeddingFailureRepository embeddingFailureRepository;
	private final EmbeddingStore<TextSegment> embeddingStore;
	private final UrlProperties urlProperties;

	@Override
	public void createEmbeddingPost(PostEntity post, List<TagEntity> tagList) {
		log.debug("Create embedding for postId={}", post.getId());

		try {
			// 1. content 내용, html -> text 변환 by Jsoup
			String content = Jsoup.parse(post.getContent()).text();

			// 2. metadata 생성
			// todo: 현재, Langchain4j 에서, List 타입을 지원하지 않음.
			// 추후, 업데이트 된다면, List 형태를 추가적으로 전달해서, tag 관련 내용도 필터링 될 수 있도록 구성
			String tags = tagList.stream()
				.map(tag -> tag.getName().toLowerCase())
				.collect(Collectors.joining(","));

			Metadata metadata = Metadata.from(Map.of(
				ID, post.getId(),
				TITLE, post.getTitle(),
				SLUG, post.getSlug(),
				CATEGORY, post.getCategory().getName().toLowerCase(),
				TAGS, tags,
				DESCRIPTION, post.getDescription(),
				CREATED_AT, post.getCreatedAt().toString(),
				SOURCE, generateOriginSource(urlProperties.getFrontend(), post.getSlug())
			));

			// 3. Document 생성 및 청킹
			Document document = Document.from(content, metadata);
			DocumentSplitter splitter = DocumentSplitters.recursive(1500, 300);
			List<TextSegment> textSegmentList = splitter.split(document)
				.stream()
				.map(segment -> TextSegment.from(segment.text(), metadata))
				.toList();

			// 4. 임베딩 데이터 생성 with OpenAi
			Response<List<Embedding>> embeddingResponse = null;
			embeddingResponse = embeddingModel.embedAll(textSegmentList);
			log.debug("Generated {} embeddings", embeddingResponse.content().size());

			// 5. Vector DB(Elasticsearch) 저장
			embeddingStore.addAll(embeddingResponse.content(), textSegmentList);
			log.debug("Successfully embedded and stored postId={}", post.getId());

		} catch (Exception e) {
			log.warn("Embedding failed for postId={}: {}", post.getId(), e.getMessage());
			EmbeddingFailureEntity failure = EmbeddingFailureEntity.of(post.getId(), e.getMessage(),
				EmbeddingJob.CREATE);
			embeddingFailureRepository.save(failure);
			throw e;
		}
	}

	private String generateOriginSource(String feUrl, String slug) {
		return feUrl + "/blog/" + slug;
	}
}

혹시나 궁금하실 분을 위한 Entity 소개 (각자의 도메인에 맞게! 참고만 하세요!)

CREATE TABLE `post`
(
    `id`              BIGINT           NOT NULL AUTO_INCREMENT,
    `title`           VARCHAR(255)     NOT NULL,
    `content`         TEXT             NOT NULL,
    `description`     VARCHAR(255)     NOT NULL,
    `view_count`      INTEGER UNSIGNED NOT NULL DEFAULT 0,
    `category_id`     BIGINT           NOT NULL,
    `thumbnail_image` text             NULL,
    `slug`            VARCHAR(255)     NOT NULL,
    `created_at`      DATETIME         NOT NULL,
    `modified_at`     DATETIME         NOT NULL,
    PRIMARY KEY `pk_post_id` (`id`),
    FOREIGN KEY `fk_post_category_id` (`category_id`) REFERENCES `category` (`id`),
    UNIQUE KEY `uk_post_slug` (`slug`)
);

Vector 화 할 데이터는, content 이고, 나머지 내용들은 Metadata 로써 활용됩니다.

현재, content(본문)은 HTML 형식으로 저장되어있어, jsoup 을 사용하여 파싱해주도록 합니다.

Metadata 란?
간단히 정의하면 "데이터를 설명하는 데이터"입니다. 우리가 저장하려는 핵심 데이터가 '블로그 본문(Content)'이라면, 메타데이터는 그 본문을 꾸며주는 '이름표'나 '속성'과 같습니다.
단순히 본문만 저장해도 검색은 되지만, 메타데이터가 없으면 RAG의 품질과 기능이 크게 떨어집니다. 그 이유는 크게 두 가지입니다.
1. 효율적인 검색 필터링 (Filtering)
2. 정확한 출처 제공 (Source Reference)

(Optional) Splitter 를 활용한 청킹

Langchain4J Splitter 를 참고하여 작성하였습니다.
이미 적용되어 있지만, 청킹에 대한 내용입니다.
이론적인 부분이 있어, 스킵 하실 분은 넘어가셔도 됩니다.

코드에서 DocumentSplitters를 사용하여 긴 본문을 쪼개는 과정을 보셨을 겁니다. 이를 Chunking(청킹)이라고 하는데, RAG 성능을 좌우하는 아주 중요한 작업입니다. 왜 굳이 멀쩡한 글을 토막 내야 할까요?

LLM의 기억력 한계 (Context Window)

가장 현실적인 이유는 LLM이 한 번에 읽을 수 있는 글자 수(토큰)에 제한이 있기 때문입니다. GPT-4 같은 모델도 입력받을 수 있는 길이에 한계가 있습니다. 만약 전공 서적 한 권 분량의 긴 글을 통째로 프롬프트에 넣으려 하면, "Too many tokens" 에러가 발생하거나 비용이 폭발적으로 증가합니다.

검색 정확도 (Vector의 희석 문제)

사실 더 중요한 이유는 검색의 정확도 때문입니다.

통째로 저장할 때: "자바의 정석"이라는 긴 글을 하나의 벡터로 만들면, 그 안에는 '변수', '제어문', '객체지향', '스레드' 등 온갖 주제가 섞이게 됩니다. 이 벡터는 특징이 흐릿해서(희석되어), 사용자가 "스레드"를 물어봤을 때 정확하게 매칭되지 않을 수 있습니다.
쪼개서 저장할 때: 글을 문단 단위로 쪼개면, 어떤 조각은 '스레드'에 대해서만 강력하게 설명하고 있을 겁니다. 이 조각의 벡터는 "스레드"라는 질문과 아주 강하게 반응하여 검색 결과 상단에 노출됩니다.

즉, "두루뭉술한 전체 요약본"보다 "구체적인 페이지 한 장"을 찾는 것이 RAG에서는 훨씬 유리합니다

Ovelap(중복)은 왜 두나요?
코드를 보면 recursive(1500, 300)이라고 되어 있는데, 뒤의 300이 바로 Overlap(중복) 수치입니다.
글을 칼로 무 자르듯 딱 잘라버리면 문맥이 끊길 위험이 있습니다.
[청킹 1] ...그래서 범인은 바로 [청킹 2] 홍길동이었다...
이렇게 잘리면 AI는 '범인이 누군지', '홍길동이 뭘 했는지' 파악하기 어렵습니다. 그래서 앞뒤 내용을 300자 정도 겹치게(Overlap) 잘라서 문맥의 연결고리를 유지해 주는 것입니다.

(Optional) Embedding fail 생성

Optional!
필수가 아닙니다!
조금 더 단단한 서비스를 위한 구성입니다.

만약, OpenAI 가 갑자기 응답을 주지 않거나, 충전 금액이 부족하거나 해서 Embedding 이 되지 않는 다면 어떻게 해야 할까요?

추후에 배치작업을 통해 실패한 Embedding 에 대해서 처리를 진행 할 수 있도록 구성하거나, 로그를 통해 확인을 해야 합니다.

따라서, 별도의 Entity 통해 실패에 대한 관리를 진행 해 주겠습니다.

EmbeddingFailureEntity

@Entity
@Getter
@Table(name = "embedding_failure")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class EmbeddingFailureEntity extends TemporalEntity {

	@Id
	@Column(name = "id")
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Long id;

	@Column(name = "post_id", unique = true, nullable = false)
	private Long postId;

	@Enumerated(EnumType.STRING)
	@Column(name = "embedding_job", nullable = false)
	private EmbeddingJob embeddingJob;

	@Column(name = "reason", nullable = false)
	private String reason;

	public EmbeddingFailureEntity(Long postId, EmbeddingJob embeddingJob, String reason) {
		this.postId = postId;
		this.embeddingJob = embeddingJob;
		this.reason = reason;
	}

	public static EmbeddingFailureEntity of(Long postId, String reason, EmbeddingJob embeddingJob) {
		return new EmbeddingFailureEntity(postId, embeddingJob, reason);
	}
}

TemporalEntity 는 그냥 JPA Auditing 기능을 위한 생성일, 수정일 용 MappedSuperClass 입니다!

@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
@Getter
public class TemporalEntity {
	@CreatedDate
	@Column(name = "created_at", updatable = false, nullable = false)
	private LocalDateTime createdAt;

	@LastModifiedDate
	@Column(name = "modified_at", nullable = false)
	private LocalDateTime modifiedAt;
}

EmbeddingFailureRepository

public interface EmbeddingFailureRepository extends JpaRepository<EmbeddingFailureEntity, Long> {
}

Embedding 처리 용 Event 등록

저희의 목표는 블로그 글을 Embedding 처리하는 것 입니다.

따라서, 블로그 글을 생성하는 로직이 진행 될 때, Embedding 처리를 진행하면 됩니다.

여기서는 이벤트를 활용하여 별도의 쓰레드에서 진행될 수 있도록 비동기 적으로 처리하도록 하겠습니다.

왜 비동기 적으로 처리하나요?
크게 두 가지 이유가 있습니다.
게시글을 생성하는 API 는 게시글을 저장하는 목적을 가집니다.
타이밍 상, [POST] 게시글 할때, Embedding 을 처리하는 것이 가장 어울리는 시나리오 지만, 명백하게 처리 흐름의 목적(관심사)가 다릅니다.
게시글 작성 API 의 응답 속도가 현저히 느려집니다.
DB에 저장하고 난 후, 별도의 Embedding 작업과 ELK 저장 로직 등이 추가되면 불필요하게 API 의 응답 속도에 영향을 끼치게 됩니다.

추가적으로, 비동기로 구성하지 않으면, 하나의 트랜잭션 관리또한 매우 복잡해 집니다.

먼저, 비동기 처리를 위해 Async 기능을 켜주고, 비동기에서 실행될 쓰레드를 재활용 하기 위해, Thread pool 을 하나 만들어 주겠습니다.

왜 별도의 Thread pool 을 만드나요?
기본적으로 spring 에서 비동기로 함수를 실행하게 된다면, thread 를 새로 생성해서 진행하게 됩니다. SimpleAsyncTaskExecutor

사실 Thread 를 만드는 과정은 생각보다 무거운 작업입니다.
저희가 사용하는 Tomcat 서버, DB 연결을 위한 DB Connection (Hikari) 또한 이를 인지하고 Thread pool 을 활용하여 이러한 오버헤드를 방지 합니다.

AsyncConfig

@EnableAsync
@Configuration
public class AsyncConfig implements AsyncConfigurer {

	@Override
	public Executor getAsyncExecutor() {
		ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
		executor.setCorePoolSize(5);
		executor.setMaxPoolSize(10);
		executor.setQueueCapacity(50);
		executor.setThreadNamePrefix("Async-");
		executor.setWaitForTasksToCompleteOnShutdown(true);
		executor.setAwaitTerminationSeconds(60);
		executor.initialize();
		return executor;
	}
}

다음으로는, 이벤트를 처리할 수 있도록 EnventListener 를 등록하고, 이벤트를 생성해주겠습니다.

EmbeddingCreatePostEvent

public record EmbeddingCreatePostEvent(PostEntity post, List<TagEntity> tagList) {
}

EmbeddingEventListener

@Slf4j
@Component
@RequiredArgsConstructor
public class EmbeddingEventListener {

	private final EmbeddingService embeddingService;

	@Async
	@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
	public void handleEmbeddingNewPostEvent(EmbeddingCreatePostEvent event) {
		embeddingService.createEmbeddingPost(event.post(), event.tagList());
	}
}

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 을 통해, 게시글이 실제 저장되어 commit 된 후, 이벤트가 동작 되도록 구성하였습니다.

이제 이 이벤트를, 게시글이 작성될 때, 발행하도록 추가해주겠습니다.

여기부터는, 제 블로그의 원본 코드 입니다.
Github 에 들어가 코드를 살펴 보셔도 되지만, 그냥 게시글을 작성하는 End-point 와 연결된 서비스 로직이라고 짐작 하시면 됩니다.

PostService

@Slf4j
@Service
@RequiredArgsConstructor
public class PostService {

	// 기존 가져올 bean 목록들...    
	private final ApplicationEventPublisher eventPublisher; // spring event 발행을 위한 publisher

    @Transactional
	public PostResponse.CreatePostResponse create(PostRequest.CreatePost request) {
		// 1 ~ 7. request 를 받아, 블로그 post 를 생성하는 로직
		// 현재 글에서는 필요하지 않아 제외되었습니다!

		// 8. post embedding event 발행
		eventPublisher.publishEvent(new EmbeddingCreatePostEvent(newPost, findTagEntityList)); // 이벤트 발행!

		// 9. 응답 생성. 리다이렉션용 slug 주소
		return PostResponse.CreatePostResponse.from(generatedSlug);
	}
}

임베딩 확인

새로운 글을 등록해, 임베딩 되는 것을 확인 해 보겠습니다.

Kibana 를 활용하여 확인하겠습니다.

Kibana 를 통한 Dataview를 생성하고, 대시보드를 생성하는 것이 생소하다면?
Elastic Search] ELK 로 로그 관리하기-Spring 실행 후, 로그 전송 확인 부터 보시면 됩니다.

본문의 내용이 Vecotr 화 되어 잘 저장되어 있고, 각각의 DOcuments 들이 Meta 데이터를 가지고 있다면 성공 입니다!

다음으로

다음으로는 사용자의 요청에 맞춰서 관련 있는 문서를 조회하는 Retrieval 작업을 완료하도록 하겠습니다.

회고

생각보다 흐름이 많이 기네요...

줄여서 써봐야 할 것 같은데 정말 어렵네요...

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

스택 시리즈LLM & RAG with Langchain4J