패스트캠퍼스 AI 개발자의 LLM 마스터 클래스(4)

embedding을 만든다 = 단어나 문장을 숫자 배열/리스트로 만든다

 

 

vector에서 검색하는 것은 기존 RDB의 PK 를 찾는 것이 아니라 vector 주변 값을 찾는 것

"키", "찾는 방법"을 임베딩으로 지정 -> Vector DB

Vector를 Key로 가진다

 

문서를 조각화하여 그 조각에서 키워드 또는 핵심 문장을 찾아 embedding 한다.

사용자 질문은 이런거이고, 유투브에서 데이터를 가져왔어. 이걸 가지고 답변을 해줘.

이 내부 로직들은 API에서 제공

 

--

Vector DB 종류

- pinecone, weaviate, QDrant, Milvus, Chroma 등의 전용 벡터 데이터베이스

- pinecone은 서비스로서의 소프트웨어로 성공적인 사례

- weaviate, QDrant, Milvus는 클라우드 서비스와 함께 오픈 소스로 쉽게 배포 가능

- Chroma는 SQLite와 유사해 작은 프로젝트에 적합

- FAISS (파이스)

 

기존에 있는 DB에 embedding으로 검색하고 싶은 경우 벡터인덱스 지원하는 제품을 사용할 수도 있다.

AMZ : Elasticsearch, Redis, Postgres 등이 벡터 인덱스 지원

MS : Cognitive Search

 

--

Pre-processing

문서를 로딩해서

Chunkig - 조각화하여

임베딩 계산 후 Vector index에 저장

 

Runtime

사용자 질문에서 임베딩 계산하여 벡터DB에 가서 유사도를 검색한다.

 

Meta Prompt -> 사용자 질문을 감싸는 프롬프트

ex) 

사용자 질문 : 만두나 김밥 먹을까?

Meta Prompt : 사용자가 원하는 품목 [만두] 종류 몇 개 예를 들면서 어떻게 맛있게 먹을 수 있는지 추천해줘

- vector db에서 만두와 유사한 상품과 예를 들어 상품정보등을 같이 프롬프트로 전달해줌

응답 : 오늘은 매콤한 사천 군만두 어떠세요? 김치 물만두는 오늘 세일이네요! 

 

---

 

Rangking , cutoff

검색의 문제

불필요한 내용이 검색될 수도 있고 검색 내용이 너무 많을 수도 있음 -> 토큰 수 늘어남, 결과 부정확함

가장 유용한 몇 개만 가지고와서 프롬프트 템플릿을 만들고 LLM에 보내기

 

사용자가 원하는 음식은 [만두 김치만두 김밥 떡볶이 엽기떡볶이 탕수육 ...] 이다

vs 

사용자가 원하는 음식은 [만두 김밥]이다.

 

---

 

벡터를 찾기 쉽게하기 위해서는 모여있어야 함

정해진 사이즈 청크

- 긴 글은 문장의 흐름이 있기 때문에 흐름에 맞게 정해진 사이즈만큼 문장을 나눠야 함.

-> 문장이 중간에 끊겨도 내용이 연결될 수 있게 청크가 조금씩 겹치게 만든다.

 

처리하는 문서가 늘 비슷한 포맷이라면 커스텀 청킹이 가능하지만 다른 포맷의 문서에는 적용하기가 어렵다.

 

청킹을 문장별로? 줄 수 대로? 페이지별로? 문단별로?

 

고정 크기 청킹 (보통 1024 토큰)

-> 구현 간단, 예측 가능

-> 중간에 끊어지면 의미 손실

 

동적 크기 청킹/semantic ( 데이터의 내용에 따라 블록의 크기가 달라지는 방법)

-> 유연하고 효율성 증가

-> 구현이 복잡함

 

정확도 vs 속도

작은 임베딩 : 정확한 임베딩, 그러나 처리하는데 훨씬 오래 걸림

- 한문장씩 임베딩 가능 그러나 찾을 때도 문장 하나하나 찾아야하기 때문에 속도가 오래 걸림

큰 임베딩 : 빠르지만 정확도가 낮음

 

---

 

Vector 인덱싱, 찾기 툴 문제

 

특히나 소설 같은 경우에는 컨텍스트 없이 이해하기 어려움.

비슷비슷한 유사도일때는 어떤 것을 선택해야할 것인가?

 이런 것들이 모두 토큰, 비용이 듬. 임베딩을 만드는 것도 비용

 

LlamaIndex (라마인덱스)

PDF, DB, API 에서 데이터를 받아서 청킹, 인덱스를 만들어 줌

 

Langchain tools - text splitters

-> 문장, 문단, HTML, code, markdown 등을 split 할 수 있음

-> userDefined ( custom character )

 

---

 

후처리 Post-processing

1. Relevance

2. moderation 내용 검열 ( 사용자 쿼리에도 적용)

- oepn api 에서 API 제공 ( moderations )

- 사용자 쿼리에서도 사용 가능 (pre-processing)

3. RAI(윤리적 AI)

4. groundedness 사실기반

5. correctness

6. cosine similarity

---

Moderation API - 이상한 질문은 미리미리 차단하자.

프롬프트에 제약사항을 모두 prompt에 넣기 전에 request 넣기 전에 질문을 검열하여 prompt의 토큰을 가볍게 만들자.

def get_moderation_results(text):
  response = client.moderations.create(input=text)
  output = response.results[0].to_dict()
  flagged = output["flagged"]
  rules_contravenced = []
  for key, value in output["categories"].items():
    if value == True:
      rules_contravenced.append(key)

 

https://platform.openai.com/docs/guides/moderation

 

Azure의 Moderation API 에서는 policy 도 존재

Gcp에서는 sapty_ratings로 제공

 

---

groundedness 

얼마나 사실에 기반했는지

Ragas (라가스) - python 라이브러리

https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/

 

생성

- Faithfulness 사실인가?

- Answer relevancy : 질문과의 관련성

검색

- Context precision : 가져온 정보의 signal to noise - 랭킹

- context recall : 가져온 정보로 충분한가

그 외

- Context relevancy : 필요한 정보만 있는가

- context entities recall : 가져온 정보중 몇 개를 썼는가

- Answer semantic similarity : 답변과 ground truth 유사도

=> metric 다양하게 넣고 테스트해보기

dataset.append(
        {
            "user_input":query,
            "retrieved_contexts":relevant_docs,
            "response":response,
            "reference":reference
        }
    )