AI

대화의 연속성 (Context Window)

사리생성 2026. 1. 22. 10:39

 


open-webui 볼륨 내부의 실제 데이터 구조

 

  • webui.db (가장 중요)
    • 역할: SQLite 데이터베이스 파일입니다.
    • 내용: 사용자 계정 정보, 비밀번호(해시), 채팅 히스토리, 설정값, 모델 리스트 등 텍스트로 된 거의 모든 핵심 데이터가 이 파일 하나에 저장됩니다.
    • 주의: 볼륨 삭제 시 이 파일이 사라지기 때문에 모든 대화 기록이 날아가는 것입니다.
  • vector_db
    • 역할: 벡터 데이터베이스 저장소입니다.
    • 내용: 사용자가 문서(PDF, TXT 등)를 업로드했을 때, AI가 검색할 수 있도록 수치화(Embedding)한 데이터가 저장됩니다. RAG(문서 기반 답변) 기능을 사용할 때 참조되는 곳입니다.
  • uploads
    • 역할: 원본 파일 저장소입니다.
    • 내용: 채팅창에 직접 업로드한 이미지나 문서 파일들이 보관됩니다.
  • cache
    • 역할: 임시 데이터 저장소입니다.
    • 내용: 모델의 아이콘, 웹 리소스, 또는 처리 중인 임시 파일들이 저장되어 시스템 속도를 높이는 역할을 합니다. 삭제해도 시스템 운영에 치명적이지는 않지만 다시 생성되는 동안 느려질 수 있습니다.

 

 

Open WebUI(구 Ollama WebUI)가 사용자와의 대화에서 '문맥(Context)'을 기억하고 대화의 연속성을 유지하는 방식은 단순히 이전 말을 기억하는 것 이상의 복잡한 과정을 거칩니다.

대화의 연속성을 위해 Open WebUI가 수행하는 핵심 메커니즘 3가지는 다음과 같습니다.

1. 컨텍스트 윈도우(Context Window) 관리

LLM(거대언어모델)은 기본적으로 '기억력'이 없습니다. 매 질문마다 이전 대화 전체를 다시 모델에게 보내줘야 합니다.

  • 대화 이력 전송: 사용자가 새 메시지를 보내면, Open WebUI는 webui.db에 저장된 이전 대화 묶음을 꺼내 질문 앞에 붙여서 모델에게 보냅니다.
  • 슬라이딩 윈도우: 모델이 한 번에 처리할 수 있는 토큰(글자 단위) 한계가 있습니다. 대화가 너무 길어지면 Open WebUI는 가장 오래된 대화부터 잘라내어 최신 문맥이 유지되도록 관리합니다.

2. RAG (Retrieval-Augmented Generation) 활용

Retrieval-Augmented Generation(검색 증강 생성)은 대규모 언어 모델(LLM)이 답변을 생성하기 전에 외부의 신뢰할 수 있는 지식 베이스에서 관련 정보를 검색하여, 더 정확하고 최신이며 출처가 명확한 답변을 생성하도록 돕는 AI 기술입니다

 

질문이 특정 문서나 지식에 관한 것이라면, 단순한 대화 이력만으로는 부족합니다.

  • 지식 검색: 사용자가 업로드한 문서(PDF 등)를 vector_db에서 찾아 질문과 가장 관련 있는 부분을 추출합니다.
  • 정보 주입: 추출된 정보를 "이 내용을 참고해서 답해줘"라는 지시와 함께 프롬프트에 포함시켜, 모델이 모르는 내용도 마치 알고 있는 것처럼 연속성 있게 대답하게 합니다.

3. 세션 및 데이터베이스(SQLite) 동기화

사용자가 브라우저를 껐다 켜도 대화가 이어지는 이유는 앞서 보신 파일들 덕분입니다.

  • webui.db의 역할: 사용자가 입력하는 즉시 대화 내용을 데이터베이스에 기록합니다.
  • 상태 보존: 특정 대화 세션의 ID를 기반으로, 모델 설정(온도, 시스템 프롬프트 등)과 과거 답변들을 매칭하여 일관된 답변 톤을 유지합니다.

