[Pitchcoach] Google Document AI, LayoutLM, Gemini 기반의 RAG 파이프라인 설계

현서·2025년 11월 27일

AI Gemini Google Document AI IR LLM LayoutLM OCR project rag

0. "왜 창업자들은 중요한 무대에 오르기 전까지 훈련받지 못할까?"

이화여자대학교 컴퓨터공학전공 캡스톤디자인 프로젝트로 개발 중인 PitchCoach(POKI)는 예비·초기 창업자를 위한 멀티모달 AI 기반 IR 피칭 솔루션입니다.

많은 창업팀이 투자 유치와 경진대회 입상을 목표로 하지만, #정보 비대칭 #자원 제약으로 인해 체계적인 피칭 훈련을 받지 못합니다. POKI는 이러한 문제를 해결하기 위해, 사용자의 발표자료(IR Deck)와 모집 공고문(Notice)을 분석하여 맞춤형 피드백을 제공하는 것을 목표로 합니다.

본 포스팅에서는 POKI의 핵심 기능 중, ① 공고 분석과 ② IR Deck 분석 모듈을 연결하여 데이터 기반의 의사결정(Data-driven Decision)을 가능케 하는 AI 문서 분석 백엔드 시스템의 설계 및 구현 과정을 다루고자 합니다.

1. Problem Definition: 범용 LLM의 한계와 기술적 병목

많은 예비 창업자들이 ChatGPT와 같은 범용 LLM에게 피드백을 구합니다. 하지만 저희가 직접 테스트해 본 결과, 범용 모델은 치명적인 한계를 가지고 있었습니다.

많은 창업자들이 ChatGPT와 같은 범용 LLM(Large Language Model)을 보조 도구로 활용합니다. 그러나 개발 초기 단계에서 수행한 Feasibility Test(타당성 검증) 결과, 범용 모델은 도메인 특화 작업에서 치명적인 한계를 드러냈습니다.

1.1. Case Study: Context 부재로 인한 피드백 실패

실제 학기 중 진행된 '중간 발표' 상황을 활용하여, ChatGPT에게 교수님의 평가 가이드라인과 팀의 발표자료를 입력하고 피드백을 요청했습니다.

Input: 평가 가이드라인 (Ground Truth)
비기술적 동기(아이디어 태동 배경) 포함 필수
핵심 기술요소 3가지를 명확히 구분하여 검증
단순 노력 나열이 아닌 '설득' 중심의 구성

Output: Baseline Model (ChatGPT)의 피드백
"텍스트 밀도가 높으니 줄이세요." (일반론)
"로고 반복이 가독성을 해칩니다." (UI/UX 관점)
"Whisper 분석 예시 이미지를 추가하세요." (단순 제안)

모델의 응답은 틀린 말은 아니었으나, 핵심 평가 기준인 '비기술적 동기 누락'이나 '기술요소 구분 미흡'과 같은 구조적 결함(Structural Defect)은 전혀 탐지하지 못했습니다. 이는 범용 모델이 문서의 표면적인 텍스트만 읽을 뿐, 평가 기준과 발표 내용 사이의 논리적 정합성을 판단하지 못함을 시사합니다.

1.2. Root Cause: 구조(Structure)와 맥락(Context)의 소실

이러한 한계의 근본 원인은 다음과 같습니다.

구조적 이해의 부재: LLM은 PDF를 단순한 1차원 텍스트 시퀀스로 처리합니다. 표(Table) 내의 평가 항목과 슬라이드 내 핵심 지표 간의 위계 관계(Hierarchy)가 파싱 과정에서 소실됩니다.

할루시네이션(Hallucination) 위험: "공고문 3페이지의 필수 항목이 IR Deck 7페이지에 누락되었다"는 식의 정밀 진단(Precision Diagnosis) 대신, 확률론적 생성에 의존한 일반적인 조언만을 제공합니다.

