2024년 중반에는 감동적이고 흥미진진한 AI 데모를 만드는 것이 쉬울 수 있습니다. 강력한 개발자, 영리하고 즉각적인 실험, 강력한 기반 모델에 대한 몇 가지 API 호출을 사용하면 오후에 맞춤형 AI 봇을 구축할 수 있는 경우가 많습니다. 다음과 같은 라이브러리에 추가하십시오. 랭체인 또는 라마인덱스 RAG를 사용하여 약간의 사용자 정의 데이터로 LLM을 강화하면 오후 작업이 주말 프로젝트로 바뀔 수 있습니다.

하지만 생산에 들어가는 것은 또 다른 문제입니다. 대규모로 안정적이고 관찰 가능하며 조정 가능하고 성능이 뛰어난 시스템이 필요합니다. 인위적인 데모 시나리오를 넘어서 실제 고객 행동의 전체 스펙트럼을 나타내는 광범위한 프롬프트에 대한 애플리케이션의 응답을 고려하는 것이 중요합니다. LLM은 사전 훈련 데이터세트에는 없는 경우가 많은 분야별 지식의 풍부한 자료에 액세스해야 할 수도 있습니다. 마지막으로, 정확성이 중요한 사용 사례에 AI를 적용하는 경우 환각을 감지, 모니터링 및 완화해야 합니다.

이러한 모든 문제를 해결하는 것이 어려워 보일 수 있지만 RAG 기반 애플리케이션을 각각의 개념적 부분으로 분해한 다음 필요에 따라 각 부분을 개선하기 위한 대상화되고 반복적인 접근 방식을 취하면 관리하기가 더 쉬워집니다. 이 게시물은 당신이 그렇게 하는 데 도움이 될 것입니다. 여기서는 검색 시 다운스트림에서 발생하는 기술보다는 RAG 문서 처리 파이프라인을 생성하는 데 사용되는 기술에만 집중할 것입니다. 이를 통해 생성 AI 애플리케이션 개발자가 프로토타입에서 생산까지의 여정을 더 잘 준비할 수 있도록 돕는 것이 목표입니다.

최신 데이터 레이크: AI 인프라의 중심

AI 시대에는 데이터가 해자 라는 말을 자주 듣습니다. 이를 위해 프로덕션급 RAG 애플리케이션을 구축하려면 독점 코퍼스를 구성하는 데이터 덩어리를 저장, 버전 관리, 처리, 평가 및 쿼리하는 데 적합한 데이터 인프라가 필요합니다. MinIO는 AI에 대해 데이터 우선 접근 방식을 취하므로 이러한 유형의 프로젝트에 대한 기본 초기 인프라 권장 사항은 최신 데이터 레이크와 벡터 데이터베이스를 설정하는 것입니다. 도중에 다른 보조 도구를 연결해야 할 수도 있지만 이 두 가지 인프라 장치가 기본입니다. 이는 RAG 애플리케이션을 프로덕션에 적용하는 과정에서 발생하는 거의 모든 작업의 중심 역할을 합니다.

MinIO를 기반으로 구축된 최신 데이터 레이크 참조 아키텍처를 찾을 수 있습니다. 여기 . 이 아키텍처가 모든 AI/ML 워크로드를 지원하는 방법을 보여주는 동반 문서는 다음과 같습니다. 여기 .

RAG: 문서 파이프라인 단계

평가

프로덕션급 RAG 애플리케이션을 구축하기 위한 중요한 초기 단계는 평가 프레임워크(종종 간단히 평가라고 함)를 설정하는 것입니다. 평가가 없으면 시스템이 얼마나 잘 수행되고 있는지, 어떤 구성 요소를 조정해야 하는지, 실제 진전이 있는지 판단할 수 있는 방법이 없습니다. 또한 평가는 해결하려는 문제를 명확히 하기 위한 강제 기능 역할을 합니다. 다음은 가장 일반적인 평가 기술 중 일부입니다.

• 경험적 코드 기반 평가 - 출력 토큰 수, 키워드 존재/부재, JSON 유효성 등과 같은 다양한 측정값을 사용하여 프로그래밍 방식으로 출력의 점수를 매깁니다. 이는 기존 단위 테스트를 위한 정규식 및 어설션 라이브러리를 사용하여 결정론적으로 평가할 수 있는 경우가 많습니다.

  
  