💡 대화 연속성 메커니즘 요약

기능 목적 관련 파일/기술
히스토리 추적 이전 대화 내용을 기억하고 참조 webui.db
시스템 프롬프트 AI의 페르소나와 답변 규칙 유지 설정값 (Settings)
임베딩 검색 대용량 문서 데이터를 대화에 반영 vector_db (RAG)

 

대화가 끊어진 느낌이 든다면.

 

Open WebUI와 Ollama를 사용하실 때 **Context Length(컨텍스트 길이)**는 AI가 한 번에 "기억하고 처리할 수 있는 데이터의 총량"을 의미합니다.

책에 비유하자면, AI가 현재 펼쳐놓고 볼 수 있는 **'책상의 크기'**와 같습니다. 책상이 좁으면 앞 내용을 계속 치워야(삭제해야) 새 내용을 읽을 수 있는 것과 같은 원리입니다.

1. Context Length가 중요한 이유

  • 기억력: 이 값이 클수록 아주 긴 대화나 방대한 양의 문서 내용을 끝까지 기억하며 답변할 수 있습니다.1
  •  
  • 답변 품질: 문맥이 충분히 제공되어야 AI가 사용자의 의도를 정확히 파악하고 일관성 있는 답변을 내놓습니다.
  • 성능(속도): 값이 너무 크면 그래픽카드(RTX 4060)의 VRAM을 많이 점유하여 답변 속도가 느려지거나, 메모리 부족(OOM) 오류가 발생할 수 있습니다.

2. Open WebUI에서 설정하는 방법

Open WebUI 설정 창에서 모델별로 이 값을 조정할 수 있습니다.

  1. 모델 설정: 채팅창 상단 모델 선택 메뉴에서 설정(톱니바퀴 아이콘) 클릭
  2. Advanced Parameters: 하단으로 내려가서 'Advanced Parameters' 확장
  3. Context Length: 여기서 숫자를 변경 (기본값은 보통 2048 또는 4096)

3. 기술적 메커니즘: 토큰(Tokens)

컨텍스트 길이는 글자 수가 아니라 토큰(Token) 단위로 계산됩니다.

  • 1024 토큰은 영어 기준으로 약 750단어 정도입니다.
  • 사용자 질문 + 이전 대화 기록 + AI 답변 예정 분량이 이 숫자를 초과하면, 가장 오래된 대화부터 webui.db에서 읽어오지 않거나 모델 입력 단계에서 잘라냅니다.

4. 사용자님의 환경(RTX 4060) 권장 설정

현재 사용 중인 RTX 4060(VRAM 8GB) 환경에서는 모델 크기에 따라 최적의 값이 다릅니다:

모델 크기 권장 Context Length 비고
Gemma 3:4b 8192 ~ 16384 가벼운 모델이라 길게 설정 가능
Qwen 2.5:7b 4096 ~ 8192 8GB VRAM에서 안정적인 수준
Llama 3:8b 4096 VRAM 사용량이 아슬아슬할 수 있음

팁: 대화 도중 AI가 갑자기 "방금 말한 내용을 기억 못 하거나 엉뚱한 소리"를 한다면, 컨텍스트 길이를 조금 더 늘려보시는 것이 좋습니다.

 

 

GPU 메모리 최적화 설정

RTX 4060(8GB VRAM) 환경에서 Open WebUI와 Ollama를 최적으로 사용하기 위한 GPU 메모리 최적화 설정을 정리해 드립니다. 8GB는 7B~9B 모델을 돌리기에 다소 타이트할 수 있으므로, 아래 설정들을 적용하면 훨씬 쾌적해집니다.

1. Ollama 환경 변수 최적화 (서버 측)

