Slide 1. 프리뷰

한 줄 설명

실행 중인 LUMI FastAPI와 내부 service surface를 실제로 두드려, 질문 실행 -> 채점 -> 비교 분석 -> 보고서 생성까지 분리한 모델 평가 워크스페이스

핵심 메시지

LGEA는 챗봇 기능을 하나 더 붙인 프로젝트가 아니라, 서비스가 어떤 질문에서 어떻게 무너지는지 반복 가능하게 확인하는 평가 체계입니다.

내 역할 요약

• LUMI와 분리된 평가 워크스페이스 구조 정리
• FastAPI와 router / response-layer / rag / tool surface 교차 실행 흐름 설계
• runner -> judge -> analysis -> reports 파이프라인 정리
• 결과 JSONL, 통계 요약, 보고서 묶음, repetition plan까지 남기는 자산 구조 설계

Slide 2. 왜 LGEA가 따로 필요했는가

문제

LUMI를 서비스로 운영하는 것과, 그 서비스가 어떤 질문에서 어떤 표면에서 약해지는지 평가하는 것은 다른 일입니다. 서비스 코드 안에 평가 로직을 섞으면 재현성이 깨지고, 응답을 한 번 확인한 뒤 끝나는 식의 테스트로 남기 쉽습니다.

해결하지 않으면 생기는 결과

• 같은 질문을 다시 돌려도 이전 실험과 비교하기 어렵습니다.
• FastAPI 최종 응답과 내부 router, response-layer, rag, tool 표면의 차이를 확인하기 어렵습니다.
• 모델 안전성이나 guardrail erosion을 말해도 근거 파일이 남지 않습니다.

flowchart LR
    A[서비스 운영 코드만 존재] --> B[평가 로직이 산발적으로 섞임]
    B --> C[같은 조건 재실행 어려움]
    C --> D[표면별 응답 차이 추적 어려움]
    D --> E[가드레일 평가 근거 약화]