• 알고리즘 코드 기반 평가 - 잘 알려진 다양한 데이터 과학 지표를 사용하여 결과를 채점합니다. 예를 들어 프롬프트를 순위 문제로 재구성하면 정규화된 할인 누적 이득(NDCG) 또는 평균 상호 순위(MRR)와 같은 추천 시스템의 널리 사용되는 채점 기능을 사용할 수 있습니다. 반대로 프롬프트를 분류 문제로 구성할 수 있는 경우 정밀도, 재현율 및 F1 점수가 적절할 수 있습니다. 마지막으로 BLEU, ROUGE 및 SAS(의미론적 답변 유사성)와 같은 측정값을 사용하여 의미론적 출력을 알려진 기준 실제값과 비교할 수 있습니다.

  
  

• 모델 기반 평가 - 한 모델을 사용하여 다음 항목에 자세히 설명된 대로 다른 모델의 결과를 평가합니다. 판사로서 LLM 심사 종이. 이 기술은 인기가 높아지고 있으며 규모를 확장하는 데 인간보다 훨씬 저렴합니다. 그러나 프로젝트를 프로토타입에서 프로덕션으로 이동하는 초기 단계에서는 평가자가 LLM이므로 안정적으로 구현하는 것이 까다로울 수 있습니다. 이 경우 기본 시스템 자체와 유사한 제한 및 편견이 적용되는 경우가 많습니다. 이 분야의 연구, 도구, 모범 사례가 빠르게 발전하고 있으므로 주의 깊게 관찰하세요.

  
  

• 인간 평가 - 인간 도메인 전문가에게 최선의 답변을 요청하는 것이 일반적으로 최적의 기준입니다. 이 방법은 느리고 비용이 많이 들지만, 통찰력을 얻고 초기 평가 데이터 세트를 구축하는 데 매우 중요할 수 있으므로 간과해서는 안 됩니다. 수행된 작업에서 추가 마일리지를 원할 경우 다음에 자세히 설명된 것과 같은 기술을 사용할 수 있습니다. 자동 평가가 올바르게 완료됨 인간 전문가가 생성한 평가를 합성 변형으로 보완하는 논문입니다.

어떤 평가 기술을 사용할지 결정하는 것과 함께 사용자 정의 벤치마크 평가 데이터세트(일반적으로 다음과 같은 Hugging Face 순위표에서 사용되는 일반적인 데이터세트)를 만드는 것을 고려해보세요. MMLU 데이터 세트는 작동하지 않습니다. 사용자 정의 평가 데이터세트에는 다양한 프롬프트와 실제 고객이 애플리케이션에 입력할 프롬프트 유형을 대표하는 도메인별 이상적인 응답이 포함됩니다. 이상적으로는 인간 전문가가 평가 데이터세트를 만드는 데 도움을 줄 수 있지만, 그렇지 않다면 직접 수행하는 것도 고려해 보세요. 어떤 프롬프트가 나올지 추측할 자신이 없다면 운영 가설을 세우고 마치 검증된 것처럼 앞으로 나아가십시오. 나중에 더 많은 데이터를 사용할 수 있게 되면 가설을 지속적으로 수정할 수 있습니다.

LLM이 구체적인 판단 유형(이진, 범주, 순위, 숫자 또는 텍스트)으로 응답할 수 있도록 평가 데이터 세트의 각 행에 대한 입력 프롬프트에 제약 조건을 적용하는 것을 고려하세요. 판단 유형을 혼합하면 평가가 합리적으로 다양하게 유지되고 결과 편향이 줄어듭니다. Ceteris paribus, 평가 테스트 사례가 많을수록 좋습니다. 그러나 이 단계에서는 양보다 질에 중점을 두는 것이 좋습니다. LLM 미세 조정에 대한 최근 연구 LIMA: 정렬에는 적을수록 좋습니다 논문에서는 1,000행의 작은 평가 데이터 세트라도 실제 더 넓은 모집단을 대표하는 샘플이라면 출력 품질을 극적으로 향상시킬 수 있다고 제안합니다. RAG 애플리케이션을 통해 우리는 수십에서 수백 개의 행으로 구성된 평가 데이터 세트를 사용하여 성능 향상을 일화적으로 관찰했습니다.