Podman이나 Docker로 Ollama를 실행할 때 다음 환경 변수를 추가하여 메모리 점유를 제어하세요.

  • OLLAMA_MAX_LOADED_MODELS=1: 한 번에 하나의 모델만 GPU에 올리도록 제한합니다. 여러 모델을 불러와 VRAM이 낭비되는 것을 방지합니다.
  • OLLAMA_NUM_PARALLEL=1: 동시 요청 처리 수를 1개로 제한하여 KV 캐시가 VRAM을 과도하게 잡아먹지 않게 합니다.
  • OLLAMA_FLASH_ATTENTION=1: (지원 모델 한정) 연산 효율을 높이고 메모리 사용량을 줄여주는 Flash Attention 기능을 활성화합니다.

명령어 예시 (Podman 실행 시):

Bash
 
podman run -d --gpus all \
  -e OLLAMA_MAX_LOADED_MODELS=1 \
  -e OLLAMA_NUM_PARALLEL=1 \
  -e OLLAMA_FLASH_ATTENTION=1 \
  --name ollama ollama/ollama

2. Open WebUI 모델 파라미터 조정 (클라이언트 측)

Open WebUI의 Settings > Models > (모델 선택) > Advanced Parameters에서 조정합니다.

  • Num GPU (num_gpu):
    • 보통 -1이나 35 이상으로 설정되어 모든 레이어가 GPU에 올라가야 빠릅니다.
    • 만약 모델이 너무 커서 속도가 급격히 느려진다면(CPU 오프로딩 발생), 이 값을 수동으로 조금씩 줄여서 VRAM에 딱 맞게 조절할 수 있습니다.
  • Keep Alive:
    • 기본값은 5분입니다. 메모리를 빨리 비우고 싶다면 5m 대신 1m이나 0(즉시 해제)으로 설정하세요. 다른 GPU 작업(게임 등)을 병행할 때 유용합니다.

3. RAG(문서 관리) 메모리 최적화

사용자님이 보신 vector_db 관련 설정입니다. Settings > Documents에서 수정합니다.

  • Embedding Model Engine: 기본 모델 대신 **Ollama**를 선택하고, **bge-m3:open-webui**나 all-minilm 같은 아주 가벼운 임베딩 모델을 사용하세요.
  • 대형 모델을 임베딩용으로 쓰면 채팅용 모델과 VRAM을 나누어 써야 하므로 속도가 반토막 납니다.

4. 기타 하드웨어 팁

  • 브라우저 하드웨어 가속: Open WebUI를 띄운 브라우저(크롬 등)도 GPU를 사용합니다. VRAM이 1GB 정도 모자란 상황이라면 브라우저의 '하드웨어 가속'을 끄는 것만으로도 모델이 GPU에 완벽히 올라갈 공간을 확보할 수 있습니다.
  • 리눅스 환경 유지: 현재 사용 중인 Ubuntu 환경은 윈도우(WSL2)보다 GPU 메모리 오버헤드가 적어 8GB VRAM을 활용하기에 최적의 조건입니다.

💡 추천 설정값 요약 (RTX 4060 기준)

항목 설정값 효과
Context Length 4096 ~ 8192 문맥 유지와 속도의 균형
Max Loaded Models 1 VRAM 중복 점유 방지
Flash Attention Enabled 추론 속도 향상 및 메모리 절약
Keep Alive 5m (또는 필요시 0) GPU 자원 반납 속도 조절

 

 

 

 

----

 

토큰(Token)

LLM(거대언어모델)에서 **토큰(Token)**은 모델이 텍스트를 이해하고 생성하는 최소 처리 단위

LLM(거대언어모델)에서 **토큰(Token)**은 모델이 텍스트를 이해하고 생성하는 최소 처리 단위입니다. 사람이 문장을 '단어'나 '글자'로 이해한다면, AI는 이를 '토큰'이라는 조각으로 나누어 처리합니다.

1. 토큰이 만들어지는 과정 (Tokenization)

