• Turing Post Korea
  • Posts
  • Topic #22: 계속되는 RAG의 진화 - HtmlRAG, 멀티모달 RAG, 에이전틱 RAG을 알아보자

Topic #22: 계속되는 RAG의 진화 - HtmlRAG, 멀티모달 RAG, 에이전틱 RAG을 알아보자

2025년의 AI 트렌드에 맞는 세 가지 새로운 RAG에 대해서 알아봅시다

AuthorAuthor

Ksenia Se & Ben Eum
January 28, 2025

글을 시작하며

RAG (Retrieval-Augmented Generation, 검색 증강 생성) 기법은 그 탄생 이후에 빠르게 분화하면서 진화하고 있죠. RAG에 익숙하지 않은 분들을 위해서 간단히 설명을 하자면, 이 기법은 ‘외부 자원 - 문서나 데이베이스 등 - 에서 실제로 필요한 정보를 검색해서, 모델에 외부 지식을 제공’해서 출력을 생성하게 하는 기법입니다.

오늘 에피소드에서는, 전통적인 RAG을 넘어서는 최신의 세 가지 접근 방식을 살펴볼까 합니다. 이 기법들은, 검색된 데이터의 품질, 답변의 정확성, 특정 도메인에서의 성능 저하 등 기존 RAG의 문제점을 극복하게끔 도와준다고 알려져 있는데요. 2025년 AI의 주요 초점이 멀티 모달리티, 그리고 에이전트 시스템인 만큼, 다음과 같은 RAG 유형을 살펴보겠습니다:

  • 텍스트의 HTML 버전을 직접 활용하는 HtmlRAG

  • 이미지 정보를 검색할 수 있는 Multimodal RAG

  • RAG 기술에 에이전트 기능을 통합한 Agentic RAG

자, 함께 들어가 볼까요?

오늘은 아래와 같은 내용을 다룹니다:

기존 RAG 기법의 한계

구조적으로 볼 때는, RAG 시스템은 ‘검색 메커니즘’과 ‘생성형 AI 모델’을 결합해서 더 정확하고, 더 맥락에 맞는 응답을 제공하는 기법입니다. 하지만, 모든 기술이 그렇듯이 몇 가지 한계가 있죠:

  1. 검색된 정보의 품질에 대한 의존성
    최종적인 출력물, 응답의 효과가, 검색된 문서의 품질, 관련성, 편향성 등에 크게 좌우됩니다. 검색 단계에서 실패나 오류가 있으면 생성된 출력이 부정확하거나 가치가 없을 수 있는 거죠.

  2. 다룰 수 있는 포맷의 제한 (내지는 어려움)
    표준 RAG로 이야기한다면, HTML 텍스트, 이미지, 비디오와 같은 다양한 유형의 정보를 검색할 수 없거나 힘듭니다.

  3. ‘검색’과 ‘사용자 질의’ 간의 매핑 오류 (또는 미스매치)
    시스템이 사용자의 쿼리 - 즉 질문 - 를 검색된 문서의 올바른 컨텍스트와 매핑하지 못할 수 있습니다.

  4. 복잡한 소스를 다루기 어려움
    표준 RAG는 여러 개의 소스를 검색하거나 복잡한 구조의 문서를 다루는데 어려움이 있습니다.

  5. 확장성 지연 문제
    검색 시스템이 최적화되지 않은 경우에, 특히 대형의 지식 베이스를 검색하는 데 지연이 발생하기 쉽습니다.

  6. 성능의 저하
    RAG 시스템은 맥락, 그리고 뉘앙스가 중요한, 고도로 전문화된 영역에서는 성능이 저하되기 쉽습니다.

  7. 컴퓨팅 자원
    검색을 위해 대규모 데이터셋을 처리하는 것은 상당한 저장 공간과 처리 능력이 필요해서, 컴퓨팅 관련 비용이 많이 소요될 수 있습니다.

물론, 이렇게 전통적인, 어찌보면 기본적인 RAG의 한계점을 극복하기 위해서 이미 다양하게 업그레이드된 RAG 기법, 시스템들이 나오고 있습니다.

오늘 에피소드에서 이야기할 세 가지 RAG 유형은, 그 중에서 주로 ‘검색 정보의 품질과 다양성’, 그리고 ‘사용자 질의와 검색 간의 불일치’라는 한계점을 해결하는데 집중하는 기법들입니다 - HtmlRAG, Multimodal RAG, 그리고 Agentic RAG을 소개합니다!

