대규모 언어 모델은 귀하의 개인 데이터에 대해 아무것도 모릅니다. 공개 인터넷에서 학습되었고, 귀사의 사내 위키에서는 학습되지 않았습니다. RAG, 즉 검색 증강 생성(Retrieval Augmented Generation)은 이를 해결합니다.00:00

아이디어는 간단합니다. 사용자가 질문을 하면, 우선 자체 문서에서 관련 정보를 검색합니다. 그런 다음, 검색된 맥락을 사용하여 사용자의 질문을 보완합니다.00:10

마지막으로, 입력하신 내용을 바탕으로 LLM이 답변을 생성하도록 합니다.00:21

검색, 증강, 생성, 그게 바로 이름의 유래입니다. 그리고 이 접근 방식의 아름다움은 모델을 다시 학습시킬 필요가 없다는 거예요.00:26

수백만 달러의 컴퓨팅 자원은 필요하지 않아요. 문서 검색하는 방법과 그 맥락을 LLM에 전달하는 방법만 있으면 돼요.00:35

간단하고 강력하며, 적어도 데모에서는 잘 작동하는 것 같아요.00:42

제가 흥미롭게 생각한 부분은 바로 이것입니다. 구글 연구팀에서 최근 발표한 연구에 따르면, 검색 결과가 부정확할 경우 LLM이 단순히 약간 잘못된 답변을 제공하는 것이 아니라 보입니다.00:46

사실 맥락을 전혀 주지 않았다면 오히려 더 환각 증세를 보입니다. 검색 기능이 부실하면 아예 검색을 하지 않는 것보다 더 심각한 문제가 될 수 있습니다.00:55

주피터 노트북 환경에서 잘 작동하는 랙 시스템과 실제 운영 환경에서 안정적으로 유지되는 랙 시스템의 차이점은 무엇일까요?01:03

오늘 저희가 탐구해 볼 내용은 바로 이것입니다. 프로덕션 환경에서 사용할 수 있는 랙 시스템의 전체 아키텍처를 단계별로 자세히 분석해 보려고 합니다. 문서 처리 방식부터 저장 방식, 그리고 사용자에게 답변을 전달하기 전에 내부적으로 답변을 검색하고 검증하는 과정까지 모든 부분을 살펴보겠습니다.01:09

혹시 이제 시작하시는 분이시든, 아니면 이미 몇몇 RAC 시스템을 구축하신 분이시든, 분명히 여기서 얻으실 만한 것이 있을 거라고 생각합니다. 자, 이제 시작해 볼까요?01:24

기본적인 RAC가 어떻게 작동하는지 빠르게 설명해 드릴게요. 사용자가 쿼리를 보내면, 그 쿼리는 임베딩으로 변환됩니다. 임베딩은 텍스트의 수치적 표현이라고 할 수 있어요. 그런 다음 벡터 데이터베이스에서 이 임베딩과 유사한 청크를 검색합니다.01:37

이것이 첫 번째 단계, 검색입니다. 검색을 하시면, 검색 결과로 돌아오는 조각들이 여러분의 맥락이 됩니다. 두 번째 단계는 인수입니다. 여러분은 그 맥락을 원본 질문과 결합하여 프롬프트를 만듭니다.01:52

마지막으로, 세 번째 단계는 생성입니다. 프롬프트를 LLM에 전달하고, 전달받은 컨텍스트를 바탕으로 답변을 생성합니다.02:03

검색, 인수, 생성입니다. 작년에 RAG 기본 사항에 대한 자세한 비디오를 만들었습니다.02:12

더 자세한 내용을 알고 싶으시면 설명에 링크를 넣어드릴게요. 하지만 지금은 이 간단한 흐름이 어디서 망가지는지 한번 살펴봅시다.02:17

음, 사용자가 '직원들을 위한 캘리포니아 주의 육아 휴직 정책이 어떻게 되나요?'라고 물어본다고 해 봐요. 그러면 시스템이 문서들을 검색해서 육아 휴직에 대한 내용과 캘리포니아 주에 대한 내용을 언급하는 부분을 찾아내겠죠.02:24