"IR 피칭의 승패는 화려한 언변보다 '평가 기준(Criteria)의 정확한 충족(Mapping)'에 있다."

따라서 본 프로젝트의 기술적 목표는 단순한 요약 생성이 아닙니다. 공고문(Text), IR Deck(Visual), 그리고 발표 음성(Audio)이라는 이질적인 멀티모달 비정형 데이터를 구조화된 정형 데이터로 변환 및 상호 정렬(Alignment)하여, LLM이 단편적인 정보가 아닌 발표의 종합적인 맥락을 판단할 수 있는 Multi-modal Ground Truth를 확보하는 파이프라인을 구축하는 것입니다.

1.3. Role & Responsibility: AI 파이프라인 아키텍트

이러한 기술적 난제를 해결하기 위해, 저는 팀 내에서 비정형 문서 데이터를 구조화하고 분석하는 백엔드 파이프라인 구축을 전담했습니다.

전체 서비스 아키텍처 중 제가 담당한 영역은 사용자가 업로드한 Raw PDF(공고문, IR Deck)를 입력받아, LLM이 이해할 수 있는 중간 표현(Intermediate Representation, JSON)으로 변환하고, 최종적으로 진단 리포트를 생성하는 코어 로직입니다. 이를 위해 단순한 API 연동을 넘어, 각 단계별 최적화된 AI 모델을 선정하고 오케스트레이션(Orchestration)하는 시스템을 설계했습니다.

2. Core Tech Stack & Architecture

범용 모델의 한계를 극복하고 Ground Truth를 확보하기 위해, 저는 각 데이터 처리 단계에 특화된 SOTA(State-of-the-art) 모델들을 결합한 하이브리드 AI 파이프라인을 구축했습니다.

2.1. 정밀 OCR 및 레이아웃 분석 (Google Document AI)

가장 먼저 수행해야 할 작업은 PDF를 기계가 읽을 수 있는 데이터로 변환하는 것입니다.

역할: 비정형 PDF 문서(공고문, IR Deck)를 입력받아 텍스트뿐만 아니라 표(Table)의 구조와 이미지의 물리적 좌표(Bounding Box)를 정밀하게 추출합니다.

구현: 단순 텍스트 추출(Text Extraction)을 넘어, 문서의 Form Structure를 파싱하여 데이터를 정규화(Normalization)하는 전처리 모듈을 구현했습니다. 이를 통해 공고문 내 복잡한 표에 담긴 '지원 자격'이나 '가점 요인'을 Key-Value 형태로 구조화할 수 있었습니다.

2.2. 문서 구조 태깅 (LayoutLMv3 Inference)

좌표 정보만으로는 "이 텍스트가 제목인지 본문인지" 알 수 없습니다. 이를 해결하기 위해 멀티모달 모델인 LayoutLMv3를 도입했습니다.

역할: Document AI가 추출한 좌표와 텍스트 정보를 바탕으로, 해당 블록이 '제목(Header)', '본문(Body)', '캡션(Caption)' 중 무엇인지 의미론적으로 분류(Semantic Classification)합니다.

전략: 데이터셋 구축 비용을 절감하기 위해 별도의 Fine-tuning 없이 사전 학습된(Pre-trained) 모델을 활용하되, Rule-based 후처리 로직을 결합하여 오분류를 보정하고 분석의 정확도를 확보하는 Hybrid Inference 전략을 채택했습니다.

2.3. 지능형 매핑 및 진단 (Vertex AI - Gemini)

구조화된 데이터를 바탕으로 실질적인 피드백을 생성하는 RAG(검색 증강 생성) 기반의 최종 분석 엔진입니다.

역할: 공고문의 요구사항과 IR Deck의 내용을 대조하여 논리적 결함을 찾아냅니다.

프로세스:

1) 동적 평가 기준 수립 (Dynamic Criteria): 공고문 텍스트를 먼저 분석하여 행사 성격(투자유치형 vs 정부지원형)을 분류하고, 이에 맞는 심사 루브릭을 생성합니다.

