openai의 gpt와 같은 llm은 기업이나 개인 내부(기밀) 데이터를 사용할 수 없다는 태생적 한계가 있다.

기업들은 문서들이나 관계형 데이터베이스에 외부에 노출하고 싶어하지 않는 데이터를 가지고 있다. 기업들은 이미 기업 자체 앱이 있고, 이 앱에 ai 기능을 추가하고 싶어한다. 그렇다고 돈이 많이 들어가는 llm을 만들고자 하지는 않는다. 노출하지 않으면서 뛰어난 llm에 연동해서 자신들의 앱을 업그레이드 하고 싶어한다.

시간이 지날 수록 나아지겠지만, 지금은 관계형 데이터베이스 보다는 자연어 검색을 지원하는 벡터 데이터베이스를 사용하는 게 유리하다. 어떻게 벡터 데이터베이스가 자연어를 사용해 쿼리에 응답하는지, 아래 문장을 읽고 대략 감을 잡아본다.

It would be nice if we could use an entire 10,000-page operating manual as context for our prompt, but because of the token limit constraint, that is impossible. Therefore, embeddings are useful for breaking down that large text into smaller pieces. We can do this by summarizing each page into a shorter paragraph and then generating an embedding vector for each summary. An embedding vector is like a compressed representation of the text that preserves its meaning and context. Then we can compare the embedding vectors of our summaries with the embedding vector of our prompt and select the most similar ones. We can then add those summaries to our input text as context for our prompt. This way, we can use embeddings to help us choose and fit large texts as context within the token limit of the model.

시맨틱 커널은 ai 애플리케이션에 기억(memory)이란 개념을 사용한다. 채팅 중에 이전 대화 내용을 기억해야 한다. 채팅 중에만 기억하면 되는 내용은 그 때만 기억하면 된다. 단기 기억이다. 장기 기억해야 할 것은 파일이나 데이터베이스에 저장하고 필요할 때 사용할 수 있어야 한다.

ai 애플리케이션은 llm 훈련에 사용하지 않은 데이터를 기억해야 한다. llm은 자연어를 사용하는데 컴퓨터는 자연어 다루기를 어려워한다. 숫자 형태를 좋아하기 때문에 llm은 자연어를 다차원의 숫자 형태인 벡터로 바꾼다. 이러한 과정을 임베딩(embedding) 한다고 한다. 임베딩은 단어, 문장, 단락, 문서와 같은 토큰을 고차원 벡터 공간에 표현하거나 인코딩하는 것이다. 각 차원은 언어의 학습된 특징 또는 속성에 해당한다. 쉽게 토큰에 대한 벡터를 만든다라고 생각할 수 있다.

왜 임베딩을 할까? 모델이, 즉 컴퓨터가 언어의 의미와 관계를 잘 처리할 수 있도록 하는 방식이라는 것.

데이터가 있으면 이를 관리하고 조회할 수 있는 기능이 특화되어 데이터베이스가 등장한다. 벡터가 등장했으니 벡터 데이터베이스도 등장한다. 벡터 데이터베이스는 벡터를 저장하고 인덱싱 해서 자연어 쿼리에 잘 답할 수 있도록 해준다. 벡터 데이터베이스에 쿼리 해 받은 응답은 보통 프롬프트의 context 부분으로 포함되어 llm에 전달된다. 벡터 데이터베이스는 llm의 한계를 보강하는 것으로 ai 애플리케이션 개발자라면 높은 관심을 가져야 할 부분이다. 벡터 데이터베이스로 파인콘이 유명하다.

시맨틱 커널 문서에서는 다음과 같은 벡터 데이터베이스들도 언급하고 있다. ms에 의해 개발이 주도 되고 있으니 애저 관련 언급은 당연하고, 크로마는 랭체인 사용 애플리케이션에서 자주 사용하는 걸 봤고, Qdrant는 시맨틱 커널을 사용하는 애플리케이션에서 봤다. 개인적인 성향은 1등하는 하는 쪽이고, 아는 한에서 1등은 파인콘이니 당연 파인콘 사용을 권한다.

– Azure Cognitive Search, Azure PostgreSQL Server

– Chroma

– DuckDB, Milvus, Postgres

– Qdrant – 오픈소스, 로컬 환경에 가볍게 설치 가능

– Redis, Sqlite, Weaviate

[설계 결정]

1. 벡터 데이터베이스를 사용하는 것도 외부에 있는 걸 사용하는 거니, 커넥터가 있어야 한다.

Pinecone만 지원하도록 한다. Pinecone 커넥터를 사용하는 네이티브 함수가 필요하다. PineconeSkill

2. Pinecone은 클라우드 벡터 데이터베이스 서비스로 구글, Azure, AWS를 지원한다. 파인콘 지원을 우선으로 하고, 향후 in-memory 버전으로 크로마(Chroma)를 지원하도록 한다.

[ 기밀 데이터 문제 ]

LLM은 태생적 한계로 훈련 시점 이후 데이터에 대해 모르고, 훈련 데이터로 쓰지 않은 기밀 데이터에 대해 모른다. 훈련 시점 이후 데이터는 검색이나 기밀이 아닌 내부 데이터를 제공할 수 있는 방법을 통해 해결 가능하지만, 기밀 데이터 문제는 해결되지 않는다. LLM 벤더가 AI 서비스 사용을 위한 데이터를 사용하지 않는다고 아무리 강조한 다고 해도 사용자는 불안하다.

이를 해결하려면,
기업 내부와 AI 서비스 사이에 주고 받는 데이터를 감시해야 하거나, 자체적으로 LLM을 가져야 한다.

오픈소스 LLM이나 sLLM이 등장하고 있기는 하지만, 아직 비용, 응답 성능이나 품질을 고려할 때 답이 되지 못한다.

생성형 AI 산업에서 해결하기로 덤벼볼 만한 문제는 “기밀 데이터를 LLM에 유출 위험 없이 사용하는 것“이 된다는 것. 앞으로 연구해 볼 분야다.

응답을 받으려면, LLM AI 서비스로 데이터가 넘어갈 수 밖에 없으니, 이쪽으로 문제 해결은 불가능에 가깝고. 결국 기업도 “기업 내부와 AI 서비스 사이에 주고 받는 데이터를 감시“하는 쪽을 선택할 것 같다. 이쪽 기술이 발전하겠네.