HtmlRAG이란?

HtmlRAG의 핵심 아이디어

여러분들이 많이 사용하실 챗GPT, 퍼플렉시티 같은 AI 도구 등에서 적용된 많은 RAG 시스템들은, 외부 정보의 출처로 ‘웹’을 많이 활용하죠.

일반적으로 이 시스템들은 이렇게 작동합니다: 웹을 검색하고, 웹페이지 결과를 수집하고, 그 내용을 일반 텍스트로 변환한 다음, 이 텍스트를 LLM에 제공해서 더 나은 답변을 생성하게 합니다. 그런데, 이런 일반적인 텍스트로 전환을 하게 되면 제목, 표, 기타 구조적 정보와 같은, 웹페이지가 담고 있는 유용한 세부 정보를 많이 잃어버리게 되겠죠.

이 문제를 해결하기 위해서, Baichuan Intelligent Technology, 그리고 중국 인민대학교의 연구자들이, 일반적인 텍스트 대신 원본의 HTML 형식을 사용하는 HtmlRAG를 소개했습니다

이 접근 방식의 장점은 뭘까요?

  • 최신의 LLM들은 HTML 구조를 잘 이해할 수 있다는 것 아시죠? 그래서 이런 LLM을 이용하면 일단 HtmlRAG을 쉽고 효과적으로 구현할 수가 있어요.

  • 앞서 말씀드렸다시피, HTML은 컨텐츠의 구조와 의미를 더 잘 보존합니다. 게다가, PDF나 워드 파일과 같은 수많은 문서 형식도 쉽게 HTML로 변환할 수 있어서, 문서를 처리하는 어플리케이션에 활용할 수 있는 좋은, 유연한 구조가 됩니다.

하지만 한 가지 문제가 있는데요. HTML에는 태그, 자바스크립트, 그리고 (불필요한) 데이터가 포함된 스타일 등 추가 요소들이 많고, 문서의 길이가 너무 길기도 하죠. 그래서 연구자들은 이런 문제들을 극복하기 위한 별도의 특별한 기술들도 함께 제안을 했습니다. 이 모든 것들이 어떻게 함께 작동하는지, 한 번 살펴보겠습니다.

HtmlRAG의 작동 방식과 한계

HtmlRAG는 원본 컨텐츠 - 즉 HTML 문서죠 - 의 구조와 의미를 더 많이 유지하기 위해서 데이터를 일반 텍스트로 변환하는 단계를 건너뛰고 HTML과 직접 상호작용합니다. HtmlRAG 작동 과정의 중요한 부분은, HTML Cleaning과 Pruning 기술입니다:

Image Credit: 오리지널 논문 ‘HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems’

HTML Cleaning

HTML Cleaning 단계 - 뭔가 청소하고 정리하는 단계 같죠? 이 단계에서는 ‘관련 없는 컨텐츠를 제거’하고, 문서의 구조를 단순화하고, 문서의 크기를 원래 길이의 약 6%로 줄입니다. 상세한 절차는 다음과 같습니다:

  • 문서의 내용이나 구조에 큰 기여를 하지 않는 부분, 즉 CSS 스타일, 자바스크립트, 주석 등을 제거합니다.

  • 중복되는 태그를 병합해서 (예시: 중첩된 <div> 태그 결합) HTML 문서의 구조를 단순화합니다.

  • 비어있거나 관련없는 태그를 제거합니다.

HtmlRAG의 이런 정리 과정은 일반 텍스트의 96.71%, 마크다운의 90.32%와 비교해 보면 토큰을 94.07% 줄여준다고 합니다.

HTML Pruning

HTML Cleaning에 이어서 실행되는 Pruning 단계는, 사용자의 질의를 기반으로 해서 ‘가장 관련성 있는 부분만 유지’하면서, 정리된 HTML의 크기를 한 차례 더 줄입니다. 이 단계는 앞 단계보다 조금 더 복잡한데, 간단히 말씀드리자면, 두 가지의 서로 다른 Pruning 작업, 그리고 HTML 부분을 그룹화하고 순위를 매기는 ‘Block Tree’ 접근 방식을 포함합니다.