관련 있어 보이지만, 문제가 발생할 수도 있습니다. 예를 들어, 육아 휴직 관련 내용이 두 번이나 업데이트된 2019년 정책에서 가져온 것일 수도 있죠. 시스템은 그 차이를 알지 못합니다. 단지 단어가 일치했다는 것만 인지하는 거죠.02:37

혹시 문서가 자르면서 자격 요건이 문장 중간에 끊겼을 수도 있어요. 그래서 LLM이 필요한 정보의 절반만 받게 되거나, 원래 문서에 모든 주별 정책을 나열한 표가 있을 수도 있습니다.02:50

하지만 텍스트를 추출했을 때, 그 표는 더 이상 말이 안 되는 뒤섞인 단어들의 엉망진창이 되어버렸어요. 검색은 작동했어요. 관련성 있는 텍스트를 찾았죠. 하지만 LLM이 받은 맥락은 불완전하거나, 오래되었거나, 아니면 완전히 잘못된 것이었어요.03:03

그리고 제가 놀랐던 부분은 여기 있습니다. LLM이 컨텍스트가 부족하면, 모른다고 말할 거라고 생각했을 겁니다. 그런데 그런 일이 일어나지 않아요. LLM에게 컨텍스트를 제공하면, 컨텍스트가 나쁘더라도 더 확신을 갖게 됩니다.03:17

터무니없는 정보를 덧붙여서 그럴듯하게 만들어내죠.03:31

그러니까, 이제는 완전히 틀린 정보를 확신에 차서 말하는 시스템을 갖게 되는 겁니다. 그건 시스템이 전혀 모른다고 말하는 것보다 훨씬 더 심각한 문제예요.03:36

그리고 이것이 데모 RAG와 실제 서비스 RAG 사이의 차이점입니다. 데모에서는 문서가 깨끗하고 질문도 예측 가능하며 모든 것이 잘 작동합니다.03:42

실제 운영 환경에서는 데이터가 지저분해요. 표나 이미지, 머리말, 꼬리말, 같은 문서의 여러 버전들이 존재하죠. 사용자분들은... 모호하거나 야심찬 질문을 하시고, 그걸 처리해야만 해요.03:51

그럼 이걸 어떻게 해결해야 할까요? 제가 실제 프로덕션 래그 아키텍처가 어떻게 생겼는지 보여드리겠습니다.04:03

왼쪽에는 데이터 소스, 문서, 코드, 이미지, 스프레드시트 등, 조직 내부에 존재하는 모든 비정형 및 정형 데이터가 있습니다.04:09

기본적인 RAG에서는 그냥 이것을 청킹하고 임베딩하게 됩니다.04:19

하지만 여기에서 일어나는 것을 보세요. 먼저 데이터가 리스트럭처링 레이어를 거칩니다.04:22

이곳에서 원본 문서를 분석하고 구조를 이해하게 됩니다. 머리말은 무엇인가요? 단락은 무엇인가요? 표는 무엇인가요? 그런 다음 구조를 인식하는 청킹이 이루어집니다.04:28

500 토큰마다 무작정 나누는 대신, 문서의 자연스러운 경계를 존중하는 방식으로 덩어리를 만듭니다. 표는 그대로 유지되고, 제목은 해당 내용과 함께 유지됩니다. 그런 다음 메타데이터 생성이 이루어집니다.04:37

각각의 청크마다 요약본을 생성하고, 키워드를 추출하며, 심지어 해당 청크가 답변할 수 있는 가상 질문까지 만듭니다. 이 모든 정보가 데이터베이스에 흘러 들어갑니다.04:49

그리고 데이터베이스라고 명시되어 있다는 점을 주목하세요. 벡터 저장소만 있는 것이 아니라, 프로덕션 환경에서는 종종 임베딩과 관계형 데이터가 함께 작동해야 합니다. 이제 쿼리 측을 살펴보겠습니다.04:59

사용자가 질문을 하면, 바로 벡터 검색으로 이어지는 것이 아니라, 질문의 의도를 파악하고 적절한 도구를 실행하여 답변을 얻어내는 계획 기능과 추론 엔진을 거치게 됩니다.05:09