컴퓨터는 텍스트를 직접 이해할 수 없기 때문에, 숫자로 변환하는 과정이 필요합니다. 이 과정을 **토크나이저(Tokenizer)**가 수행합니다.

  • 영어: 대략 단어 1개 ≈ 0.75개~1개 토큰으로 계산됩니다. (예: "apple" → 1토큰)
  • 한국어: 한글은 조사와 어미가 발달해 있어 영어보다 복잡합니다. 형태소 단위로 쪼개지거나, 글자당 1~3개의 토큰이 소모될 수 있습니다. (예: "먹었습니다" → "먹", "었", "습니다" 등으로 분리)
  • 공백 및 기호: 띄어쓰기, 마침표, 줄바꿈 등도 모두 각각의 토큰으로 계산됩니다.

2. 왜 토큰이 중요한가요?

구분 설명
비용 계산 대부분의 AI API(OpenAI, Google Cloud 등)는 글자 수가 아니라 사용된 토큰 수를 기준으로 요금을 부과합니다.
기억력 제한 앞서 질문하신 '컨텍스트 윈도우'는 이 토큰의 최대 수용량을 의미합니다. 토큰 제한을 넘어가면 AI는 대화의 앞부분을 잊어버립니다.
처리 속도 토큰이 많을수록 AI가 계산해야 할 양이 늘어나 답변 속도가 느려질 수 있습니다.

3. 토큰을 아끼는 팁

  1. 불필요한 공백 제거: 의미 없는 빈 줄이나 중복된 공백도 토큰을 소모합니다.
  2. 직설적인 표현: 장황한 수식어보다는 명확하고 간결한 문장이 토큰 효율이 좋습니다.
  3. 한국어 최적화 모델 사용: 최근 출시된 모델(HyperCLOVA X, 최신 Gemini 등)은 한국어를 더 효율적으로 토큰화하여 같은 내용도 더 적은 토큰으로 처리합니다.

🔍 직접 확인해보기

사용 중인 문장이 몇 개의 토큰으로 구성되는지 궁금하다면 각 개발사가 제공하는 Tokenizer Tool을 사용해 볼 수 있습니다.

  • OpenAI Tokenizer: GPT 모델 기준 토큰 수 확인 가능
  • Google AI Studio: Gemini 모델의 프롬프트 입력창 하단에서 실시간 토큰 수 확인 가능

 

----

 

Conversation History

 

 

**대화 기록(Conversation History)**은 LLM이 사용자와 주고받은 이전 메시지들을 기억하여 문맥에 맞는 답변을 할 수 있게 해주는 핵심 장치입니다.

AI 모델 자체는 기본적으로 '상태가 없는(Stateless)' 상태입니다. 즉, 질문을 던질 때마다 모델은 이전 내용을 모두 잊어버린 채 새로 시작합니다. 우리가 연속적인 대화를 한다고 느끼는 이유는 서비스(ChatGPT, Gemini 등)가 이전 대화 내용을 매번 질문과 함께 모델에게 다시 전달해주기 때문입니다.

1. 대화 기록의 작동 원리

대화가 길어질 때 내부적으로는 다음과 같은 과정이 반복됩니다.

  1. 첫 번째 질문: 사용자: "안녕?" → 모델: "안녕하세요!"
  2. 두 번째 질문: 사용자: "오늘 날씨 어때?"
  3. 모델에게 전달되는 실제 데이터: > [이전 대화] 사용자: "안녕?" / 모델: "안녕하세요!"
  4. [현재 질문] 사용자: "오늘 날씨 어때?"
  5. 결과: 모델은 이전 대화를 읽고 "아, 인사 다음에 날씨를 묻는구나"라고 파악하여 답변합니다.

2. 대화 기록 관리의 주요 개념

  • 히스토리 버퍼 (History Buffer): 지금까지 나눈 대화 전체를 저장하는 공간입니다.
  • 컨텍스트 윈도우 제한: 앞서 배운 것처럼 모델이 한 번에 처리할 수 있는 토큰 양은 정해져 있습니다. 대화가 너무 길어져서 이 제한을 넘어가면 가장 오래된 대화부터 삭제됩니다.
  • 역할 분담 (Roles): 대화 기록 내에서 각각의 메시지는 누구의 것인지 구분됩니다.
    • System: AI의 성격이나 규칙 설정 (예: "너는 친절한 수학 선생님이야.")
    • User: 사용자가 입력한 메시지
    • Assistant (AI): AI가 이전에 했던 답변