임시적으로 수동으로 평가 실행을 시작할 수 있지만 평가 채점 프로세스 실행을 자동화하는 CI/CD 파이프라인을 구현하기 전에 너무 오래 기다리지 마십시오. 매일 평가를 실행하거나 소스 코드 저장소 및 관찰 가능성 도구에 연결된 트리거에서 평가를 실행하는 것은 일반적으로 ML-ops 모범 사례로 간주됩니다. 다음과 같은 오픈 소스 RAG 평가 프레임워크 사용을 고려해보세요. 라가스 또는 DeepEval 신속하게 시작하고 실행하는 데 도움이 됩니다. 버전이 지정된 평가 데이터세트와 평가가 실행될 때마다 생성되는 다양한 출력 지표가 모두 포함된 테이블에 대한 정보 소스로 데이터 레이크를 사용하세요. 이 데이터는 프로젝트 후반에 전략적이고 목표가 명확한 개선을 위해 사용할 수 있는 귀중한 통찰력을 제공합니다.

데이터 추출기

처음에 프로토타입을 시작하는 RAG 코퍼스는 프로덕션에 들어가기에 거의 충분하지 않습니다. LLM이 환각, 누락 및 문제가 있는 유형의 편견을 줄이는 데 도움이 되도록 지속적으로 추가 데이터로 말뭉치를 보강해야 할 것입니다. 이는 일반적으로 업스트림 데이터를 다운스트림 문서 파이프라인에서 추가로 처리할 수 있는 형식으로 변환하는 추출기와 로더를 구축하여 사례별로 수행됩니다.

필요한 것보다 더 많은 데이터를 수집하여 바다를 끓이려고 시도하는 데는 약간의 위험이 있지만 회사가 액세스할 수 있는 고품질 정보 소스에 대해 창의적이고 고정 관념에서 벗어나는 것이 중요합니다. 분명한 가능성에는 기업 OLTP 및 데이터 웨어하우스에 저장된 구조화된 데이터에서 통찰력을 추출하는 것이 포함될 수 있습니다. 기업 블로그 게시물, 백서, 출판된 연구, 고객 지원 문의 등의 출처도 고려해야 합니다. 단, 이러한 출처는 적절하게 익명화되고 민감한 정보를 삭제할 수 있어야 합니다. 소량의 고품질 도메인 내 데이터를 코퍼스에 추가하면 성능에 미치는 긍정적인 영향을 아무리 강조해도 지나치지 않으므로 탐색하고, 실험하고, 반복하는 데 시간을 투자하는 것을 두려워하지 마세요. 다음은 고품질 도메인 내 코퍼스를 부트스트랩하는 데 일반적으로 사용되는 몇 가지 기술입니다.

• 문서 추출 - 독점 PDF, 사무용 문서, 프리젠테이션 및 마크다운 파일은 풍부한 정보 소스가 될 수 있습니다. 이 데이터를 추출하기 위해 오픈 소스 및 SaaS 도구로 구성된 광범위한 생태계가 존재합니다. 일반적으로 데이터 추출기는 파일 유형별(JSON, CSV, docx 등), OCR 기반이거나 기계 학습 및 컴퓨터 비전 알고리즘을 기반으로 합니다. 간단하게 시작하고 필요한 경우에만 복잡성을 추가하세요.

  
  

• API 추출 - 공개 및 비공개 API는 도메인 내 지식의 풍부한 소스가 될 수 있습니다. 또한 잘 설계된 JSON 및 XML 기반 웹 API에는 이미 일부 기본 제공 구조가 있으므로 관련 없는 것으로 간주되는 항목을 삭제하면서 페이로드 내에서 관련 속성의 대상 추출을 더 쉽게 수행할 수 있습니다. 사용하려는 각 API에 대해 사용자 정의 ETL을 작성하는 것을 방지하는 데 도움이 되는 저렴한 로우 코드 및 노코드 API 커넥터로 구성된 광범위한 에코시스템이 존재합니다. 이는 전담 데이터 엔지니어 팀 없이는 유지 관리 및 확장이 어려울 수 있는 접근 방식입니다.

  
  