그렇다면 Block Tree는 어떻게 만들까요? 우선, 검색된 모든 HTML 문서들을 하나로 결합합니다. 이렇게 결합된 문서를 Beautiful Soup 같은 도구를 사용해서 DOM 트리로 변환합니다. 그런 다음, Child Node가 Parent Node와 병합해서 Block을 형성하구요. 각 Block의 크기는 Block 당 최대 단어수 같은 설정을 통해서 제어하고, Tree의 상세한 수준은 어느 정도의 수준을 유지하도록 - 너무 상세하거나, 너무 대략적인 수준이 되지 않도록 - Pruning의 필요에 따라 조정할 수 있습니다. 데이터의 관련성 (Relevance)을 효율적으로 측정하기 위해서, Block Tree는 HTML 태그와 토큰이 색상으로 구분되는 Token Tree로 변환됩니다. 그런 다음, 토큰의 확률을 결합해서 Block Score를 도출합니다.

Image Credit: 오리지널 논문 ‘HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems’

이 Pruning 절차는 두 개의 단계로 진행되는데, 두 단계 모두 Block Tree 구조를 사용해서 이루어집니다:

1단계: 임베딩 모델을 이용한 Pruning

이 단계는, 경량의 임베딩 모델을 사용해서 HTML 문서 내에서 관련성이 적은 부분을 식별하고 제거하게 됩니다. 작동 방식은 다음과 같습니다:

  • 각 HTML 블록 텍스트를 임베딩 모델의 유사도 점수를 사용해서 사용자의 질의와 비교합니다.

  • LLM의 입력값 제한 수치를 맞추는 범위 내에서 관련성 점수가 낮은 블록들이 삭제됩니다.

  • Pruning 후에, 남은 HTML 구조에서 중복된 태그나 빈 요소를 제거하고 정리합니다.

이 방법은 문서의 크기를 빠르게 효과적으로 줄일 수 있지만, 각 블록의 개별적으로 평가하니까 전체의 문서 구조를 고려하는 방법은 아닌 거죠. 또, 정확한 관련성 (Relevance)을 판단하기에 텍스트가 충분하지 않은 아주 작은 블록에서는 작업이 애매할 수 있습니다. 그래서 두 번째 단계가 필요합니다.

2단계: 생성형 AI 모델을 활용한 세밀한 Pruning

생성형 AI 모델을 사용해서 문서의 전체 구조를 고려하면서 HTML을 더욱 세밀하게 정제합니다. 보통 생성형 AI 모델은 임베딩 모델과는 달리 전체 문서의 맥락을 한 번에 처리할 수 있는데, 이건 블록들 간의 미묘한 관계, 그 내용을 더 잘 파악할 수 있다는 뜻입니다. 그렇다면 어떻게 작동할까요?

  • 1단계에서 정제된 HTML로 시작해서 블록들을 더 작은 부분으로 세분화합니다.

  • 생성형 AI 모델이 사용자의 검색어와 얼마나 잘 부합하는지를 기준으로 문서의 각 작은 블록에 점수를 매깁니다. 이 점수는 각 블록으로 이어지는 태그들의 "경로"(예: <html><div><p>)를 분석해서 계산됩니다.

  • 점수가 낮은 블록들은 제거되어, 남은 HTML이 간단하면서도 의미있는 내용을 유지하도록 합니다.

이 과정을 최적화하기 위해서 HtmlRAG는 Token Skipping (토큰 건너뛰기) 방식을 사용합니다. 이 기법으로 모델이 반복되거나 예측 가능한 HTML 구조 부분을 건너뛰어서 컴퓨팅 자원을 절약하고, ‘깊이를 우선하는 탐색 기법 (Depth-First Traversal Technique)’을 통해서 이전에 계산된 데이터를 재사용, 중복을 줄이고 처리 속도를 높입니다.

HTML Pruning는 평균 토큰 수를 160만 개에서 4천 개로 줄이면서도 관련성 (Relevance)을 같은 수준으로 유지해 줍니다. 또 노드의 45%를 건너뛰어, 효과는 유지하면서 비용 증가를 최소화해 줍니다.

HtmlRAG의 한계