여러 에이전트들이 각자 문제의 다른 부분을 처리할 수 있는 다중 에이전트 시스템이 있습니다.05:21

그리고 그 아래로는 이런 인간 사고 검증 노드들이 있습니다. 게이트키퍼, 감사관, 전략가, 이들은 프로세스를 검증하고 사용자에게 반환되기 전에 문제를 발견합니다.05:26

오른쪽에는 평가 결과가 있습니다. 사용자가 긍정적으로 평가한 것뿐만 아니라, 실제 측정 지표도 확인하실 수 있습니다.05:38

LLM 심사관을 활용한 질적 평가, 정밀도와 재현율을 측정하는 양적 평가, 지연 시간 및 비용을 추적하는 성능 평가를 진행하고, 빨간색 섹션을 확인해 주십시오.05:45

왼쪽에 스트레스 테스트와 레드 팀, 편향된 의견, 정보 회피, 프롬프트 주입 등이 있습니다. 시스템이 어떻게 망가지는지 사용자가 알기 전에 알아야 합니다. 전체적인 그림입니다.05:55

이제 몇 가지 중요한 부분으로 좀 더 자세히 살펴보겠습니다. 데이터 수집부터 시작해서, 기본적인 랙에서는 문서를 가져와서 덩어리로 나누고 임베딩합니다. 간단하지만, 실제 운영 환경에서는 데이터가 간단하지 않습니다.06:06

PDF 파일에 표가 있고, 머리말과 바닥글이 있는 워드 문서, 콘텐츠에 혼합된 탐색 메뉴가 있는 HTML 페이지가 있습니다. 그냥 추출해서, 테스트하고, 무작정 덩어리(청크)로 나누면 모든 구조를 잃어버리게 됩니다.06:18

그래서 첫 번째 단계는 재구조화입니다. 문서를 분석하고 제목, 단락, 표, 코드 블록이 무엇인지 이해하게 됩니다.06:30

구조는 의미를 담고 있으며, 그걸 보존하고 싶어합니다. 다음은 구조를 고려한 청킹입니다. 토큰 500개마다 맹목적으로 나누는 대신, 문서의 자연스러운 경계에 따라 청킹을 하거든요.06:39

제목과 설명을 같이 유지하고, 코드 함수를 중간에 자르지 않아요. 대부분의 팀들이 채택하는 적절한 크기는 청크당 256에서 512 토큰 사이인데, 경계를 넘어 문맥을 유지하기 위해 약간의 중첩을 둬요.06:52

하지만 정확한 숫자는 구조를 존중하는 것만큼 중요하지 않습니다. 그리고 메타데이터 생성이 있습니다. 각 청크마다 텍스트와 임베딩만 저장하는 것이 아니라요.07:05

요약본을 만들어서 덩어리 안에 무엇이 담겨 있는지 알 수 있습니다. 핵심 키워드를 추출하기도 하고요. 유용한 팁이 하나 있습니다. 왜냐하면 이 덩어리가 답할 수 있는 가상의 질문들을 만들어 내거든요.07:14

사용자가 질문을 할 때, 질문 내용을 텍스트 조각들과 일치시키게 됩니다. 만약 텍스트 조각들에 미리 생성된 질문들이 연결되어 있다면, 질문과 질문을 비교하게 되는데, 이는 임의의 단락과 질문을 비교하는 것보다 훨씬 효과적입니다.07:24

지금 이 데이터 수집 파이프라인은 화려하지 않습니다. PDF 파일을 처리하는 일에 누가 흥미를 느끼겠습니까? 하지만 이것이 기초가 됩니다.07:36

데이터가 처음부터 제대로 구조화되지 않으면, 이후의 어떤 과정도 그것을 고칠 수 없습니다. 이제 이 모든 프로세스 데이터는 어디론가 가야 합니다. 대부분의 튜토리얼에서는 벡터 데이터베이스를 볼 수 있습니다. 임베딩을 저장하고 유사성 검색을 수행하는 것으로 끝납니다.07:43