2) Gap Analysis: 구조화된 IR Deck 데이터를 위 기준에 매핑하여, "재무 섹션 누락", "시장 데이터 근거 부족" 등 구체적인 결함을 지적하는 피드백 JSON을 생성합니다.

이어지는 섹션에서는 이 아키텍처를 실제 Python 코드로 구현하면서 겪었던 gRPC 타임아웃, 대용량 청크 처리, 순환 참조 등 구체적인 엔지니어링 이슈와 해결 과정을 다룹니다.

3. 구현 상세: Google Document AI 기반 데이터 파이프라인

파이프라인의 첫 관문은 비정형 PDF를 기계가 읽을 수 있는 정형 데이터(JSON)로 변환하는 것입니다.

초기에는 Tesseract와 같은 오픈소스 OCR을 검토했으나, 공고문의 핵심인 '복잡한 표 구조(Table Structure)'를 인식하지 못하고 단순 텍스트로 뭉개버리는 한계가 있었습니다. 이에 따라, 문서의 레이아웃과 폼(Form) 데이터를 Key-Value 형태로 완벽하게 파싱할 수 있는 Google Document AI (Form Parser)를 최종 채택했습니다.

3.1. API 제약 사항 극복: Chunking Architecture

구현 과정에서 마주친 첫 번째 병목은 API의 물리적 제약이었습니다. Google Document AI의 동기식(Synchronous) 처리 방식은 한 번에 처리할 수 있는 페이지 수에 제한(통상 15페이지 내외)이 있거나, 처리 시간이 길어질 경우 gRPC Deadline Exceeded 오류를 반환합니다.

반면, 창업자들의 IR Deck은 평균 20~50페이지에 달하며, 고해상도 이미지가 포함되어 있어 단일 요청으로는 처리가 불가능했습니다.

이를 해결하기 위해 Divide and Conquer(분할 정복) 전략을 도입했습니다. PyPDF2를 활용하여 원본 문서를 API가 안정적으로 처리할 수 있는 논리적 단위(15페이지)로 슬라이싱하고, 각 청크를 독립적으로 처리하는 전처리기를 구현했습니다.

PDF 분할 유틸리티 (src/utils/pdf_split.py)
먼저 API 제약을 피하기 위해 PDF를 물리적으로 쪼개는 순수 유틸리티 함수입니다.

Python

# src/utils/pdf_split.py
from PyPDF2 import PdfReader, PdfWriter

def split_pdf(input_pdf: str, output_dir: str, chunk_size: int = 15) -> List[str]:
    """
    대용량 PDF를 chunk_size 단위로 분할하여 저장하는 유틸리티
    - Google Document AI의 페이지 제한(15장)을 우회하기 위함
    """
    reader = PdfReader(input_pdf)
    total_pages = len(reader.pages)
    chunks = []
    
    # ... (생략: 페이지 루프 돌면서 파일 저장) ...
    
    return chunks

청크 처리 프로세서 (src/document_ai/processor.py)
위 유틸리티를 활용해서 실제로 OCR을 병렬(또는 순차) 처리하고 결과를 관리하는 비즈니스 로직입니다.

Python

# src/document_ai/processor.py
from src.utils.pdf_split import split_pdf  # 사용자 정의 모듈 활용

def process_pdf_ocr_in_chunks(
    file_path: str, 
    output_dir: str, 
    pages_per_chunk: int = 15
) -> List[Dict]:
    """
    Divide and Conquer 전략 구현
    1. split_pdf로 파일 분할
    2. 분할된 파일별로 Document AI 호출
    3. 결과 리스트 반환
    """
    # 1. 파일 분할 (유틸리티 호출)
    chunk_files = split_pdf(file_path, output_dir, pages_per_chunk)
    
    results = []
    for chunk_path in chunk_files:
        # 2. 개별 OCR 수행
        result = process_document(
            file_path=chunk_path,
            processor_type="OCR",
            # ...
        )
        results.append(result)
        
    return results