HtmlRAG이 좋은 결과를 보여줄 수 있지만, 여전히 몇 가지 한계점이 있습니다:

  • HTML의 품질에 의존
    HtmlRAG는 ‘잘 구조화된’ HTML 입력 문서에 의존성이 높다는 걸 알 수 있습니다. 따라서, 불완전하거나 구조가 잘못된 페이지를 처리할 때는 성능이 저하될 수 있습니다.

  • ‘멀티 소스’ 입력 처리의 난점
    여러 개 출처의 정보를 종합할 때, 맥락을 이해하거나 적절한 가중치를 부여하는 데 어려움이 있을 수 있습니다.

  • ‘도메인 특수성’이라는 제약
    HTML 페이지가 일반적인 구조와 다른 니치 마켓, 또는 고도로 전문화된 분야에서는 HtmlRAG가 최적의 성능을 발휘하지 못하는 경우가 있을 수 있습니다.

물론, 이러한 한계에도 불구하고 HtmlRAG는 더 복잡한 텍스트 형식을 잘 다뤄서 ‘검색의 정확도’를 효과적으로 높여주는 새로운 기법임에는 틀림없습니다. 자, 그렇다면, 여기에 ‘이미지 정보’를 다룰 수 있는 능력이 더해진다면, RAG의 성능이 더 개선되지 않을까요?

Multimodal RAG이란?

Multimodal RAG의 핵심 아이디어

2025년, AI의 핵심 키워드 중 하나, 바로 ‘멀티모달 (Multimodality)’이죠. 이 시대에, 멀티모달 데이터를 처리할 수 있는 RAG 기술이 필요하다는 건 자명합니다.

Multimodal RAG의 아이디어는, 2022년 구글 리서치가 MuRAG 기법을 통해서 탐구했는데요. 그 이후를 보자면, 이런 유형의 RAG에 대한 최신의 연구 중 하나로 ‘Center for Information and Language Processing’ 그리고 Siemens AG의 연구를 들 수 있습니다. 이 연구에서는 기술 및 산업 관련된 문서에서 이미지 정보를 처리하고 검색하는 두 가지 방법을 시험했는데요. 핵심적인 궁금증은 이거죠 - Multimodal RAG 기법이 텍스트만 사용하는 RAG보다 성능이 더 나을까요?

Multimodal RAG의 작동 방식과 성능

먼저, PDF 같은 문서에서 이미지 정보를 처리하고 검색하는 방법을 정의해야겠죠. 연구자들은 두 가지 방법을 제시합니다:

  1. 멀티모달 임베딩 (Multimodal Embeddings)
    이 방법은, 이미지가 뜻하는 시각적인 의미를 텍스트 검색어와 직접적으로 연결합니다. 작동 방식은 다음과 같습니다:

    • CLIP 도구를 사용해서 이미지, 그리고 질문 모두를 임베딩으로 변환합니다.

    • 질문과 가장 관련성이 높은 이미지를 찾기 위해서 유사도를 계산합니다.

    • 검색된 이미지를 AI 모델이 답변을 생성하는 데 사용합니다.

  2. 이미지를 텍스트로 전환, 요약
    이미지를 텍스트로 변환하면 텍스트 기반 RAG 파이프라인과 통합하는 게 더 쉬워지고, 검색 과정에서 정보 손실의 위험이 줄어듭니다. 작동 과정은 다음과 같습니다:

    • 이미지의 요약본을 텍스트로 임베딩해서 벡터 데이터베이스에 저장합니다.

    • 질문이 들어오면, 시스템은 가장 관련성 높은 텍스트 요약본을 검색해서 원본 이미지와 함께 AI 모델에 전달합니다.

우선, 텍스트와 이미지 정보를 어떻게 결합해서 Multimodal RAG를 만드는지 살펴보시죠. 이런 RAG 유형을 두 가지 구성으로 테스트해 봅니다:

Image Credit: 오리지널 논문 ‘Beyond Text: Optimizing RAG with Multimodal Inputs for Industrial Applications’

  1. 별도의 이중 벡터 데이터베이스 구조

텍스트 청크들은 하나의 벡터 데이터베이스에 저장되고, 이미지 임베딩은 다른 별도의 벡터 데이터베이스에 저장됩니다. 시스템은 두 벡터 데이터베이스 사이에서 유사도 검색을 하구요. 검색된 텍스트, 그리고 이미지 데이터를 결합해서 AI 모델 답변을 생성하는데 입력값으로 사용합니다.

