이번 프로젝트의 목표

• 지금까지 학습하신 자연어처리 및 LLM 지식들을 토대로, RAG 시스템을 구축하여 복잡한 형태의 기업 및 정부 제안요청서(RFP) 내용을 효과적으로 추출하고 요약하여 필요한 정보를 제공하는 서비스를 만들어봅시다.

• 여러분들을 **B2G 입찰지원 전문 컨설팅 스타트업 – ‘입찰메이트’**의 엔지니어링 팀이라고 가정해 볼게요.

  • ‘입찰메이트’는 공공입찰 컨설팅 서비스를 제공하는 스타트업입니다.
  • 하루 수백건의 RFP(제안요청서)가 나라장터 등에서 올라오게 되는데, 한 요청서당 수십 페이지가 넘는 걸 기업 담당자들이 일일이 다 읽어볼 순 없겠죠. ‘입찰메이트’는 쏟아져나오는 요청서 가운데서 고객사에게 딱 알맞는 입찰 기회를 빠르게 찾아 고객사에게 추천하는 비즈니스를 하고 있습니다. 따라서 ‘입찰메이트’의 컨설턴트들은 RFP의 주요 요구 조건, 대상 기관, 예산, 제출 방식 등 중요한 정보를 핵심만 빠르게 파악한 뒤, 고객사들에게 추천하여 컨설팅까지 이어질 수 있는 기회를 만들어야합니다.
  • ‘입찰메이트’의 엔지니어링 팀은 사용자의 요청에 따라 RFP 문서의 내용을 효과적으로 추출하고 요약하여 필요한 정보를 제공할 수 있는 사내 RAG 시스템을 구현하는 미션을 부여 받았습니다. 그렇게 되면 ‘입찰메이트’의 컨설턴트들이 수십 페이지가 넘어가는 제안서를 일일이 들여다볼 일은 없어지고, 컨설팅 업무에 최대한 집중할 수 있겠네요.

• 여러분들은 100개의 실제 RFP 문서와 각각의 메타데이터를 제공받을 예정입니다. 다양한 자연어 처리 모델들로 실험하여 해당 문서들의 내용을 바탕으로 Q&A를 할 수 있는 시스템을 구축해보세요. 그리고 평가 방식이나 지표를 팀 별로 직접 선정하여 성능을 평가해보세요. 여러가지 의사 결정 과정이 모두 보고서와 발표에 드러나야 합니다.

지금까지 해왔던 것

1. 데이터 분석

1. 데이터 분석

   

   공고 번호, 공고 차수, 사업명, 사업 금액, 발주 기관, 공개 일자, 입찰 참여 시작일, 입찰 참여 마감일, 사업 요약, 파일형식, 파일명, 텍스트가 data_list.csv 파일에 있었다.

   

   혹시 해서 비어있는 리스트를 확인해보니 공고 번호, 공고 차수, 사업 금액, 입찰 참여 시작일, 입찰 참여 마감일이 비어 있는 곳이 있었다.

2. 데이터 빈 부분 채워넣을 방법 나라장터 기반 openapi를 사용해 채우는 것이 1차 목표

   

   현재 그 방법을 사용하기에 너무 신경 쓸 부분이 많음

   • 수 많은 데이터 중 내가 원하는 데이터가 어디에 있는지를 어떻게 확인할 수 있는가
   • 그것을 자동으로 하려면 어떤 구조로 만들어야 하는가
   • 해당 api는 남에게 공유할 수 있는가
   • api 기반으로 출력하면 그것을 잘 정렬해서 제작할 수 있는가

   

   우선 기본으로 매뉴얼을 수동으로 설정해 채워넣는 방식으로 설정

3. 확장자 및 라이브러리 선택

   기존 데이터는 hwp 파일 96개, pdf 파일 4개로 이루어져 있다.

   이를 결정하기 위해 여러 시도를 감행했다.

   1. HTML 형식으로 변환하는 방식을 시도

      

      

      해당 방식은 변환 속도가 오래 걸리는 문제 발생

   2. 원본 파일을 그대로 사용하는 방식

      hwp 파일의 경우 텍스트 추출이 원활하지 않은 문제가 생김

   3. pdf 형식으로 변환하여 사용하는 방식

      pdf 형식은 비교적 텍스트 추출이 안정적이며, 처리 과정의 일관성을 유지할 수 있다고 판단

      

2. 가상환경 설정

1. 주피터허브를 연결 후 사용

   

   주피터 사용을 확인하기 위해 한글화, 다크모드, 편의성 개선 등을 사용해봤지만, 이 서버를 변형할 수 있는 것은 할 수 없으므로 우선 어떻게 할지 생각 후, 이를 어떻게 연결할지 고민했다.

   그 중 다크모드는 선택할 수 있었지만, 한글 패치나 편의성의 경우 주어진 권리가 없어서 크게 건드릴 수 없었다.

2. 깃허브 연결

   

   각자의 아카이브 파일을 만들어 불러온 후 필요한 데이터를 넣기로 결정

   

   각자 브랜치를 만들어 데이터 분석 및 전체적인 구조를 한 번씩 만들어 더 좋은 성능을 지닌 것으로 결정하기 위해 각자 RAG를 만들어 생성하려 구조를 짰다.

3. 깃허브에 여러 설정 확인

   깃허브를 다루는 방법이 서툴러 기본적인 명령어 및 깃푸시/풀 등을 공부, 그리고 주피터허브와 깃허브, 로컬 데이터를 연결하기 위해 어떤 데이터가 있는지 공부했다.

   로컬 데이터를 연결하는 것은 힘들었지만, 주피터허브와 깃허브를 연결해 전체적인 구동을 쉽게 할 수 있었다.

3. 전체적인 RAG 구조 중 시도해본 것

1. doc 구조로 변경

   전체 구성을 doc_id, 텍스트, 메타데이터 순으로 넣었으며, 메타데이터 내에는 사진 내 내용만 넣었다.

   

   doc_id는 공고 번호와 공고 차수를 합쳐 생성, 텍스트는 추출된 텍스트를 넣었다.

   doc 구조를 사용한 이유 : 청킹은 텍스트로 나누고 고유 id 값과 메타데이터는 유지되기 때문

2. 청크 단위

   페이지 단위, 섹션 단위 등 다양한 단위를 나눴지만, 그 중 제일 좋은 성능을 보여줄 수 있었던 것은 토큰 단위 청킹이다.

   사용하지 못한 이유

   • 페이지 : 정확한 정답을 불러올 가능성이 적음
   • 섹션 : 섹션을 나누는 기준이 모호함, 청크 사이즈가 과하게 커질 경향이 있음

3. 프롬프트 작성

   다양한 프롬프트를 작성해 성능을 올리려 했다.

   1. 셀프체크 프롬프트

      생성에서 셀프체크를 통해 다시 확인하는 프롬프트

      사용하지 않은 이유 : 시간이 오래 걸릴 뿐더러 오히려 성능이 떨어지는 경우 발생

   2. 리랭킹 프롬프트

      Grader 이후 생성된 문서에 점수를 부여하는 프롬프트

      

      사용하지 않은 이유 : 시간이 오래 걸리는 것에 비해 성능이 크게 오르지 않아서

4. 질문 리스트/GT

   전체적인 질문/답변 리스트 생성

   해당 질문은 RAGAS 스코어를 측정하기 위해 생성