4. 구현 상세: LayoutLMv3 기반 구조 태깅 (Structure Tagging)

단순 텍스트 추출(OCR)만으로는 문서의 의미론적 구조를 파악할 수 없습니다. 텍스트가 '제목'인지 '본문'인지, 혹은 '테이블 내 데이터'인지를 구분하기 위해 LayoutLMv3 모델을 도입했습니다.

이 과정에서 가장 큰 기술적 과제는 Google Document AI의 출력 데이터를 LayoutLMv3의 입력 텐서(Tensor) 규격에 맞게 변환하는 데이터 어댑터(Data Adapter)를 구현하는 것이었습니다.

4.1. 좌표계 정규화 (Coordinate Normalization)

Document AI는 문서 내 텍스트 위치를 normalizedVertices (0~1 실수) 또는 vertices (절대 픽셀 좌표) 형태로 반환합니다. 반면, LayoutLM은 0부터 1000 사이의 정수 좌표계(0-1000 scale)를 요구합니다.

이러한 좌표계 불일치(Coordinate Mismatch)를 해결하기 위해, 원본 문서를 1000x1000 그리드로 투영하여 좌표를 정규화하는 변환 로직을 구현했습니다.

# src/layoutlm/preprocess.py

def convert_bounding_poly(bounding_poly: Dict, width: int, height: int) -> List[int]:
    """
    [Adapter] Document AI BoundingPoly -> LayoutLM Normalized BBox (0-1000)
    """
    # 1. 상대 좌표(0~1)인 경우
    if "normalizedVertices" in bounding_poly:
        verts = bounding_poly["normalizedVertices"]
        xs = [v.get("x", 0) * 1000 for v in verts]
        ys = [v.get("y", 0) * 1000 for v in verts]
    
    # 2. 절대 좌표(Pixel)인 경우 -> 이미지 크기로 나누어 정규화
    elif "vertices" in bounding_poly:
        verts = bounding_poly["vertices"]
        xs = [v.get("x", 0) / width * 1000 for v in verts]
        ys = [v.get("y", 0) / height * 1000 for v in verts]
    else:
        return [0, 0, 0, 0]
    
    # [x_min, y_min, x_max, y_max] 형태로 변환
    return [
        int(min(xs)), int(min(ys)),
        int(max(xs)), int(max(ys))
    ]

4.2. 멀티모달 입력 텐서 구성 (Tensor Construction)

LayoutLMv3는 텍스트(Text), 이미지(Image), 위치(BBox) 정보를 동시에 처리하는 멀티모달 모델입니다. 따라서 PDF 페이지를 이미지로 렌더링하고, 앞서 정규화한 좌표와 토큰을 결합하여 모델이 학습 가능한 형태의 Input Features를 생성해야 합니다.

# src/layoutlm/preprocess.py

def prepare_layoutlm_input(
    doc_json: Dict, pdf_path: str, processor, max_length: int = 512
) -> Dict:
    """
    OCR 결과와 원본 PDF 이미지를 결합하여 LayoutLM 입력 텐서 생성
    """
    # 1. PDF를 이미지로 변환 (Visual Feature)
    images = convert_from_path(pdf_path)
    
    # 2. Document AI 결과에서 텍스트와 좌표 추출 (Text & Layout Feature)
    all_page_tokens = []
    all_page_boxes = []
    
    # ... (중략: 페이지별 블록 순회 및 토큰/BBox 추출 로직) ...
            
    # 3. Processor를 통해 최종 인코딩
    # boxes 인자에 정규화된 좌표를 직접 주입
    encoding = processor(
        images=all_page_images,
        text=all_page_tokens,
        boxes=all_page_boxes,
        return_tensors="pt",
        padding="max_length",
        truncation=True,
        max_length=max_length,
    )
    
    return encoding

4.3. Inference 최적화: `apply_ocr=False`