3. 효율적인 대화 기록 관리 기법 (개발 및 고급 활용)

대화가 무한정 길어질 수 없기 때문에, 효율적으로 기억을 관리하는 여러 전략이 사용됩니다.

기법 설명
Sliding Window 정해진 개수의 최근 메시지(예: 최신 10개)만 유지하고 나머지는 버림.
Summarization 이전 대화 내용을 AI가 스스로 요약하여 짧은 문장으로 압축해 기억함.
Vector DB (RAG) 아주 오래된 대화는 외부 저장소에 넣어두었다가, 관련 있는 내용이 나올 때만 다시 꺼내옴.

💡 사용자가 체감하는 특징

  • 지시 사항 누적: 대화 초반에 "앞으로 모든 답변은 존댓말로 해줘"라고 말하면, 대화 기록 덕분에 이후 대화에서도 그 규칙이 유지됩니다.
  • 지칭어 이해: "그거 다시 설명해줘"라고 했을 때, '그거'가 무엇인지 이전 기록에서 찾아냅니다.

대화 기록이 너무 길어져서 AI의 답변 속도가 느려지거나 과거 내용을 자꾸 잊어버린다고 느껴지시나요? 그렇다면 대화를 새로 시작하거나 요약을 요청하는 것이 방법이 될 수 있습니다.

 

 

-----

 

 

Stateless

LLM(AI) 관점에서의 차이

우리가 사용하는 대부분의 LLM API는 본질적으로 Stateless입니다.

구분 LLM에서의 작동 방식
Stateless (모델 본체) 모델은 당신이 5분 전에 무엇을 물었는지 기억하지 못합니다. 모델 입장에서는 매 질문이 늘 '첫 질문'입니다.
Stateful (서비스 인터페이스) ChatGPT 같은 서비스가 'Stateful'하게 느껴지는 이유는, 서비스가 내부적으로 대화 기록을 계속 덧붙여서(Stateless 모델에게) 다시 보내주기 때문입니다.

요약 비교

항목 Stateless (상태 비저장) Stateful (상태 유지)
기억 여부 기억 안 함 (독립적) 기억함 (연속적)
데이터 전달 매번 전체 정보를 보냄 바뀐 부분이나 식별자만 보냄
확장성 매우 높음 (서버 교체 자유로움) 낮음 (기억을 가진 서버로 가야 함)
대표 예시 HTTP, DNS, REST API TCP, 온라인 뱅킹, 게임 서버

 

 

 

----

 

summarization

 

요약(Summarization)**은 방대한 양의 정보를 핵심 내용 위주로 압축하는 기술입니다. LLM 시대에 들어서면서 요약은 단순히 길이를 줄이는 것을 넘어, 문맥의 의미를 파악해 재구성하는 수준으로 발전했습니다.

특히 앞서 대화했던 '컨텍스트 윈도우'와 '대화 기록' 문제를 해결하는 아주 강력한 도구이기도 합니다.

1. 요약의 두 가지 방식

AI가 요약을 수행하는 방식은 크게 두 가지로 나뉩니다.

  • 추출적 요약 (Extractive Summarization): * 원문에서 가장 중요한 문장 몇 개를 그대로 뽑아내는 방식입니다.
    • 장점: 원문 왜곡이 적고 정확합니다.
    • 단점: 문장이 매끄럽지 않을 수 있습니다.
  • 생성적 요약 (Abstractive Summarization): * 내용을 이해한 뒤 AI가 새로운 문장으로 재작성하는 방식입니다. (현재의 LLM 방식)
    • 장점: 사람이 요약한 것처럼 자연스럽고 핵심 파악이 뛰어납니다.
    • 단점: 원문에 없는 내용을 지어내는 '할루시네이션(환각)'이 발생할 수 있습니다.

