벡터 DB 만들어 보기

https://wikidocs.net/262584

벡터 데이터베이스 정의

벡터 데이터베이스는 데이터 객체의 수치적 표현인 벡터(벡터 임베딩이라고도 함) 형태로 정보를 저장하는 데이터베이스입니다. 이러한 벡터 임베딩의 성능을 활용하여 이미지, 텍스트, 센서 데이터 등의 비정형 데이터 및 반정형 데이터로 구성된 대규모 데이터 세트를 색인하고 검색합니다. 벡터 데이터베이스는 벡터 임베딩을 관리하기 위해 구축되었으므로 비정형 및 반정형 데이터 관리를 위한 완벽한 솔루션을 제공합니다.

벡터 데이터베이스는 벡터 검색 라이브러리 또는 벡터 인덱스와 다릅니다. 이는 메타데이터 저장 및 필터링을 가능하게 하고, 확장 가능하며, 동적 데이터 변경을 허용하고, 백업을 수행하고, 보안 기능을 제공하는 데이터 관리 솔루션입니다.

벡터 데이터베이스는 고차원 벡터를 통해 데이터를 구성합니다. 고차원 벡터에는 수백 개의 차원이 포함되어 있으며 각 차원은 그것이 나타내는 데이터 객체의 특정 기능이나 속성에 해당합니다.

벡터 임베딩이란 무엇인가요?

벡터 임베딩은 주제, 단어, 이미지 또는 기타 데이터를 숫자로 표현한 것입니다. 임베딩이라고도 하는 벡터 임베딩은 대규모 언어 모델 및 기타 AI 모델에 의해 생성됩니다.

각 벡터 임베딩 사이의 거리는 벡터 데이터베이스 또는 벡터 검색 엔진이 벡터 간의 유사성을 결정할 수 있게 해줍니다. 거리는 데이터 객체의 여러 차원을 나타낼 수 있으므로,머신 러닝 및 AI가 패턴, 관계 및 기본 구조를 이해할 수 있습니다.

DB-Engines Ranking of Vector DBMS 

https://db-engines.com/en/ranking/vector+dbms

데이터 저장 및 읽기까지 9단계 과정 필요

통상 벡터 DB에 데이터를 저장하고 이를 읽어오기까지는 9단계 과정이 필요하다. 기업이 자체적으로 작성한 신입사원 백서 파일을 벡터 DB에 저장하고 신입사원이 기업 전용 생성형 AI 챗봇에 질의하고 받기까지 과정을 예로 들어 보자. 먼저 구축된 벡터 DB에 덩어리(청크, Chunk) 형태로 백서 파일을 변환해야 한다. 청크는 의미 있는 단위로 나누는 것을 의미한다. 이후 청크 형태로 바뀐 신입사원 백서 데이터를 임베딩 모델에 넣어 벡터화한다. 이렇게 벡터화된 신입사원 백서 데이터를 벡터 DB에 넣기 전 인덱싱(Indexing)을 통해 정렬하고 벡터 DB에 저장한다. 여기까지가 신입사원 백서 파일을 벡터화하고 벡터 DB에 저장하는 과정으로 볼 수 있다. 이때 사내 규정 및 거버넌스가 바뀌면서 백서가 수정될 경우 벡터 DB에 실시간으로 반영할 수 있어야 한다.


벡터 DB와 지식그래프 비교 (출처: medium.aiplanet.com)
이후 신입사원이 기업용 생성형 AI 챗봇에 입사 첫해 여름휴가를 최대 며칠까지 사용할 수 있는지 질의한다면, LLM과 연동된 랭체인을 통해 쿼리를 임베딩 모델에 넣어 벡터화한다. 이후 벡터화된 질의문을 벡터 DB 내 인덱스에서 유사 벡터 군집(휴가에 대한 정보들) 및 벡터 데이터(입사 첫해 여름휴가 정보)를 찾고 이를 다시 LLM에 보내 사용자가 이해할 수 있는 답변으로 치환해 보여주는 방식이다. 이러한 과정은 타 DB와 별다른 차이점이 없다.
 

다음은 벡터 DB를 생성하는 코드입니다.

# build_vector_db.py
from langchain_community.document_loaders.csv_loader import CSVLoader
from langchain_community.vectorstores import Chroma
from langchain_upstage import UpstageEmbeddings