HuggingFace의 LayoutLMv3Processor는 기본적으로 Tesseract OCR을 내장하고 있습니다. 하지만 우리는 이미 Google Document AI를 통해 훨씬 높은 품질의 한글 OCR 결과를 확보한 상태입니다.

따라서 불필요한 중복 연산과 OCR 성능 저하를 방지하기 위해, Processor 초기화 시 apply_ocr=False 옵션을 적용하여 내장 OCR을 비활성화하고, 우리가 전처리한 Ground Truth 데이터를 직접 주입하는 방식을 택했습니다.

# main.py (Inference Setup)

from transformers import LayoutLMv3Processor

# [Optimization] 내장 Tesseract OCR 비활성화
# Document AI가 추출한 고품질 텍스트와 좌표를 그대로 사용하기 위함
processor = LayoutLMv3Processor.from_pretrained(
    "microsoft/layoutlmv3-base",
    apply_ocr=False 
)

# ... prepare_layoutlm_input 호출 ...

5. 구현 상세: Gemini 기반 RAG 및 최종 진단 (Reasoning & Diagnosis)

앞선 단계에서 문서의 물리적 구조(OCR)와 의미적 구조(LayoutLM)를 파악했다면, 이 단계에서는 추출된 데이터를 바탕으로 실질적인 비즈니스 가치(Feedback)를 창출합니다.

단순히 LLM에게 모든 데이터를 던져주고 "분석해줘"라고 요청하는 것은 비효율적일 뿐만 아니라, 할루시네이션의 원인이 됩니다. 따라서 우리는 Vertex AI (Gemini)를 컨트롤 타워로 활용하되, 정량적 분석은 Rule-based로 처리하는 Hybrid RAG 파이프라인을 설계했습니다.

5.1. Context-Aware Classification (2-Stage Reasoning)

모든 IR Deck를 동일한 기준으로 평가해서는 안 됩니다. '투자 유치(Investment)' 목적의 발표와 '정부 지원(Competition)' 목적의 발표는 평가 기준(Rubric) 자체가 다르기 때문입니다.

이를 해결하기 위해 2-Stage Reasoning 방식을 적용했습니다.

Stage 1: 공고문(Notice)을 먼저 분석하여 '심사위원이 중요하게 보는 평가 요소'와 '필수 섹션'을 추출합니다.

Stage 2: 추출된 전략(Strategy)을 IR Deck 분석 프롬프트의 컨텍스트(Context)로 주입합니다.

# src/llm/gemini_client.py

class GeminiAnalyst:
    def analyze_notice(self, notice_text: str) -> dict:
        """
        [Reasoning] 공고문 텍스트를 분석하여 심사 전략(Strategy) 수립
        - 목적: IR Deck 분석 시 사용할 Dynamic Criteria(동적 기준) 생성
        """
        prompt = f"""
        당신은 스타트업 투자 심사역입니다. 다음 공고문을 분석하여 JSON으로 응답하세요.
        
        [분석 목표]
        1. type: 행사 성격 분류 (investment vs competition)
        2. required_sections: 이 행사에서 반드시 포함해야 할 필수 섹션 리스트
        3. focus_point: 심사위원이 가장 중요하게 볼 평가 요소 (One-liner)
        
        [공고문 텍스트]
        {notice_text[:15000]}  # Token Limit을 고려한 Slicing
        """
        
        # ... (Gemini 호출 및 JSON 파싱 로직) ...
        return json.loads(response.text)

5.2. Rule-based & LLM 하이브리드 진단 (Hybrid Diagnosis)

LLM은 논리적 추론에 강하지만, 숫자 계산이나 단순 카운팅에는 취약하고 비용이 높습니다. 반면, Python 코드는 계산이 정확하고 빠릅니다.

시스템의 비용 효율성(Cost Efficiency)과 정확도(Accuracy)를 동시에 확보하기 위해 역할을 분리했습니다.