2. 대화 기록 관리에서의 요약 전략

대화가 길어져 토큰 한도(Context Window)에 다다랐을 때, Stateful한 경험을 유지하기 위해 AI 시스템은 다음과 같은 전략을 씁니다.

  1. 전체 요약 (Full Summary): 지금까지의 모든 대화 내용을 한 단락의 요약본으로 바꿉니다. 그리고 새로운 질문을 던질 때 [요약본] + [새 질문] 형태로 모델에게 보냅니다.
  2. 증분 요약 (Incremental Summary): 대화가 추가될 때마다 기존 요약본에 새로운 내용을 조금씩 업데이트하며 크기를 일정하게 유지합니다.

3. 요약을 잘 시키는 방법 (Prompt Engineering)

LLM에게 요약을 시킬 때 더 좋은 결과를 얻으려면 기준을 명확히 주어야 합니다.

  • 대상 지정: "이 회의록을 결정 사항 위주로 요약해줘."
  • 길이 제한: "전체 내용을 3문장 이내 또는 200자 내외로 줄여줘."
  • 형식 지정: "불렛 포인트(Bullet Points) 형식으로 정리해줘."
  • 대상 독자 설정: "초등학생이 이해할 수 있을 정도로 쉽게 요약해줘."

4. 요약의 한계와 주의점

  • 정보 손실: 압축 과정에서 세부 수치나 고유 명사가 생략될 수 있습니다.
  • 편향성: AI가 중요하다고 판단한 기준이 사용자의 의도와 다를 수 있습니다.

 

 

 

 

 

---------------------------------

 

Auto-Compressors

 

"Auto-Compressors" 또는 **"Auto-Compaction"**에 대해 물어보신 것이 맞을까요?

컴퓨팅과 LLM 분야에서 이 용어들은 주로 **"데이터나 컨텍스트를 자동으로 압축하여 효율을 높이는 기술"**을 의미합니다. 앞서 우리가 이야기한 '토큰'과 '대화 기록' 관리의 연장선에 있는 개념입니다.

가장 관련 깊은 두 가지 관점에서 설명해 드릴게요.

1. LLM 컨텍스트 자동 압축 (Context Auto-Compression)

대화가 길어지면 토큰이 꽉 차서 비용이 비싸지고 속도가 느려집니다. 이를 해결하기 위해 시스템이 알아서 중요하지 않은 토큰을 쳐내거나 요약하는 기술입니다.

  • 작동 방식: AI가 대화 내용 중 "안녕", "반가워" 같은 부가적인 부분은 삭제하고, **핵심 의미를 담은 토큰(Summary 또는 Soft Tokens)**만 남깁니다.
  • 장점: 사용자는 대화 흐름이 끊긴다고 느끼지 않으면서도, 모델은 훨씬 적은 양의 데이터를 처리하므로 응답 속도가 빨라집니다.

2. 데이터베이스 자동 압축 (Auto-Compaction)

만약 벡터 데이터베이스(Vector DB)나 로그 시스템을 다루고 계신다면, 이 용어는 저장 공간 관리를 의미합니다.

  • 작동 방식: 데이터가 수정되거나 삭제될 때 생기는 '빈 공간'들을 자동으로 정리하고, 흩어져 있는 데이터 조각들을 하나로 모으는 작업입니다.
  • 비유: 책꽂이에서 책을 몇 권 뺐을 때 생긴 빈틈을 메우기 위해 남은 책들을 한쪽으로 밀어 정리하는 것과 같습니다.

💡 왜 이 기술이 중요한가요?

LLM 서비스 운영자 입장에서는 비용 절감이 가장 큰 이유입니다.

  1. 토큰 절약: 불필요한 데이터를 자동으로 압축해서 보내면 API 호출 비용이 줄어듭니다.
  2. 성능 유지: 컨텍스트 윈도우가 가득 차서 발생하는 정보 유실(Forgetfulness) 현상을 방지합니다.

 

 

 

 

 