loader = CSVLoader(
    file_path="./csv/한국산업은행_금융 관련 용어_20151231.csv", encoding="cp949"
)
pages = loader.load()
print(pages[:2])

us_model =  UpstageEmbeddings(
    api_key="up_ULzGbJVs57bcnNHm8D0KdI51Nzl4F",
    model="solar-embedding-1-large"
)

Chroma.from_documents(pages, us_model, persist_directory="./database")

코드 블록별로 설명하면 아래과 같습니다.

• CSV 파일 로드

실습에 사용되는 파일을 로드합니다. CSVLoader 객체를 사용하여 CSV 파일을 로드하고, 반환된 Document 정보를 pages 변수에 저장합니다. 다음 코드는 CSV 파일을 출력하고 샘플 데이터를 출력하는 내용입니다.

loader = CSVLoader(file_path="./csv/한국산업은행_금융 관련 용어_20151231.csv", encoding='cp949')
pages = loader.load()

print(pages[:2])

[Document(metadata={'source': './csv/한국산업은행_금융 관련 용어_20151231.csv', 'row': 0}, page_content='구분: 리스크\n분류: 리스크 개요\n용어: 리스크(Risk)\n설명: 미래수익 또는 자산가치 변동
의 불확실성(Uncertainty)으로 인하여 보유자산에서 손실이 발생할 가능성(신용  시장  금리  유동성리스크 등) 또한 부적절하거나 잘못된 내부절차  시스템 오류  직원의 실수·고의 또는 자연재해 등의 사 건에 의해 손실이 발생할 가능성 (운영리스크 등)'), Document(metadata={'source': './csv/한국산업은행_금융 관련 용어_20151231.csv', 'row': 1}, page_content='구분: 리스크\n분류: 리스크 개요\n용어: 불확실성\n설명: 설사 손실이 발생한다 해도 발생될 것이 확실하고 크기(금액)도 확실히 알 수 있어서 회피 또는 수용하기로 의사결정하고 나면 그것은 더 이상 리스크가 아님')]

• 임베딩 모델 로딩

업스테이지 랭체인 인터페이스를 사용해서 solar-embedding-1-large 모델을 로딩합니다.

us_model = UpstageEmbeddings(
    api_key="발급받은 키",
    model="solar-embedding-1-large"
)

• 벡터 DB 생성

Chroma.from_documents 메서드를 호출해서 로딩한 문서를 임베딩 모델을 통해 임베딩 벡터로 변환하고 이것을 최종적으로 로컬 디렉터리에 저장합니다.

Chroma.from_documents(pages, us_model, persist_directory="./database")

이 명령이 실행되고 나면 임베딩 벡터 외에도 원문 정보, 인덱스, 메타 데이터 등의 각종 정보를 바탕으로 로컬 디렉터리에 데이터베이스가 구성됩니다. 다음은 로컬에 생성된 데이터베이스를 캡처한 자료입니다.

**"Hallucination" (환각)** 할루시네이션 은  인공지능, 특히 대규모 언어 모델(Large Language Model, LLM)과 같은 생성형 AI 분야에서 사용되는 중요한 용어입니다.

Hallucination은 LLM이 사실과 다르거나, 논리적으로 불가능하거나, 학습 데이터에 존재하지 않는 정보를 마치 사실인 것처럼 자신 있게 생성하는 현상을 의미합니다. 쉽게 말해, AI가 '없는 것을 지어내는 것' 또는 **'거짓말을 하는 것'**과 같습니다.

왜 Hallucination이 발생할까요?

LLM은 방대한 양의 텍스트 데이터를 학습하여 단어와 문장 사이의 통계적 패턴과 관계를 배웁니다. 이를 통해 다음 올 단어를 예측하고 문장을 생성합니다. Hallucination이 발생하는 주요 이유는 다음과 같습니다.

1. 패턴 학습의 한계:
   • LLM은 '세상에 대한 이해'를 하는 것이 아니라, '단어 시퀀스의 통계적 패턴'을 학습합니다. 따라서 특정 질문에 대해 학습 데이터에서 유사한 패턴을 찾지 못하거나, 불완전한 패턴을 발견했을 때, 가장 그럴듯한(통계적으로 유사한) 단어 시퀀스를 조합하여 생성하게 됩니다. 이 과정에서 사실과 동떨어진 내용이 나올 수 있습니다.
2. 데이터 부족 또는 편향:
   • 특정 주제에 대한 학습 데이터가 부족하거나, 데이터 자체가 편향되어 있다면, 모델은 부정확하거나 존재하지 않는 정보를 생성할 가능성이 높아집니다.
3. 최신 정보 부족:
   • LLM은 학습 데이터가 업데이트된 시점 이후의 최신 정보를 알지 못합니다. 따라서 최신 사건이나 사실에 대해 질문을 받으면, 과거 데이터를 기반으로 그럴듯하지만 틀린 답변을 생성할 수 있습니다.
4. 불분명하거나 모호한 프롬프트:
   • 사용자의 질문(프롬프트)이 너무 추상적이거나 모호할 경우, LLM은 질문의 의도를 정확히 파악하기 어렵고, 이로 인해 잘못된 방향으로 정보를 생성할 수 있습니다.
5. 과도한 일반화:
   • 모델이 학습 과정에서 본 일부 패턴을 과도하게 일반화하여, 실제로는 적용되지 않는 상황에 잘못된 정보를 생성할 수 있습니다.

Hallucination의 문제점

• 신뢰성 저하: AI가 사실과 다른 정보를 생성하면 사용자는 AI의 답변을 신뢰하기 어렵게 됩니다.
• 잘못된 의사결정: AI의 잘못된 정보를 기반으로 중요한 결정을 내릴 경우 심각한 결과를 초래할 수 있습니다.
• 확인 노력 증가: 사용자는 AI가 생성한 모든 정보를 일일이 사실인지 확인해야 하는 추가적인 부담을 안게 됩니다.

Hallucination을 줄이는 방법

Hallucination을 완전히 없애는 것은 현재 LLM 기술의 큰 과제이지만, 다음과 같은 방법들로 그 발생 빈도와 심각도를 줄일 수 있습니다.

• RAG (Retrieval-Augmented Generation): 외부의 신뢰할 수 있는 최신 정보를 검색하여 LLM에 제공함으로써 LLM이 '참조할 자료'를 기반으로 답변을 생성하게 합니다. (위에서 설명한 내용입니다!)
• 정확한 프롬프트 엔지니어링: 질문을 명확하고 구체적으로 작성하여 LLM이 정확한 의도를 파악하도록 돕습니다.
• 모델 재학습(Fine-tuning) 및 업데이트: LLM을 최신 데이터로 주기적으로 재학습시키거나, 특정 도메인에 특화된 데이터로 파인튜닝하여 해당 분야의 정확도를 높입니다.
• 불확실성 표시: LLM이 자신이 생성한 정보에 대해 얼마나 확신하는지를 사용자에게 알려주어, 불확실한 정보는 사용자가 한 번 더 확인할 수 있도록 유도합니다.
• 인간 개입 및 검증: 중요한 의사결정이나 민감한 정보의 경우, AI의 답변을 사람이 최종적으로 검증하고 수정하는 단계를 거칩니다.

Hallucination은 LLM을 실생활에 적용할 때 가장 주의해야 할 부분 중 하나이며, RAG와 같은 기술의 발전으로 그 영향력을 줄이려는 노력이 계속되고 있습니다.

CxO 또는 기술 전략 담당자라면 지난 몇 달 동안 AI에 대한 태도가 변화했을 가능성이 크다. 거대 기업의 생성형 AI 서비스가 헤밍웨이와 같은 이메일/문자 품질을 만들어줄 것이라고 기대하지 않으며, 이러한 서비스가 전반적인 수익과 주가를 높여줄 것이라고 기대하지도 않는다. GPU 칩도 일개 하드웨어로 무심히 바라보게 됐을 것이다. 그렇다고 해서 AI를 포기했다는 의미는 아니다. 현실을 직시했다는 뜻이다. 그렇다면 실제 행동 측면에서 현실의 기업들은 어떤 모습일까? '현실의' AI란 무엇일까?

일단은 점점 더 사내에서 실행하는 애플리케이션을 향해가고 있다. AI 계획을 공유한 292개 기업 중에서 164개 기업은 자체 호스팅 AI를 통해서 진정한 AI 혜택이을 얻을 수 있을 것으로 예상했다. 또 105개 기업만이 AI에 대해 잘 알고 있다고 답했고, 47개 기업은 확신을 가지고 있다고 답했다. 전반적으로 사내 AI(in-house AI)가 초기 단계에 있다고 말하는 것은 정확한 표현이다. 기업 내 AI 배포에는 많은 영역이 있으며 대부분이 아직 혼란스럽기 때문이다.

이러한 어려움에도 불구하고 벤더들은 셀프 호스팅 옵션을 내세우는 듯하다. 시스코와 주니퍼( HPE의 인수가 순조롭게 진행되고 있음)는 모두 엔터프라이즈 데이터센터에서의 AI에 더 집중하겠다는 의사를 밝혔다. AI 모델 제공업체들도 생성형 AI 도구의 라이선스를 강조한다. 두 그룹 모두 기업들의 구매를 고대하고 있지만, 앞서 언급한 혼란으로 인해 기업 대부분은 어떻게 시작해야 할지조차 모른다.

전반적으로 기업들은 AI 호스팅 계획의 시작으로 GPU와 데이터센터 장비를 생각하곤 한다. 그러나 응답을 분석한 결과 앞선 기업들은 그렇지 않다고 말하고 있었다. “애플리케이션 요구 사항에 대한 예상에 맞춰 하드웨어를 구매하면 안 된다. AI가 수행하기를 원하는 작업부터 시작한 다음 어떤 AI 소프트웨어가 필요한지 물어봐야 한다. 그런 다음 데이터센터 계획을 시작할 수 있다”라고 한 CIO는 말했다.
 

LLM과 SLM 비교
자체 AI 호스팅 경험을 가진 기업 다수는 챗GPT로 시작했다고 전한다. 퍼블릭 AI 서비스 중 하나에서 사용되는 대규모 언어 모델(LLM)의 프라이빗 버전을 호스팅해야 한다고 가정하는 것이다. 기업 3분의 1은 이러한 경로를 밟고 있었다. 그러나 3분의 2는 자체 호스팅하는 AI가 '오픈소스' 모델을 기반으로 해야 한다고 생각하고 있었다. 또 이들 중 대부분은 이제 특정 미션에 '전문화'된 AI 모델을 찾고자 한다고 응답했다. 

오늘날 사내 구현 형태로 제안될 가능성이 가장 큰 AI 프로젝트는 AI 챗봇이었다. 비즈니스 사례로서의 성공 가능성도 크다고 할 수 있다. 이러한 프로젝트는 대개 사전 판매 및 판매 후 미션, 즉 마케팅/영업 및 고객 지원을 목표로 한다. 이러한 애플리케이션을 우선적으로 고려하는 기업은 퍼블릭 AI 서비스나 클라우드 호스팅을 고려할 가능성이 높았다. 즉 독점 모델을 유지하는 기업들인 1/3의 대부분을 차지하고 있었다.

비즈니스 사례를 만들 가능성이 다음으로 높은 AI 애플리케이션 분야는 비즈니스 분석 및 인텔리전스다. 대부분의 기업이 AI를 자체 호스팅해야 한다고 처음부터 생각하는 분야이기도 하다. IBM 고객들은 이 분야에서 IBM의 왓슨X 전략을 이용하는 경향이 있으며, 모든 기업 중에서 모델 선택 방식에 가장 큰 자신감을 보이고 있었다. 다른 기업들 사이에서는 메타의 라마가 블룸과 팔콘 모델을 제치고 가장 선호하는 전략이 됐다. 하지만 이러한 변화는 상당히 최근에 나타났기 때문에 계획 측면에서는 앞서 있지만 구축은 뒤처져 있었다.

한편 고객 대면 업무의 챗봇 사용자, 의료 업계 종사자, 심지어 비즈니스 분석 분야에서 AI를 계획하는 많은 기업들이 소규모 언어 모델(SLM)에 점점 더 많은 관심을 보이고 있다. SLM은 특정 임무에 맞게 학습된다. 덕분에 환각의 위험을 획기적으로 줄이고 전문 영역에서 더 유용한 결과를 생성할 수 있다. 몇몇 SLM은 기본적으로 특수 임무에 맞게 조정된 LLM이기에 적당한 LLM을 선택하면 SLM 선택이 끝난다. AI 전략에 대해 신뢰할 수 있는 공급업체가 있다면 해당 공급업체와 미션별 SLM에 대해 논의하는 것이 현명한 수순이다. 전문 SLM을 사용해 본 기업(총 14개)은 SLM이 현명한 선택이었으며 호스팅 비용을 크게 절감할 수 있다는 데 동의했다.

GPU 및 이더넷 네트워크
하드웨어는 어떨까? 엔비디아 GPU를 떠올리기 쉽지만 기업들이 실제 구매하는 기기는 GPU가 포함된 서버다. 델이나 HPE, 슈퍼마이크로와 같은 벤더들이 기업의 GPU 정책에 영향을 끼친다. 기업들은 AI 호스팅을 위해 약 50개에서 거의 600개까지 다양한 수의 GPU를 보유하고 있었으며, 100개 미만의 GPU를 보유한 기업의 3분의 2가 초기 테스트 중에 추가했다고 보고했다. 500개 이상을 보유한 기업 중 일부는 현재 너무 많다고 생각하고 있었다. 대부분의 엔터프라이즈 셀프 호스팅 계획자는 200~400개 사이를 배포할 것으로 예상했으며, 450개 이상을 사용할 것이라고 답한 기업은 단 두 곳에 그쳤다.

GPU를 직접 설치하려는 기업은 거의 없었다. 즉 표준 서버용 GPU 보드를 구매하려는 경우는 드물었다. 그저 끼운다고 끝이 아님을 잘 알고 있기 때문일 터다. 좋은 GPU에는 빠른 메모리, 빠른 버스 아키텍처, 빠른 I/O 및 네트워크 어댑터가 필요하다.

한편 이더넷을 사용할지 인피니밴드를 사용할지에 대한 오래된 논란은 자체 호스팅 AI를 사용 중이거나 계획 중인 기업들에게 그리 고민거리가 아니었다. 이들은 이더넷이 정답이라는 데 동의하며, 가능한 한 빨라야 한다는 데도 동의했다. 우선순위 흐름 제어와 명시적 혼잡 알림 기능을 모두 갖춘 800G 이더넷은 기업에서 권장하고 있으며, 화이트박스 장치로도 제공되고 있다. 

기업들은 또 AI를 표준 서버와 혼용해서는 안 된다는 데 동의하고 있었다. AI 배포를 자체 고속 클러스터 네트워크를 갖춘 새로운 클러스터로 볼 수 있는 셈이다. 또한 학습이나 프롬프트 등 회사 데이터에 액세스하기 위해 데이터센터에 빠르게 연결하고 사용자 액세스를 위해 VPN에 연결하는 것이 중요하다.

여러 개의 AI 애플리케이션을 사용할 예정이라면 두 개 이상의 AI 클러스터가 필요할 수 있다. 필요에 따라 SLM 또는 LLM을 클러스터에 로드할 수는 있지만, 데이터를 보호하면서 동일한 클러스터에서 여러 모델을 동시에 실행하는 작업은 더 복잡하다. 

일부 기업에서는 하나의 LLM 도구를 선택하여 고객 지원, 재무 분석 및 기타 애플리케이션에 맞게 학습시킨 다음 다른 애플리케이션에 병렬로 사용할 수 있다고 생각하고 있었다. 문제는 응답을 격리하는 것이 어렵다는 점이다. 모델 내에서 미션을 혼합하는 것은 현명하지 않을 가능성이 크다.

그렇다면 최종 권장 사항은 무엇일까? 테스트... 테스트… .테스트다. 시간을 들여 모델 옵션을 평가해야 한다. 시간을 들여 구성을 선택하고, 특히 커밋하기 전에 AI를 시험해 볼 수 있을 때 가능한 한 자주 테스트하라. AI 전략을 수립한 후에는 제품, 비즈니스, 운영 중인 세금 및 규제 프레임워크의 변화에 따라 모델을 최신 상태로 유지할 수 있도록 계속 테스트하라. AI는 인간과 마찬가지로 상황이 변화함에 따라 재교육을 필요로 한다 그리고 인간 또한 AI에 대한 새로운 시각을 지속적으로 업데이트해야 한다. 

https://www.ciokorea.com/news/349969