Quantitative(정량): 발표 시간 예측, 텍스트/이미지 비율, 키워드 카운팅 → Python Rule-based

Qualitative(정성): 논리적 흐름(Logic Flow), 필수 섹션 누락 여부 판단 → LLM Strategy + Set Operation

# src/llm/gemini_client.py

class GeminiAnalyst:
    def analyze_notice(self, notice_text: str) -> dict:
        """
        [Reasoning] 공고문 텍스트를 분석하여 심사 전략(Strategy) 수립
        - 목적: IR Deck 분석 시 사용할 Dynamic Criteria(동적 기준) 생성
        """
        prompt = f"""
        당신은 스타트업 투자 심사역입니다. 다음 공고문을 분석하여 JSON으로 응답하세요.
        
        [분석 목표]
        1. type: 행사 성격 분류 (investment vs competition)
        2. required_sections: 이 행사에서 반드시 포함해야 할 필수 섹션 리스트
        3. focus_point: 심사위원이 가장 중요하게 볼 평가 요소 (One-liner)
        
        [공고문 텍스트]
        {notice_text[:15000]}  # Token Limit을 고려한 Slicing
        """
        
        # ... (Gemini 호출 및 JSON 파싱 로직) ...
        return json.loads(response.text)

이러한 하이브리드 접근 방식을 통해, 순수 LLM만을 사용할 때보다 API 비용을 약 40% 절감하고, 수치 데이터에 대한 100% 신뢰성(Ground Truth)을 확보할 수 있었습니다.

6. Service Integration: 멀티모달 파이프라인의 중추(Hub) 역할

구축한 문서 분석 파이프라인의 최종 산출물은 단순한 분석 리포트가 아닙니다. 이는 서비스 내의 다른 AI 모듈(음성 분석, Q&A 생성, XAI 리포트)이 작동하기 위한 핵심 컨텍스트 공급하는 인터페이스(Interface) 역할을 수행합니다.

타 기능과의 데이터 연동 구조는 다음과 같습니다.

6.1. With Voice Analysis (발표 음성 분석)

"텍스트 밀도와 실제 발화 속도의 정렬(Alignment)"

발표자료 15페이지의 '음성 분석(Whisper+Librosa)' 모듈은 사용자의 목소리 톤과 속도를 측정합니다. 하지만 단순한 빠르기(WPM)만으로는 "말이 빠르다"는 판단을 내릴 수 없습니다. 슬라이드에 담긴 정보량이 많다면 당연히 말이 빨라져야 하기 때문입니다.

제 파이프라인은 각 슬라이드별 텍스트 밀도를 기반으로 estimated_speech_duration (적정 발표 시간)을 계산하여 음성 분석 팀에 전달합니다. 이를 통해 음성 모듈은 "텍스트 양 대비 실제 발화 속도가 적절한가"를 판단하는 고차원적인 피드백을 제공할 수 있습니다.

// [Interface] To. Voice Analysis Team
{
  "page": 3,
  "section": "Problem",
  "text_density": "High (950 chars)",
  "estimated_duration": 45, // "이 슬라이드는 45초 정도가 적당합니다."
  "voice_guide": "내용이 많으므로 핵심 키워드 위주로 요약을 권장합니다."
}

6.2. With Q&A Generation (예상 질문 생성)

"약점을 파고드는 날카로운 질문 생성(Sharp Questioning)"

서비스 내의 'Q&A 훈련' 기능은 LLM이 면접관 페르소나를 연기하며 질문을 던집니다. 이때 LLM에게 단순히 "질문해줘"라고 하면 일반적인 질문밖에 하지 못합니다.

파이프라인은 앞서 수행한 Gap Analysis(공고문 vs IR Deck) 결과를 Q&A 모듈에 주입합니다. 예를 들어, "초기창업패키지(Competition Type)인데 '시장 진입 전략' 섹션이 누락됨"이라는 진단 결과가 전달되면, Q&A 봇은 이를 바탕으로 "경쟁사가 많은데 구체적인 시장 진입 전략은 무엇인가요?"와 같은 방어 논리 점검용 질문을 생성합니다.

