RAG 시스템 구축을 위한 랭체인 가이드

RAG

• 검색 - 증강 - 생성 3단계에 걸쳐 LLM이 사실에 근거하여 답변하도록 도움

• Retrieval
• 어떻게 사용자 질문에 올바른 정보를 찾아오는가?
1. 사용자의 질문을 임베딩으로 변환 (BERT, 파생모델 사용)
2. 참고할 문서들을 동일한 방식을 통해 행렬값으로 변환 (벡터 DB)
3. 벡터DB에서 사용자 질문 임베딩과 유사한 임베딩 추출하여 해당 임베딩 문장을 추출
• 벡터 DB구축시 우리가 가진 문서가 임베딩 모델의 최대 입력 길이를 벗어나는 경우 문서를 분할하는 과정을 거쳐야함. Chuncking.
• 질문 임베딩과 벡터 DB내 임베딩 값을 비교하여 가장 유사한 임베딩 값을 찾아낸다고 가정시, 사용자 질문에 답변할 수 있는 맥락이 충분히 담기지 않을 수 있음 → 문서 분할하여 임베딩 값으로 변환하는 과정에서 어떤 방식으로 분할할지, 어떤 구조로 문서를 분할하여 저장할지 고민해야함

• Augment
• Langsmith에서 제공하는 RAG프롬프트

당신은 질문-답변 작업을 위한 어시스턴트입니다. 
다음의 검색된 문맥을 사용하여 질문에 답변하세요. 
만약 답을 모른다면, 모른다고 말하세요.
<</SYS>>

#Context:
{검색된 문맥}

#Question:
{사용자 질문}

• Generation

RAG vs Fine-tuning

• RAG는 모델의 성능이 고정되어 있어서, 모델외의 모듈을 최적화하며 성능을 올려야함. 파인튜닝은 LLM을 특정 도메인 데이터셋으로 특화하여 재학습시켜 답변 품질이 향상됨.

• PoC를 구축하여 서비스 결합 가능성을 검토한다면 RAG가 비용, 시간 측면에서 유리함. 지식 업데이트가 잦은 경우에도 유리.

Langchain

• 랭체인은 LLM 앱 구축을 위한 프레임워크

• 사용자의 프롬프트를 바로 LLM에게 전달하는게 아니라 하나의 프롬프트 템플릿을 거쳐 추가적인 연결고리를 만들어서 원하는 답변을 이끌어냄

• 모듈 종류
• Models : 여러 LLM을 어플리케이션에 통합
• Prompts : 사용자의 프롬프트를 재가공
• Document Loaders : 벡터DB로 구축할 문서를 불러옴
• Text Splitters : 청크로 분류
• Vector Stores : 분할된 텍스트 청크들을 저장
• Output Parsers : 원하는 답변 형태로 재가공

• ChatPDF 로직
• 문서 업로드 → 문서 분할 → 문서 임베딩(LLM이 이용할 수 있도록 문서 수치화) → 임베딩 검색(질문 연관성 높은 문서 추출) → 답변 생성

• streaming : LLM은 답변을 한 단어씩 생성해서 모델의 작동 과정을 실시간으로 화면ㄴ에 표시해줌. 사용자 경험 향상에 좋음. 랭체인 stream()함수 실행

• 응답 캐싱 : 답변 속도 향상을 위해 이전에 응답을 캐싱해둠.

• output parser : llm의 답변을 원하는 형태로 조정 ; csv파서, datetime파서, json파서

• Document 객체 : 어떠한 형식의 문서를 불러오더라도 하나의 통일된 양식으로 통합해서 RAG에 활용할 수 있도록 함. page_content(문서 내용), metadata(문서 위치, 제목, 페이지 번호)라는 key-value 딕셔너리 형태를 지님
• RAG시스템의 목적은 LLM이 명확한 근거가 있는 답변을 생성한다는 점. 따라서 Document 메타데이터가 이러한 RAG강점에 기여함.
• 메타데이터는 정보 검색 필터링의 기준이 됨. ex업무 규정 중 당직 규정을 알려줘라는 명령이 오면, 업무규정 pdf파일만 참고해서 당직 규정을 설명함