하지만 제품 환경에서는 벡터만으로는 부족한 경우가 많습니다. 한번 생각해 보세요. 날짜별로 결과를 필터링해야 최신 정책 문서 버전을 가져올 수 있을 수도 있습니다.07:57

부서별로 또는 문서 유형별로 필터링해야 할 수도 있습니다. 또한, 동일한 문서에 속한 여러 조각의 정보를 결합해야 할 수도 있습니다.08:07

이것은 관계형 데이터입니다. 그리고 벡터 유사성만으로 이 모든 것을 처리하려고 하면 잘 안 됩니다. 그래서 프로덕션 시스템에서는 보통 둘 다 처리할 수 있는 데이터베이스를 사용합니다.08:15

의미론적 검색과 관계형 데이터에 대한 임베딩입니다. 필터링 및 조인을 위한 데이터이지요. 실제로 Neon과 같은 도구가 유용해지는 부분이며, 이번 영상의 스폰서이기도 합니다.08:25

네온은 서버리스 PostgreSQL입니다. 따라서 관계형 데이터베이스의 모든 강력한 기능을 활용하실 수 있습니다. 또한 PG 벡터를 지원하여 관계형 데이터와 함께 임베딩을 저장하고 검색할 수 있습니다.08:35

그러니 벡터 시스템과 메타데이터 시스템을 따로 관리하는 대신, 모든 것을 한 곳에서 관리할 수 있게 됩니다.08:47

의미론적 검색을 하고 동일한 쿼리에서 날짜별로 필터링할 수 있습니다. 조각들을 상위 문서에 다시 조인할 수도 있고, 버전 및 타임스탬프를 추적할 수도 있습니다.08:54

그리고 서버리스이기 때문에 자동으로 확장됩니다. RAC 시스템을 사용하지 않을 때, 이상적인 용량을 위해 돈을 지불하지 않아요. 그리고 트래픽이 급증할 때, 더 많은 리소스를 프로비저닝하려고 애쓰지도 않아요.09:03

트래픽이 없을 때는 0으로 축소할 수 있고, 요청이 들어오면 밀리세컨드 안에 다시 확장할 수 있습니다. 그런데 흥미로운 사실은 네온이 얼마 전에 데이터브릭스에 약 10억 달러에 인수되었다는 겁니다.09:13

네온이 Databricks에 인수된 이유가 인공지능 에이전트 때문이었습니다. 그들은 현재 네온에서 생성되는 데이터베이스의 80% 이상이 인간이 아닌 인공지능 에이전트에 의해 프로비저닝되고 있다고 밝혔습니다.09:25

한번 생각해 보세요. 인공지능 에이전트가 스스로 데이터베이스를 구축하여 정보를 저장하고 검색하는 것을요.09:35

그것이 상황이 흘러가는 방향입니다. 그리고 Neon의 아키텍처가 서버리스이고 즉시 프로비저닝할 수 있다는 점은 이러한 에이전트 기반 워크플로우에 자연스럽게 잘 어울립니다. Rack의 경우, 내부적으로 PostgreSQL을 사용하고 있다는 의미는 추가적으로도 가능합니다.09:41

데이터베이스 브랜치와 같은 기능이 있습니다. 전체 지식 베이스를 즉시 복제하여 프로덕션 환경에 영향을 주지 않고 새로운 청킹 전략이나 새로운 임베딩 모델을 테스트할 수 있습니다. 결과에 만족하면 다시 병합할 수 있습니다.09:54

데이터베이스의 Git과 비슷하다고 할 수 있습니다. 이제 쿼리가 들어왔을 때 어떤 일이 발생하는지 알아봅시다. 기본적인 Rack에서는 쿼리를 받아서 임베딩하고 가장 유사한 청크를 찾습니다. 하지만 쿼리가 명확하고 잘 구성되어 있다고 가정합니다.10:07

실제로 보면, 사용자들은 모호한 질문을 하세요. 그들이 사용하는 단어와 문서에 있는 단어가 다를 수 있어요. 때로는 하나의 쿼리가 여러 곳에서 정보를 필요로 할 때도 있습니다.10:20

