문서 RAG 관리 시스템에 대한 개발 경험

1. 영수증 RAG에 대한 사항
- 영수증은 그 자체로 메타데이터 이므로 세부항목을 제외한 사항이 모두 라벨링 대상이 된다.
- 따라서, 영수증에 대한 복합 질의에도 오류율이 적은 편이다.
- 여기서 오류율은 A 장소에 결재한 카드의 합계 또는 동일 상호 다른 지점의 예이다.
- 결론적으로 영수증에 대한 추출만 잘 이루어 지면 이슈가 없으며,
      AZURE DOCUMENT INTELLIGENCE를 사용해본바, 추출 품질은 훌륭하며 영수증마다 추출은 개별 커스텀이므로 상당한 노가다가 필요함.

2. PDF 포함 OFFICE 문서에 대한 사항
- PDF 같은 경우 문서 자체에서 메타 정보를 추출할 수 없으며, 파일명에 정리되어 있는 수준 - "(작성:XXX, 작성년:XXXX) 2024년 복지개정안.pdf" 같은 - 이라면 가능하나
  목표로 하는 RAG 기능이 작성자 및 작성년, 각종 문서별 분류(복지, 인사, 보안 등등...)별 질의에 응답해야 할 경우
  이에 맞는 메타정보가 입력되어야만 정확한 응답이 가능한다.
- 즉, 문서 RAG 관련 메타데이터의 추출 또는 입력 행위가 원문서에 대한 라벨링(메타데이터 태깅)이 되므로
  기능 구현시 해당 기능에 대한 고려가 꼭 필요하다.   
    - 시중에 일부  문서 RAG 관련 솔루션들은 이러한 메타데이터 태깅을 사용자에게 일임하여 처리하게 하고 있다.
- 따라서 엔터프라이즈 시나리오에서는
- 라벨링된 문서내에서 전체 검색이 전제가 된다.
- 사용자 입력에 따라 라벨링 데이터에 맞게 키워드 및 필터 검색 추출이 우선이 된다.
- 기본적 RAG 에서는 검색은 Vector Search를 이용하고
- 세부 문서에 대한 청크를 이용하여 LLM 질의를 하게 된다.

 

* 결론 : RAG 는 AI 검색만으로도 충분히 구현 가능 하지만 어떤 원인에 따라 어떤 결과가 도출되는 알 수 없으므로, 즉, 원본 데이터가 LLM에서 어떻게 해석되는지 관찰할 수 없다면 좋지 않은 개발 경험이 될 것 같다. LLM 결과에 대한 도출이 어떻게 되는지, 내가 작성한 프롬프트가 어떤 식으로 해석되어지는지 관찰 할 수 있다면 더 좋은 개발 경험을 할 수 있을 것 같다.