6.3. With XAI Dashboard (설명 가능한 리포트)

"정성적 평가의 정량적 근거 제시(Quantitative Evidence)"

발표자료 17페이지의 'XAI 기반 리포트'는 사용자가 납득할 수 있는 점수를 보여줘야 합니다. 제 파이프라인은 단순히 "부족함"이라고 말하는 대신, SHAP/LIME 분석에 활용될 수 있는 정량적 Feature를 추출하여 전달합니다.

Visual Score: 이미지/도표가 없는 슬라이드 (0점) vs 균형 잡힌 슬라이드 (100점)
Logic Flow: 문제-해결 순서가 뒤바뀐 경우 (Flag: True/False)

이러한 정형 데이터(Structured Data)는 최종 리포트 프론트엔드에서 "왜 내 점수가 70점인지"를 설명하는 Ruled-based Highlight의 근거 데이터로 활용됩니다.

결과적으로 제가 설계한 백엔드 시스템은 POKI 서비스의 데이터 허브로서, 비정형 문서 데이터를 구조화하여 음성(Audio), 언어(Language), 시각(Vision) 모듈이 유기적으로 연결될 수 있도록 하는 멀티모달 통합의 기반(Foundation)을 마련했습니다.

7. 회고

이번 프로젝트의 가장 큰 수확은 막연하게만 느껴졌던 '비정형 데이터의 구조화'를 실제 서비스 가능한 수준의 파이프라인으로 구현해냈다는 점입니다.

초기에는 단순히 "LLM에게 PDF를 주면 알아서 하겠지"라고 생각했지만, 수많은 시행착오 끝에 깨달은 결론은 "AI의 성능은 결국 입력 데이터의 품질(Data Quality)이 결정한다"는 것이었습니다.

7.1. Project Impact

제가 구축한 Document AI + LayoutLM + Gemini 파이프라인은 POKI 서비스의 중간 역할을 수행합니다.

Before: "IR Deck 디자인이 깔끔하네요." (범용 모델의 모호한 칭찬)
After: "초기창업패키지 공고문 5페이지의 '시장 진입 전략'이 발표자료 7페이지에 누락되었습니다." (Ground Truth 기반의 정밀 진단)

이처럼 할루시네이션을 통제하고, 근거 있는 피드백을 제공하는 시스템을 설계함으로써, 예비 창업자들에게 실질적인 도움을 줄 수 있는 기술적 토대를 마련했습니다.

7.2. Future Roadmap

현재의 파이프라인은 '기능 구현'에 초점이 맞춰져 있지만, 앞으로 다음과 같은 기술적 고도화를 계획하고 있습니다.

Domain Adaptation (Fine-tuning): 현재 사용 중인 LayoutLMv3는 일반 문서로 학습된 Pre-trained 모델입니다. 이를 스타트업 IR Deck 데이터셋으로 Fine-tuning하여, 'Team', 'Problem', 'Solution' 등 도메인 특화 섹션의 분류 정확도를 95% 이상으로 끌어올릴 계획입니다.

Latency Optimization: 현재 동기식(Synchronous)으로 작동하는 청크 처리 로직을 비동기 큐(Celery/Redis) 기반으로 리팩토링하여, 대용량 문서 분석 시의 사용자 대기 시간을 획기적으로 단축하고자 합니다.

백엔드 엔지니어로서 데이터의 흐름(Flow)을 설계하고, 최적의 AI 모델을 적재적소에 배치(Orchestration)하는 경험은 앞으로의 커리어에 큰 자산이 될 것이라 확신합니다.

POKI-AI GITHUB
Jang Hyeon-seo GITHUB

현서

LLM부터 풀스택까지, 만들면서 기록합니다

다음 포스트