그래서 하이브리드 검색이 필요한 이유가 바로 여기입니다. 벡터 유사성만 사용하는 것이 아니라 키워드 검색과 결합하는 방식이죠. 벡터 검색은 의미를 파악하는 데는 아주 좋지만, 벡터가 놓칠 수 있는 정확한 일치 항목은 키워드 검색이 잡아냅니다.10:31

제품 이름이나 오류 코드, 특정 용어 같은 것들이 있죠. 대부분의 실제 운영 시스템에서는 이 두 가지를 함께 사용하고, 결과를 다시 순위를 매겨 가장 관련성 높은 텍스트 조각들을 보여줍니다.10:43

하지만 좋은 검색 기능이 있어도 여전히 문제가 남아 있습니다. 텍스트 조각들을 가지고 있잖아요. 이제 그걸 어떻게 활용해야 할까요? 기본적인 RAG에서는 검색된 텍스트 조각들을 프롬프트에 넣고 LLM에게 답변을 생성하도록 요청합니다.10:53

간단한 질문에는 그렇게 작동하기도 합니다. 하지만 사용자가 복잡한 질문을 한다면 어떻게 될까요? 예를 들어, 유럽과 아시아의 3분기 성과를 비교하고 다음 분기에 어떤 지역에 집중해야 할지 제안해 달라는 질문은 단일 검색으로는 해결할 수 없습니다.11:06

유럽의 3분기 데이터가 필요하고요. 아시아의 3분기 데이터도 필요할 수 있어요. 과거 추세 정보도 필요할 수도 있고요.11:21

시장 현황에 대한 정보도 필요할 수 있고, 그런 모든 정보를 종합해서 판단을 내려야 할 거예요.11:26

그리고 이것이 추론 엔진이 작동하는 부분입니다. 쿼리에서 바로 검색 및 생성으로 넘어가는 것이 아니라, 먼저 쿼리가 실제로 무엇을 필요로 하는지 분석하는 플래너가 있습니다.11:32

어떤 정보가 필요한가요? 그리고 어떤 단계를 거쳐야 할까요?11:42

어떤 도구를 사용해야 할까요? 플래너가 계획을 세우면, 도구 실행 레이어가 그걸 실행합니다. 아마 여러 번 검색을 하거나, 시장 데이터를 가져오기 위해 외부 API를 호출할 수도 있습니다.11:46

그리고 혹시 계산을 하기도 합니다. 좀 더 발전된 시스템에서는 멀티 에이전트 시스템이 있어요. 다양한 분야를 전문으로 하는 여러 에이전트들이 존재합니다. 한 에이전트는 금융 데이터를 검색하는 데 능하고, 다른 에이전트는 요약하는 데 능할 수도 있어요.11:57

다른 에이전트는 계산을 담당할 수도 있습니다. 이 에이전트들은 프로세스 데이터베이스에서 작업을 수행하고, 여정의 해당 부분에 관련된 정보를 가져온 다음, 최종 응답으로 결합됩니다.12:11

이것이 사람들이 에이전트 웨이크(agentic wag)라고 이야기하는 의미입니다. 시스템은 단순히 검색하고 생성하는 것 이상입니다.12:21

이것은 추론하고, 계획하고, 여러 단계를 조정하여 복잡한 문제를 해결하는 것입니다. 하지만 중요한 것은, 복잡성이 증가하면 오류가 발생할 가능성이 더 커진다는 점입니다.12:28

에이전트가 잘못된 정보를 가져올 수도 있고, 플래너가 질문을 잘못 이해할 수도 있죠. 최종 답변은 확신에 찬 것처럼 들릴 수 있지만, 완전히 엉뚱한 내용일 수도 있어요. 그래서 검증이 필요한 이유예요.12:37

자, 그럼 이 아키텍처의 하단부를 살펴보겠습니다. 사용자에게 전달되기 전에 검증 노트를 통해 출력을 보내는 조건부 라우터가 있습니다. 응답이 실제로 질문에 답하는지 확인하는 게이트키퍼도 존재합니다.12:49

질문이 있습니다. 검색된 맥락에 기반하여 정보의 정확성을 검증하는 감사관과, 보다 넓은 맥락을 고려했을 때 답변이 타당한지 평가하는 전략가가 있습니다. 이는 인간이 생각하는 방식과 유사하게 모방하려는 아이디어입니다.13:01

