본문 바로가기

ALL

 (131)
4. 멀티모달 RAG 멀티모달 RAG LLM은 최신 정보 답변 불가, 부정확한 답변, 정보 출처 불분명 등 여러 한계를 가지고 있다. RAG은 참고할 문서를 찾아서 사용자의 요청과 함께 LLM에 전달함으로써 한계를 해결한다. 그리고 이전까지 살펴본 RAG은 모두 텍스트만을 다루고 있었다. 사용자의 요청도 텍스트이고, 참고할 문서도 모두 텍스트이다. 하지만 멀티모달 RAG은 여기서 더 나아가 오디오, 이미지, 비디오 등 여러 양식의 데이터를 다룬다. 세상의 정보는 텍스트로만 이루어져 있지 않다. 오히려 텍스트 이외의 데이터가 더욱 많다. 그래서 텍스트 뿐 아니라 여러 데이터를 다루는 멀티모달 RAG이 다양한 정보를 함께 이해하고 더 풍부한 답을 줄수 있다. 멀티모달 RAG 구조 텍스트 데이터만 다룰때는 RAG의 구조가 단순..
3. RAG 검색 성능 개선 백터 검색의 한계점 문서를 임베딩하여 벡터로 저장하고, 이를 사용자 요청과 비교하여 가장 유사한 문서를 가져오는 것이 일반적인 RAG 검색기의 구조이다. 그러나 여기에는 몇가지 한계가 있다. 먼저 문서를 벡터로 변환하는 과정에서 정보의 손실이 발생한다. 벡터 변환이란 문서를 n개의 숫자로 재 표현하는 것을 의미하는데, 어떤 길이와 내용의 문서라도 동일한 n개의 숫자로 나타내기 때문에 정보의 손실이 발생하는 것은 어쩔 수 없다. 또 벡터화된 문서를 검색하는 과정에서도 손실이 발생할 수 있다. 검색해야할 문서가 많은 경우 검색 시간 단축을 위해 최적화 알고리즘을 적용하는 경우가 있는데, 이 때 검색 되어야될 문서가 검색되지 않을 수 있다. 단순한 해결방법: 더 많은 문서를 가져오자! 분명 사용자의 요청에..
2. 임베딩과 벡터저장소를 활용한 RAG 키워드 검색의 한계 검색 엔진이 초기에 의존했던 키워드 매칭 방식은 단어 자체가 일치해야만 문서를 찾을 수 있습니다. 예를 들어 “비오는날 음식”이라는 쿼리로 파전 을 추천하려면, 파전 문서 안에 “비오는날 음식”의 키워드가 정확히 있어야 합니다. 하지만 파전을 설명하는 문서에는 다음과 같이 있습니다. "파전: 한국 요리 중의 하나로서, 반죽한 밀가루에 파를 넣어 부친 전". 문장에 ‘비오는날 음식’이라는 키워드가 없으므로 전통적인 키워드 검색으로는 해당 문서를 찾지 못합니다.즉, 의미와 상관없이 표현이 다르면 검색이 빗나가는 구조적 한계가 존재합니다. 임베딩이란 이러한 문제를 해결하기 위한 대표적인 기술이 바로 임베딩(Embedding) 입니다. 임베딩이란 텍스트를 고차원 벡터 공간으로 변환하는 기술..
1. LLM의 한계와 RAG(검색 증강 생성) LLM의 주요 한계점 LLM은 방대한 양의 텍스트 데이터로 학습하지만, 이 지식은 LLM 모델에 명시적으로 저장되는 것이 아니라, 확률적인 패턴 형태로 저장된다. 이러한 특성 때문에 LLM은 본질적인 한계를 가지고있다.부정확한 정보 생성 (환각 현상): LLM은 확률적으로 가장 그럴듯한 다음 단어를 예측하며 텍스트를 생성한다. 실제 사실인 데이터를 기반으로 학습했다고 했을지라도, 이 데이터들이 모델에 저장될때는 확률적인 패턴으로 저장된다. 이 때문에 응답을 생성할 때 사실이 아닌 내용을 마치 사실인 것처럼 꾸며내는 '환각(Hallucination)' 현상이 발생할 수 있다.최신 정보 부족: LLM은 학습 시점 이후에 발생한 사건이나 새롭게 등장한 정보에 대해서는 알지 못한다. 예를 들어, 만약 "트랄랄레..
Flyway를 활용한 DB Migration 자주 겪는 일 일반적으로 소스, 서버, DB 등 서비스 환경은 개발, 검증, 운영으로 나누어져 있다. 개발자들은 이렇게 나누어진 환경 때문에 번거로운 과정들을 거쳐야 한다. 프로젝트를 진행하다 보면 기존의 소스와 테이블을 바꾸어야 하는 경우가 자주 발생 한다. 실제로 이전에 진행했던 프로젝트에서는 기획 변경으로 인해 필요한 데이터가 바뀌면 1) 로컬의 소스와 DB를 수정하여 작업하고, 2) 개발계 DB 수정을 요청하고, 개발계에 소스를 올리고 배포한 후, 3) 검증, 운영계도 같은 과정을 수행하였다. 하지만 위와 같은 과정들은 번거로운 뿐더러 여러 문제를 발생시켰다. 담당자가 직접 DB를 수정하다보니 실수로 계획한 것과 다르게 반영되어 장애가 발생하거나, DB 담당자 부재시 소스 배포도 함께 불가능해지..
Jest와 React Jest란 가장 대표적인 JavaScript 테스트 프레임 워크이다. Jest 이전에는 JavaScript 테스트에 필요한 Test Runner(mocha), Test Matcher(sinon), Mocking(test mock) 라이브러리들을 조합하여 테스트를 진행해야 했다. 하지만 Jest는 All-in-one 테스트 프레임 워크로서 쉽게 구성하고 사용할 수 있다. CRA(Create React App)에서의 Jest Jest를 사용하기 위해서는 관련 라이브러리와 스크립트 설정등 화녕 구성이 필요하지만 CRA로 만들어진 react 앱에는 모든 내용이 포함되어있다. 그리고 App의 테스트 코드가 들어있는 App.test.ts까지 만들어져 있다. import React from 'react'; impor..
아이템 83: 지연 초기화는 신중히 사용하라 지연 초기화 public class FileUtil { private File oldfile = new File("oldfile"); ... } 여기 FileUtil 클래스가 있다. 이 클래스의 oldfile 필드가 프로그램이 100번 실행될 때 한 번 사용될 까 말까하는 필드라면 어떨까? 100번 실행되는 동안 사용하지도 않을 oldfile을 계속 불러와서 초기화 할 것이고 이는 명백한 리소스 낭비이다. 지연 초기화는 위와 같은 문제에 대한 해답이 될 수 있다. 자주 사용되지 않는 필드를 프로그램이 시작할 때가 아니라 비로소 사용될 때 초기화 하는 것이다. public class OldFileUtil { private File oldfile = null; ... public File getOldFile..
아이템 82: 스레드 안정성 수준을 문서화하라 스레드 안정성 문서화 클래스를 개발할 때, 해당 클래스를 사용할 클라이언트들을 위하여 필요한 정보들을 주석으로 작성하여 문서화 해야한다. 아무런 설명이 없다면 클라이언트는 추측과 가정을 통해 그 클래스를 사용하게 된다. 특히 스레드 안정성에 대한 정보는 설명이 필요한 중요한 정보 중 하나이다. 스레드 안정성이 잘못되면 프로그램에 심각한 오류가 발생할 것이다. 스레드 안정성 수준 불변(immutable): 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화가 필요없다. 무조건적 스레드 안전(unconditionally thread-safe): 이 클래스의 인스턴스는 수정될 수 있으나, 내부에서 충실히 동기화하여 별도의 외부 동기화 없이 동시에 사용해도 안전하다. 조건부 스레드 안전(conditional..

티스토리툴바