• PDF Loader : PDF에서 텍스트 추출, 테이블 정보도 추출 가능, OCR기능은 아직 미흡

• 다양한 파일 형태 불러오기 : Docx2txtLoader(Word파일 불러오기), WebBaseLoader(인터넷 정보 로드하기), DirectoryLoader(특정 경로 내 모든 파일 불러오기)

VectorDB

• RAG시스템에서 문서를 불러온 후 해야하는 것은 벡터DB 저장. 사용자 질문과 비교하여 유사 문장 검색할 준비가 됨. 근데 문서가 긴 경우 한번에 벡터 DB 변환은 지양해야함.

• Why
• 임베딩 모델의 컨텍스트 윈도우 문제 : 임베딩 모델도 LLM처럼 길이 제한 문제가 있음.
• LLM의 컨텍스트 윈도우 문제 : 사용자 질문에 답할 수 있는 근거 문서는 여러 문서에 산재할 가능성 높음. 사용자 질문과 유사 문서 합친 텍스트 토큰 수는 특정 토큰 수 이상이 되면 안됨.
• 건초더미에서 바늘찾기 : LLM이 주어진 컨텍스트 정보 처리에 있어서 앞부분 다소 망각함. 최대한 사용자 질문과 유사한 텍스트를 짧고 알차게 LLM에 전달해야함.

• Text Splitter : Document를 특정 기준에 따라 정해진 길이의 청크로 분할함. 사용자 질문과 벡터 DB내 모든 청크간의 유사도를 계산해서 유사도가 높은 N개의 청크를 검색하게 됨.

• 임베딩은 텍스트를 수치로 변환하는 작업

• 텍스트를 수치로 바꾸려면 대량의 텍스트로 사전학습된 모델을 활용함 (ex BERT)

• 임베딩이 키워드 검색보다 나은 이유 :

• 벡터 DB와 RDB와의 차이 : 벡터DB는 비정형 데이터를 저장하는데 특화된 DB, 벡터 DB는 조회방식이 다름. 텍스트나 이미지 검색시 정확히 일치하는게 안리ㅏ 비슷한 것을 찾고자 함. ANN알고리즘 바탕으로 임베딩 벡터간 유사도를 계산해서 검색에 활용

• 벡터 DB 종류 : 순수 벡터 데이터베이스 (ex. Pinecone, Chroma,..) / 텍스트 전용 데이터베이스 (ex Elasticsearch, OpenSearch..) → 벡터 검색을 위한 추가 모듈 결합 필요 / 벡터 라이브러리 (ex FAISS, Annoy) → 벡터 유사도 계산이나 클러스터링을 위한 라이브러리

• Chroma DB : RAG구축시 가장 많이 쓰는 오픈 소스 벡터 DB

Retriever(문서 검색기)

• 사용자 질문과 근거 문서를 어떻게 잘 연결할 것인가

• 사용자의 질문을 어떻게 해석할까

• 답변 근거가 될 문서는 얼마나 어떻게 가져올 것인가

• MultiQueryRetriever(사용자 질문 재가공하여 검색 품질 향상) : 사용자의 질문을 여러 버전으로 만들어 벡터 DB 내 검색이 원활하도록 함. LLM이 사용자 질문의 목적을 다각도로 해석하여 여러 버전의 질문 문장을 만들어냄. 그리고 이를 유사청크로 검색.

• MultiVectorRetriever(문서의 벡터를 재가공해서 검색 품질 향상) : 상위 문서 검색기는 청크를 나누는 기준을 2개로 정의. 사용자의 질문과 유사한 문서를 검색할 때, 짧은 길이의 하위 청크를 검색해서 더욱 정확하게 추출, LLM에게 컨텍스트를 전달할 때는 상위 청크를 전달하여 좀 더 완전한 맥락을 주입한 답변을 풍부하게 함.

Tool&Agent

• LLM은 주어진 문제해결을 위해 어떤 행동이 필요한지 생각, 필요한 행동 순서대로 수행, 다음으로 해야할 행동이 무엇인지 관찰

• Tool은 LLM이 문제해결을 위해 액션 플랜에 사용하는 외부 도구. 인터넷 검색, 외부 DB검색과 같은 작업 수행의 API활용 (ex Tavily AI)