답변을 보내기 전에, 실제로 질문에 대한 답변이 되었는지 스스로에게 물어보세요. 정확한가요? 말이 되는가요? 실제 운영 환경에서는 이 검증 노드들이 사용자에게 전달되기 전에 많은 문제를 해결합니다.13:15

자신감 있게 들리지만 출처 문서와 모순되는 답변이 있습니다. 또한, 질문과는 전혀 다른 질문에 대한 답변도 있습니다.13:28

중요한 제약 조건을 고려하지 않은 추천도 문제가 됩니다. 이제 다이어그램 오른쪽에는 평가가 있습니다. 이것은 시스템이 실제로 작동하는지 확인하는 방법입니다.13:35

그리고 세 가지 유형이 있습니다. 양적 평가는 LLM 평가단을 사용하여 충실도, 관련성, 깊이와 같은 측면을 평가합니다. 응답이 검색된 맥락에 충실한가요? 질문과 관련이 있나요?13:45

충분히 꼼꼼한가요? 양적 평가는 검색 정확도와 재현율을 측정합니다.13:57

검색된 정보 조각 중에서 실제로 관련 있는 조각은 몇 개였나요? 데이터베이스 내의 모든 관련 조각 중에서, 검색 시스템은 얼마나 성공적으로 불러왔으며, 성능 평가에서는 지연 시간과 비용이 측정됩니다. 각 쿼리는 얼마나 오래 걸리는지 알아내는 것이죠.14:03

얼마나 많은 토큰을 사용하고 계신가요? 규모가 커질 때 이 점이 중요합니다. 평가 없이 운영하면 상황을 제대로 파악하지 못하는 것과 같습니다. 시스템이 훌륭하게 작동한다고 생각하실 수도 있지만, 사용자들은 조용히 잘못된 답변을 받으실 수 있습니다.14:16

마지막으로, 다이어그램 맨 위에 배포 전에 스트레스 테스트를 진행해야 합니다. 시스템이 어떻게 망가지는지 알아야 하기 때문입니다. 이것이 바로 '고장내기 팀(vet teaming)'입니다. 의도적으로 여러분의 시스템을 망가뜨려 보려고 노력하는 것입니다.14:27

시스템에 프롬프트를 주입하여 지시사항을 무시하게 할 수 있나요? 아니면 유출해서는 안 되는 정보를 유출하게 할 수 있나요?14:39

질문을 특정 방식으로 표현함으로써 누군가가 편향되거나 유해한 결과를 얻을 수 있나요? 편향된 의견, 정보 회피, 프롬프트 인젝션에 대한 테스트를 수행해야 합니다. 사용자들이 발견하기 전에 취약점을 찾아야 합니다. 그리고 이것은 선택 사항이 아니에요.14:47

실제 사용자나 중요한 비즈니스 의사결정에 영향을 미치는 랙 시스템을 배포하신다면, 시스템의 고장 양상을 이해하시는 것이 필요합니다. 이것이 전체 아키텍처입니다.15:00

구조를 보존하고 풍부한 메타데이터를 생성하는 데이터 주입 방식입니다. 벡터 데이터와 관계형 데이터를 결합하는 데이터베이스 계층을 활용합니다.15:09

의미론적 검색과 키워드 검색을 모두 활용하는 하이브리드 검색 방식이 필요합니다. 복잡한 쿼리를 계획하고 실행할 수 있는 추론 엔진과 여러 단계를 거쳐야 하는 문제들을 위해 다중 에이전트 조정 기능도 중요합니다.15:16

풍부한 사용자에게 오류가 발생하기 전에 오류를 잡는 검증 노드들이 필요합니다. 그리고, 실제로 어떻게 작동하는지 측정하고 취약점을 찾기 위한 스트레스 테스트도 중요합니다.15:28

이것보다 훨씬 더 많은 과정이 필요해요. 하지만 실제 운영 환경에서 제대로 작동하는 것을 만들기 위해서는 이런 단계를 거쳐야 합니다.15:37