[Pitchcoach] Google Document AI, LayoutLM, Gemini 기반의 RAG 파이프라인 설계

0. "왜 창업자들은 중요한 무대에 오르기 전까지 훈련받지 못할까?"

1. Problem Definition: 범용 LLM의 한계와 기술적 병목

1.1. Case Study: Context 부재로 인한 피드백 실패

1.2. Root Cause: 구조(Structure)와 맥락(Context)의 소실

1.3. Role & Responsibility: AI 파이프라인 아키텍트

2. Core Tech Stack & Architecture

2.1. 정밀 OCR 및 레이아웃 분석 (Google Document AI)

2.2. 문서 구조 태깅 (LayoutLMv3 Inference)

2.3. 지능형 매핑 및 진단 (Vertex AI - Gemini)

3. 구현 상세: Google Document AI 기반 데이터 파이프라인

3.1. API 제약 사항 극복: Chunking Architecture

4. 구현 상세: LayoutLMv3 기반 구조 태깅 (Structure Tagging)

4.1. 좌표계 정규화 (Coordinate Normalization)

4.2. 멀티모달 입력 텐서 구성 (Tensor Construction)

4.3. Inference 최적화: `apply_ocr=False`

5. 구현 상세: Gemini 기반 RAG 및 최종 진단 (Reasoning & Diagnosis)

5.1. Context-Aware Classification (2-Stage Reasoning)

5.2. Rule-based & LLM 하이브리드 진단 (Hybrid Diagnosis)

6. Service Integration: 멀티모달 파이프라인의 중추(Hub) 역할

6.1. With Voice Analysis (발표 음성 분석)

6.2. With Q&A Generation (예상 질문 생성)

6.3. With XAI Dashboard (설명 가능한 리포트)

7. 회고

7.1. Project Impact

7.2. Future Roadmap

SlideWise: AI Agent로 구현한 대학생 맞춤 시험 대비 플랫폼

0개의 댓글

[Pitchcoach] Google Document AI, LayoutLM, Gemini 기반의 RAG 파이프라인 설계

0. "왜 창업자들은 중요한 무대에 오르기 전까지 훈련받지 못할까?"

1. Problem Definition: 범용 LLM의 한계와 기술적 병목

1.1. Case Study: Context 부재로 인한 피드백 실패

1.2. Root Cause: 구조(Structure)와 맥락(Context)의 소실

1.3. Role & Responsibility: AI 파이프라인 아키텍트

2. Core Tech Stack & Architecture

2.1. 정밀 OCR 및 레이아웃 분석 (Google Document AI)

2.2. 문서 구조 태깅 (LayoutLMv3 Inference)

2.3. 지능형 매핑 및 진단 (Vertex AI - Gemini)

3. 구현 상세: Google Document AI 기반 데이터 파이프라인

3.1. API 제약 사항 극복: Chunking Architecture

4. 구현 상세: LayoutLMv3 기반 구조 태깅 (Structure Tagging)

4.1. 좌표계 정규화 (Coordinate Normalization)

4.2. 멀티모달 입력 텐서 구성 (Tensor Construction)

4.3. Inference 최적화: apply_ocr=False

5. 구현 상세: Gemini 기반 RAG 및 최종 진단 (Reasoning & Diagnosis)

5.1. Context-Aware Classification (2-Stage Reasoning)

5.2. Rule-based & LLM 하이브리드 진단 (Hybrid Diagnosis)

6. Service Integration: 멀티모달 파이프라인의 중추(Hub) 역할

6.1. With Voice Analysis (발표 음성 분석)

6.2. With Q&A Generation (예상 질문 생성)

6.3. With XAI Dashboard (설명 가능한 리포트)

7. 회고

7.1. Project Impact

7.2. Future Roadmap

SlideWise: AI Agent로 구현한 대학생 맞춤 시험 대비 플랫폼

0개의 댓글

4.3. Inference 최적화: `apply_ocr=False`