----------------------------

 

데이터를 최적화하는 기술

 

LM(거대언어모델) 환경에서 **Auto Compact(자동 압축)**는 주로 긴 대화나 방대한 데이터를 처리할 때, 제한된 컨텍스트 윈도우를 효율적으로 사용하기 위해 시스템이 스스로 데이터를 최적화하는 기술을 의미합니다.

주로 LlamaIndex나 LangChain 같은 LLM 프레임워크나 벡터 데이터베이스에서 이 용어를 사용합니다. 핵심적인 세 가지 측면에서 정리해 드릴게요.

1. 컨텍스트 자동 압축 (Context Auto-Compaction)

대화 기록이 길어지면 모델의 토큰 한도를 초과하게 됩니다. 이때 사용자가 수동으로 요약하지 않아도 시스템이 알아서 처리하는 방식입니다.

  • 작동 원리: 대화 내용이 일정 토큰(예: 한도의 80%)에 도달하면, 시스템이 이전 대화들을 분석하여 중요하지 않은 수식어는 삭제하고 핵심 정보만 추출하여 새로운 '압축된 컨텍스트'로 재구성합니다.
  • 효과: 대화의 맥락(State)은 유지하면서 사용 토큰 수는 획기적으로 줄여 비용을 아끼고 모델의 '망각' 현상을 방지합니다.

2. 검색 결과 자동 압축 (RAG Post-Processing)

RAG(검색 증강 생성) 시스템에서 외부 문서를 불러올 때, 문서 전체를 모델에게 주는 것이 아니라 필요한 부분만 압축해서 전달하는 과정입니다.

  • Selective Context: 검색된 문서들 중 질문과 관련성이 낮은 문장이나 중복되는 단어를 AI가 사전에 필터링합니다.
  • LongLLMLingua: Microsoft에서 발표한 기술로, 토큰 간의 정보 밀도를 계산하여 정보 가치가 낮은 토큰을 제거함으로써 컨텍스트를 최대 20배까지 압축하면서도 성능을 유지합니다.

3. 스토리지 자동 압축 (Storage Auto-Compaction)

LLM이 기억을 저장하는 Vector Database에서 발생하는 기술적 관리 프로세스입니다.

  • 데이터 정리: 대화 기록이나 임베딩 데이터가 수정/삭제될 때 발생하는 파편화된 저장 공간을 자동으로 하나로 모으는 작업입니다.
  • 인덱스 최적화: AI가 데이터를 더 빨리 찾을 수 있도록 데이터 구조를 주기적으로 재배치합니다.

요약: 왜 Auto Compact를 쓰나요?

특징 효과
비용 절감 불필요한 토큰 소비를 줄여 API 호출 비용을 낮춤.
성능 향상 모델이 핵심 정보에 더 집중하게 하여 답변의 정확도를 높임.
무한 대화 컨텍스트 한도에 구애받지 않고 매우 긴 대화를 이어갈 수 있음.

🛠️ 구현 예시 (LlamaIndex 등)

만약 개발자라면, ContextChatEngine 같은 도구를 설정할 때 compact 옵션을 활성화하면 됩니다. 그러면 시스템은 매 질문마다 전체 히스토리를 보내는 대신, 토큰이 찰 때마다 자동으로 요약본으로 교체하며 대화를 이어갑니다.

'AI' 카테고리의 다른 글

RAG -> milvus (밀부스) + Elasticsearch ( chroma T.T )  (0) 2026.01.24
머신러닝 - Transformer  (0) 2026.01.23
lm studio (토큰 보여줘서)  (0) 2026.01.22
ubuntu <-> mac 원격 접속  (0) 2026.01.20
Grok docker-compose mysql 설치 + ChatGPT 유저생성쿼리.  (0) 2025.09.13

'AI'의 다른글

  • 현재글대화의 연속성 (Context Window)

관련글

티스토리툴바