이렇게 접근하면, 텍스트와 이미지 데이터를 분리된 상태로 유지해서, 각각 형식에 대한 독립적인 최적화를 할 수 있겠죠.

  1. 통합된 벡터 데이터베이스 구조

이 방법은, 이미지를 텍스트로 변환해서 요약한 것, 그리고 문서 (PDF)의 텍스트 청크를 먼저 결합합니다. 둘 다 텍스트로 임베딩되어서, 하나의 벡터 데이터베이스에 저장됩니다. 그런 다음, 통합된 벡터 데이터베이스에서 단일 유사도 검색을 실행, 텍스트와 이미지에서 파생된 요약 모두를 검색하죠. AI 모델은 질문에 답하기 위해서 이 통합된 정보를 받아오게 됩니다.

이렇게 모든 정보를 하나의 데이터베이스에 저장하면, 검색 과정이 단순화되고, 텍스트와 이미지 정보가 일관되게 처리되도록 보장할 수 있습니다.

다양한 실험의 결과를 살펴보면, ‘텍스트와 이미지를 결합’하는 방식이 ‘텍스트나 이미지만 단독으로 사용’하는 방식보다 성능이 더 나은 것으로 나타나고 있습니다. 그리고, 위의 Multimodal RAG의 두 가지 기법 중에서는, ‘이미지를 텍스트로 변환, 요약’하는 방식이 멀티모달 임베딩보다 더 유연하고 효과적인 걸로 보이구요.

Image Credit: 오리지널 논문 ‘Beyond Text: Optimizing RAG with Multimodal Inputs for Industrial Applications’

하지만 Multimodal RAG에도 몇 가지 한계가 있습니다:

  • LLM에 의존하다 보니 부정확성, 환각, 복잡한 멀티모달 입력 처리의 어려움 같은 일반적인 LLM의 문제점들이 나타납니다.

  • 공개적으로 사용 가능한 도메인별 데이터셋이 부족해서, 연구 결과의 재현성 (Reproducibility)과 일반화 가능성 (Generalization)에 제약이 있을 수 있습니다. 결국, 이런 데이터셋을 개발하는 것이 향후의 지속적인 성능 개선을 위해서 아주 중요합니다.

자, 말씀드린 것처럼, 전반적인 결과는 RAG에 멀티모달 기능을 추가하는 것이 RAG 시스템의 효과성에 긍정적인 영향을 미친다는 점을 보여주고 있는데요.

하지만 멀티모달 기능만큼 중요한 ‘에이전트 기능’은 어떨까요?

Agentic RAG이란?

2025년 (뿐 아니라, 앞으로 계속해서) 에이전트 시스템이 부상할 것이 확실해 보이는데요. 얼마 전 오픈AI에서도 ‘Operator’라는 이름의 AI 에이전트를 프리뷰 공개했습니다.

에이전트 시스테을 구성하는 모든 요소, 그 자체도 더 ‘에이전트처럼’ 움직이고 작동해야 하겠죠. 그래서 많은 AI 연구자들이 Agentic RAG 개념을 탐구하고 있습니다. 이 Agentic RAG 시스템의 작동 방식을 이해하기 위한 방편으로, 허깅페이스가 만든 버전의 Agentic RAG 시스템을 살펴볼까 합니다.

Agentic RAG이 해결하려고 하는 문제

이 글의 서두에서, 표준 RAG 시스템이 가진 한계점을 이야기했는데요. 다시 한 번 이 한계점들, 특히 ‘사용자의 질의와 검색 간의 미스매치, 그리고 검색 데이터의 품질과 관련된 것들을 살펴볼께요:

  • 사용자의 질의는 (당연히) 주로 질문의 형태로 작성되지만, 지식 베이스의 문서는 동일한 정보를 다른 방식으로 표현할 수 있죠. 이런 미스매치 때문에 검색 품질이 저하될 수 있습니다.

  • 초기의 검색에서 목표를 제대로 확보하지 못하면, 이후에 생성된 응답이 부정확하거나 불완전할 가능성이 당연히 높겠죠.

자, 여기서 Agentic RAG가 등장합니다 - 이건 시스템에 ‘에이전트와 같은 기능’을 부여해서 RAG의 성능을 향상시키는데, 다음과 같은 작업을 수행하게 됩니다:

  • 질의의 재구성
    사용자의 질문을 관련 문서의 구조와 더 잘 일치하는, ‘검색 친화적인 문장’으로 변환합니다.

  • 검색 결과의 비평 및 재시도
    검색된 결과를 평가하고, 부족한 점이나 관련성이 없는 부분을 인식해서 수정/업데이트된 질의로 다시 시도합니다.