• 웹 스크레이퍼 - 웹페이지는 트리와 같은 DOM 구조를 가진 반구조화된 데이터로 간주됩니다. 찾고 있는 정보가 무엇인지, 해당 정보가 어디에 있는지, 해당 정보가 있는 페이지 레이아웃을 알고 있다면 잘 문서화된 API 없이도 이 데이터를 소비하는 스크레이퍼를 빠르게 구축할 수 있습니다. 웹 스크래핑을 위한 귀중한 추상화를 제공하기 위해 많은 스크립팅 라이브러리와 로우 코드 도구가 존재합니다.

  
  

• 웹 크롤러 - 웹 크롤러는 웹페이지를 탐색하고 재귀적인 URL 목록을 작성할 수 있습니다. 이 방법을 스크래핑과 결합하여 기준에 따라 정보를 검색, 요약 및 필터링할 수 있습니다. 보다 중요한 규모로 보면 이 기술을 사용하여 자신만의 지식 그래프를 만들 수 있습니다.

  
  

데이터 수집에 어떤 기술을 사용하든 해킹된 일회성 스크립트를 작성하려는 충동에 저항하십시오. 대신, 데이터 엔지니어링 모범 사례를 적용하여 데이터 레이크 내부 테이블에 데이터를 저장하는 반복 가능하고 내결함성이 있는 ETL 파이프라인으로 추출기를 배포하세요. 이러한 파이프라인(소스 URL 및 추출 시간과 같은 주요 메타데이터 요소)을 실행할 때마다 각 콘텐츠와 함께 캡처되고 레이블이 지정되는지 확인하세요. 메타데이터 캡처는 다운스트림 데이터 정리, 필터링, 중복 제거, 디버깅 및 속성 분석에 매우 유용합니다.

청킹

청킹은 큰 텍스트 샘플을 LLM의 컨텍스트 창에 맞을 수 있는 더 작은 개별 조각으로 줄입니다. 컨텍스트 창이 점점 더 커지고 추론 중에 더 많은 콘텐츠 덩어리를 채울 수 있지만 청킹은 정확성, 재현율 및 계산 효율성 사이의 적절한 균형을 유지하기 위한 중요한 전략으로 남아 있습니다.

효과적인 청크를 생성하려면 적절한 청크 크기를 선택해야 합니다. 청크 크기가 클수록 컨텍스트 창 내에 존재하는 총 청크 수가 적어지는 대신 텍스트의 컨텍스트와 의미적 의미가 보존되는 경향이 있습니다. 반대로 청크 크기가 작을수록 LLM의 컨텍스트 창에 더 많은 콘텐츠 청크를 채울 수 있습니다. 그러나 추가 가드레일이 없으면 각 콘텐츠 조각이 주변 컨텍스트에서 제거될 때 품질이 저하될 위험이 있습니다.

청크 크기 외에도 다양한 청크 전략과 방법을 평가해야 합니다. 고려해야 할 몇 가지 표준 청크 방법은 다음과 같습니다.

• 고정 크기 전략 - 이 방법에서는 콘텐츠 청크에 대해 고정된 수의 토큰을 선택하고 그에 따라 콘텐츠를 더 작은 청크로 분해합니다. 일반적으로 이 전략을 사용할 때 너무 많은 컨텍스트 손실을 피하기 위해 인접한 청크 간의 일부 겹치는 것이 좋습니다. 이는 가장 간단한 청킹 전략이며 일반적으로 더 정교한 전략을 시도하기 전에 좋은 출발점이 됩니다.

  
  

• 동적 크기 전략 - 이 방법은 다양한 콘텐츠 특성을 사용하여 청크를 시작하고 중지할 위치를 결정합니다. 간단한 예는 마침표 및 새 줄과 같은 특정 문자의 존재 여부에 따라 문장을 분할하는 구두점 청커입니다. 구두점 청커는 간단하고 짧은 콘텐츠(예: 트윗, 문자가 제한된 제품 설명 등)에는 합리적으로 잘 작동할 수 있지만 더 길고 복잡한 콘텐츠에 사용하면 명백한 단점이 있습니다.

  
  

• 콘텐츠 인식 전략 - 콘텐츠 인식 청커는 추출되는 콘텐츠 및 메타데이터 유형에 맞게 조정되고 이러한 특성을 사용하여 각 청크를 시작하고 중지할 위치를 결정합니다. 헤더 태그를 사용하여 청크 경계를 나타내는 HTML 블로그용 청커를 예로 들 수 있습니다. 또 다른 예는 각 문장의 쌍별 코사인 유사성 점수를 이전 이웃과 비교하여 문맥이 새 청크의 설명을 보장할 만큼 충분히 실질적으로 변경된 시기를 결정하는 의미론적 청커일 수 있습니다.

  
  