Agentic RAG의 작동 방식과 장점, 그리고 한계

Agentic RAG의 작동 방식

Agentic RAG도 전통적인 RAG 시스템처럼 ‘의미적 유사도’를 사용해서 벡터 데이터베이스를 검색하는데요. 그 작동 방식은 다음과 같습니다:

  • 에이전트가 사용자의 질의를 검색 친화적인 문장으로 변환하는 것으로 시작합니다. 문서와의 Alignment를 개선하기 위해서, ‘질문’의 형태가 아닌 ‘긍정문’의 형태로 질의를 받아들입니다. 예를 들면, 사용자의 질의가 "Hub에 모델을 어떻게 업로드하나요?"라고 하면, 재구성된 질의는 "Hub에 모델 업로드하기"가 되겠죠.

  • 질의 내용을 사용해서 Agentic RAG가 임베딩의 유사도를 기반으로 상위 k개의 관련 문서를 데이터베이스에서 검색합니다.

  • 검색된 내용을 반환하고 추가 분석을 진행합니다. 검색된 결과가 불충분하거나 관련성이 낮다면, 에이전트가 이를 평가해서 새로운 질의를 생성합니다. 그리고 이 과정을 충분한 정보가 검색되거나 미리 설정된 제한에 도달할 때까지 반복합니다.

  • 에이전트가 검색된 맥락에 만족할 수준이 되면, 이 정보를 사용자 질의와 결합해서 LLM에 전달하고 최종 응답을 생성합니다.

Agentic RAG의 장점과 한계

Agentic RAG은 더 자율적으로 ‘의미적으로 다른’ 질의로 검색을 다시 시도하는 구조라서, 올바른 - 관련성이 높은 - 정보를 찾을 가능성을 높여 줍니다. 특히 영역이 복잡하거나 도메인에 특화된 질문의 경우에 정확도, 완성도를 크게 향상시켜 주는데, 한 연구에 따르면 질의를 재구성하고 반복적으로 검색하는 작업만으로 표준 RAG의 성능을 14% 이상 향상시킬 수 있었다고 하네요.

물론 이런 이점의 이면에는 다음과 같은 문제들도 있습니다:

  • 표준적인 RAG 시스템에 비해 설정이나 실행 과정의 추가적인 복잡성이 있습니다.

  • 질의를 재구성하고 검색을 반복함으로써 계산 오버헤드가 증가합니다.

  • 시스템의 품질이, 언어 모델이 정확하고 맥락에 맞게 질의를 재구성하는 능력, 그리고 답변을 생성하는 능력에 크게 의존하게 됩니다.

  • 자동화된 평가 과정 중에 LLM의 판단에 의존하기 때문에 일종의 ‘편향’ 등 문제가 발생할 수 있습니다. 사람을 이 Loop에 어떻게 들어가게 할 수 있느냐가 하나의 고려 사항이 되겠습니다.

맺으며

오늘 에피소드에서는, ‘검색 정보의 품질’과 ‘전반적인 효율성 및 정확성’ 측면에서 표준적인 RAG의 성능을 향상시켜주는 세 가지 RAG 시스템, HtmlRAG, Multimodal RAG, 그리고 Agentic RAG를 살펴봤습니다.

복잡한 구조를 가진 문서를 다룰 때는 HtmlRAG가 리소스를 절약하면서 텍스트의 중요한 구조를 모두 유지, 이해하는데 도움을 줄 수 있습니다. 멀티모달 시대, 이미지를 다루지 않고는 AI 분야를 상상할 수 없는데, 이런 경우에는 Multimodal RAG를 반드시 고려해 봐야 되겠죠. Agentic RAG는 RAG를 새로운 수준의 자율성, 그리고 정확성으로 끌어올릴 수 있는 또 다른 차원의 시스템입니다.

AI 모델의 급격한 발전과 능력의 개선, 결국 AI 모델을 사용하는 RAG 기법과 기술도 함께 발전해야 합니다. 계속해서 새로운 혁신을 주시하고, 우리의 현장에서 테스트하면서 확산을 시도해야 할 때가 아닌가 합니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!

Reply

or to participate.