RAG 애플리케이션에 대한 최적의 청크 전략은 LLM의 컨텍스트 창 길이, 기본 텍스트 구조, 텍스트 길이 및 코퍼스 콘텐츠의 복잡성에 맞게 조정되어야 합니다. 다양한 청킹 전략을 자유롭게 실험하고 각 변경 후에 평가를 실행하여 주어진 전략에 대한 애플리케이션 성능을 더 잘 이해하십시오. 데이터 레이크 테이블에서 청크된 콘텐츠의 버전을 지정하고 각 청크에 업스트림 데이터 추출 단계의 원시 콘텐츠와 해당 메타데이터를 추적할 수 있는 계보 정보가 있는지 확인하세요.

풍부하게 함

대부분의 경우 RAG 중에 검색을 위해 인덱싱된 콘텐츠 청크는 프로덕션 환경에서 애플리케이션이 접하게 되는 실제 프롬프트와 상황에 따라 다릅니다. 예를 들어, AI 질문 답변 봇을 구축하는 경우 고객 쿼리에 대한 수많은 정답이 포함된 방대한 독점 정보 모음이 있을 수 있습니다. 그러나 원시 형태에서는 코퍼스가 유사성 기반 임베딩 검색에 이상적인 질문-답변 쌍 형식으로 미리 구성되어 있을 가능성이 없습니다. 이 예에서 검색 시 인바운드 고객 질문과 의미상 유사한 원시 콘텐츠 덩어리를 순진하게 검색하면 검색 결과 집합의 차선의 관련성이 발생할 수 있습니다. 이는 문맥상 서로 다른 항목, 즉 질문과 답변의 유사성을 비교하고 있다는 사실의 결과입니다. 다행스럽게도 솔루션은 상대적으로 간단합니다. LLM의 기능을 사용하여 가능한 답변(일명 원시 콘텐츠 청크)을 가상 질문으로 다시 맥락화함으로써 풍부하게 만들 수 있습니다. 그런 다음 후속 검색을 위해 이러한 가상 질문을 벡터 데이터베이스에 색인화합니다. 이라고 불리는 이 기술은 가설 문서 임베딩(HyDE) 에서는 LLM을 사용하여 문서 처리 파이프라인 내에서 데이터를 강화하는 기능을 보여줍니다. 다음은 잘 알려진 콘텐츠의 일부 콘텐츠에 이 기술을 사용하는 예입니다. squad_v2 데이터 세트 :

 System Prompt: Given the provided snippet of text, generate three hypothetical questions that could be asked about it. Each question must be able to be answered using the information within the referenced snippet of text and only that information. Be concise. User Prompt: “At the 52nd Annual Grammy Awards, Beyoncé received ten nominations, including Album of the Year for I Am... Sasha Fierce, Record of the Year for "Halo", and Song of the Year for "Single Ladies (Put a Ring on It)", among others. She tied with Lauryn Hill for most Grammy nominations in a single year by a female artist. In 2010, Beyoncé was featured on Lady Gaga's single "Telephone" and its music video. The song topped the US Pop Songs chart, becoming the sixth number-one for both Beyoncé and Gaga, tying them with Mariah Carey for most number-ones since the Nielsen Top 40 airplay chart launched in 1992. "Telephone" received a Grammy Award nomination for Best Pop Collaboration with Vocals.” Response: Here are some questions that could be asked based on the provided text: * How many nominations did Beyoncé receive at the 52nd Annual Grammy Awards? * For which album was Beyoncé nominated for Album of the Year at the 52nd Annual Grammy Awards? * Which song earned Beyoncé a nomination for Record of the Year at the 52nd Annual Grammy Awards?

긴 형식 및/또는 주제별로 복잡한 콘텐츠로 구성된 코퍼스로 작업하는 경우 추가 전처리를 수행하여 콘텐츠 청크를 사전 요약하여 의미 차원을 줄이는 것을 고려하세요. 검색 시 청크 요약의 임베딩을 쿼리한 다음 컨텍스트 창 삽입을 요약되지 않은 텍스트로 대체할 수 있습니다. 이 방법은 크고 복잡하며 자주 변경되는 말뭉치에 대해 RAG를 수행할 때 관련성을 높입니다.

토큰화

2024년의 대규모 언어 모델은 일반적으로 서면 단어를 기본적으로 이해하지 못하는 변환기 기반 신경망입니다. 들어오는 원시 텍스트는 토큰으로 변환된 후 행렬 곱셈 작업에 최적화된 고차원 임베딩 벡터로 변환됩니다. 이 인바운드 프로세스를 일반적으로 인코딩이라고 합니다. 반전된 아웃바운드 프로세스를 디코딩이라고 합니다. 많은 LLM은 교육을 받은 것과 동일한 토큰화 체계를 사용하여 추론에만 작동합니다. 따라서 선택한 토큰화 전략은 성능에 미묘한 영향을 미칠 수 있으므로 기본 사항을 이해하는 것이 중요합니다.

간단한 문자 및 단어 수준 토큰화 체계가 있지만 거의 모든 최신 LLM은 문서 작성 당시 하위 단어 토크나이저를 사용합니다. 따라서 여기서는 해당 토크나이저 범주에만 중점을 둘 것입니다.

하위 단어 토크나이저는 단어를 반복적으로 더 작은 단위로 나눕니다. 이를 통해 어휘 크기를 너무 많이 늘리지 않고도 어휘에 포함되지 않은 단어를 이해할 수 있습니다. 이는 훈련 성과와 보이지 않는 텍스트를 일반화하는 LLM의 능력에 대한 핵심 고려 사항입니다.

오늘날 널리 사용되는 하위 단어 토큰화 방법은 BPE(바이트 쌍 인코딩)입니다. 높은 수준에서 BPE 알고리즘은 다음과 같이 작동합니다.

• 단어를 하위 단어 단위의 토큰으로 분할하고 이를 어휘에 추가합니다. 각 토큰은 훈련 자료 내 공통 인접 문자 패턴의 상대적 빈도에 의해 제어되는 하위 단어를 나타냅니다.

  
  

• 위 단계의 공통 토큰 쌍을 해당 쌍을 나타내는 단일 토큰으로 바꾸고 이를 어휘에 추가합니다.

  
  

• 위의 단계를 재귀적으로 반복합니다.

  
  

BPE 토큰화는 일반적으로 많은 사용 사례에 적합하므로 RAG 애플리케이션을 시작하기에 좋은 장소입니다. 그러나 선택한 모델에 사용된 사전 학습 코퍼스의 어휘에는 잘 표현되지 않은 상당한 양의 고도로 전문화된 도메인 언어가 있다고 가정해 보겠습니다. 이 경우 대체 토큰화 방법을 연구하거나 이 기사의 범위를 벗어나는 미세 조정 및 낮은 순위 적응을 탐색하는 것을 고려하십시오. 앞서 언급한 제한된 어휘 문제는 의학, 법률 또는 모호한 프로그래밍 언어와 같은 전문 도메인용으로 구축된 애플리케이션에서 성능 저하로 나타날 수 있습니다. 더 구체적으로 말하면 고도로 전문화된 언어/전문 용어를 포함하는 프롬프트에서 널리 사용됩니다. 데이터 레이크에 저장된 평가 데이터 세트를 사용하여 필요에 따라 다양한 모델을 통해 다양한 토큰화 체계와 해당 성능을 실험해 보세요. 토크나이저, 임베딩 및 언어 모델은 종종 밀접하게 결합되어 있으므로 하나를 변경하면 다른 것도 변경해야 할 수도 있습니다.

결론

MinIO 객체 저장소 위에 구축된 최신 데이터 레이크는 RAG 기반 애플리케이션을 프로덕션에 자신 있게 도입하기 위한 기본 인프라를 제공합니다. 이를 통해 데이터 레이크 테이블 내에 저장하고 버전을 관리할 수 있는 평가 및 도메인별 평가 데이터 세트를 생성할 수 있습니다. 이러한 평가를 사용하여 RAG 애플리케이션 문서 파이프라인의 각 구성 요소(추출기, 청커, 강화 및 토크나이저)를 프로덕션 수준의 문서 처리 파이프라인을 구축하는 데 필요한 만큼 반복적으로 평가하고 점진적으로 개선합니다.

궁금한 점이 있으면 다음 연락처로 문의해 주세요. 느슨하게 !