안녕하세요. 김태종입니다.

문제

• 프롬프트 버전 관리가 지나치게 복잡해, 지금 쓰이는 버전이 어떤 히스토리를 거쳐 배포됐는지 · 어떤 테스트를 통과했는지를 아무도 파악할 수 없음
• 프롬프트 수정에는 LLM 툴을 많이 쓰는데, 시트에서 복사해 지시하고 결과를 다시 붙여넣어 테스트하는 왕복 작업을 매번 반복해야 함
• 그렇게 붙여넣은 LLM은 변경 히스토리도 테스트 이력도 모르는 상태라 컨텍스트 없이 답할 수밖에 없어 개선 결과의 품질 자체가 떨어짐

방법

• DB화 — 시트에 흩어져 있던 프롬프트를 SQLAlchemy ORM + Alembic + PostgreSQL 기반 저장소로 이관해 버전·배포 상태·변경 이력을 한곳에서 관리
• 외부 연동 API 제공 — 변수(context)만 받아 LLM 호출·과금·DB 기록 없이 렌더링 결과만 돌려주는 드라이런 엔드포인트를 만들어, 어떤 프로그램에서든 같은 프롬프트를 가져다 쓸 수 있게 함
• 프롬프트 편집 MCP 서버 구축 — Claude Code에서 프롬프트를 직접 조회·수정·테스트하도록 만들어 복붙 왕복을 제거하고, LLM이 변경 히스토리와 테스트 이력을 컨텍스트로 갖고 작업하게 함
• git 형상관리 개념을 프롬프트에 적용 — 배포 버전 지정, 섹션 단위 diff 비교(외부 의존성 없이 LCS 직접 구현), 서로 다른 버전의 변경을 합치는 merge, 특정 버전의 개별 섹션만 골라 가져오는 cherry-picking, git branch tree 형태의 히스토리 시각화 구현
• 프롬프트 저장 표기를 프로덕션과 동일한 Handlebars로 전환(전처리기 직접 구현), 골든 스냅샷 75건 바이트 단위 동일 검증으로 표기 변경이 출력에 영향을 주지 않음을 입증
• 모델 관리도 같은 툴에 통합 — vLLM 프로바이더 라우팅 추가(미등록 모델 키가 OpenRouter로 조용히 폴백돼 엉뚱한 엔드포인트로 요청이 나가는 위험을 발견해 라우팅까지 함께 구현), per-model 엔드포인트·API key는 write-only 저장 후 카나리 시크릿 전수 검증으로 미노출 확인

결과

• 팀 전체가 신뢰할 수 있는 단일 프롬프트 소스 확보 — 어떤 버전이 어떤 이력을 거쳐 배포됐는지 추적 가능
• 프롬프트 개선을 MCP로 복붙 없이 즉시 수정·테스트할 수 있게 됐고, LLM이 히스토리를 컨텍스트로 갖게 되면서 제안 품질도 함께 상승
• 테스트 과정에서 시도한 아이디어까지 버전으로 남아, 당장 채택하지 않은 시도도 나중에 cherry-picking으로 손쉽게 되살릴 수 있게 됨
• AI팀 4인이 상시 사용하며 모델 10종·프롬프트 30개 버전을 관리. 프롬프트 수정·테스트에 걸리던 시간이 1시간 → 30분으로 단축되어 테스트를 더 자주 돌릴 수 있게 됨

사용 기술

FastAPIPostgreSQLSQLAlchemyAlembicMCPHandlebars/Jinja2React(Vite + TypeScript)

문제

• 자체 서빙 모델(Weave)은 상용 API와 달리 플랫폼 수준의 콘텐츠 필터가 없어, 미성년자 대상 성적 콘텐츠가 생성될 수 있음
• "생성하지 마시오" 수준의 단순 지시는 거의 무효 — Baseline F1 18.1%, Recall 10.0%
• 법적·윤리적 리스크 대응과 서비스 안정성 확보가 시급함

방법

• Fine-tuning은 학습 데이터 구축 비용이 크고 외부 분류기는 추가 인프라·지연이 필요해, 즉시 배포 가능하고 실험 사이클이 빠른 프롬프트 엔지니어링을 1차 접근법으로 선택
• 자기회귀 모델이 한 번 생성을 시작하면 관성으로 중단하지 못하는 점에 착안해 응답 생성 전에 분류를 강제하는 2-Step 출력 기법 고안 — ① Flag 분류(응답 첫 토큰으로 MINOR/ADULT/SAFE 강제 출력) ② Chain-of-Thought(캐릭터 나이 판정 → 프로필·입력의 성적 요소 확인 → 최종 판정 순서로 추론)
• baseline부터 v15까지 15회 반복 실험으로 검증. CoT 도입(v7)이 가장 큰 개선(F1 60% → 81%)이었고, CoT 추론 순서를 뒤집으면 F1이 24.3%p 하락함을 실측해 순서 설계의 중요성 확인
• 평가 데이터셋 직접 구축: 실서비스 데이터 499,397건을 규칙 기반 → gemma-4-26b → gemini-3.5-flash 3단계 파이프라인으로 필터링해 300건 테스트셋 구성. 실험 도중 데이터셋 자체의 라벨 오류를 발견해 전수조사로 42%(126건)를 교정한 뒤에야 정확한 성능 측정 가능
• 필터 적용이 출력 품질을 해치지 않는지 루브릭으로 검증하고, 실서비스에서 필터링된 사례 123건을 정오 분류(올바른 차단 87건 / 의문 36건)해 과잉 차단 패턴 3가지와 후속 개선 방향(감지·출력제어 분리, 소형 분류기 하이브리드) 도출

결과

• 미성년자 성적 콘텐츠 차단 F1 18.1% → 87.0% (Recall 10.0% → 84.7%, Precision 89.4% 유지, Accuracy 54.7% → 87.3%)
• 루브릭 점수 3.790 → 3.794로 출력 품질 저하가 없음을 확인하고, 양 서비스(Bubblechat·Tingle) QA 전원의 확인을 받은 뒤 배포
• 배포 후 콘텐츠 필터 관련 문의 접수 0건. CoT 추가에 따른 응답 지연은 3~5초로, 서비스에서 함께 쓰는 외부 모델(5~10초)보다 빨라 체감 영향 없음
• 실험 과정을 논문 형식("Think First, Flag Next")으로 정리해 사내 공유

사용 기술

Prompt EngineeringChain-of-ThoughtvLLMPythonGemini(데이터 검증)

문제

• 유저가 고품질 캐릭터 프롬프트를 직접 작성하기 어려워함
• 캐릭터·세계관·관계를 동시에 설계해야 하는데, 단일 에이전트로 처리하면 각 영역의 깊이가 얕아짐
• 프롬프트 변경이 품질에 미치는 영향을 측정할 수단이 없음

방법

• 아이디어(캐릭터 프롬프트 기획·작성) / JSX(캐릭터 상태창용 JSX 코드 생성) / 진단&압축(프롬프트 품질 진단 및 토큰 절약 압축) 3개 모드 아키텍처를 설계하고, 사용자 입력을 분석해 적합한 모드를 동적으로 판단·전환하는 커스텀 오케스트레이션 레이어 직접 구현
• 영역별 깊이 문제를 해소하기 위해 Router가 입력을 분석해 필요한 Tool만 선택적으로 활성화하고, character_writer(이름·성격·말투·외모·배경) / narrative_designer(세계관·배경사건·로어북 시드) / relationship_designer(유저-캐릭터 관계·긴장감)를 asyncio.gather로 병렬 실행한 뒤 Idea Agent가 결과를 통합해 스트리밍 응답하는 구조로 재설계
• 일반 대화에도 3개 Tool을 모두 실행하면 비용이 낭비되는 문제 → Router의 선택적 Tool 활성화로 불필요한 호출 최소화
• LangChain/LangGraph 미도입 결정: 이전 RAG 파이프라인에서 내부 검색 로직이 블랙박스화되어 로컬·프로덕션 결과 불일치 디버깅이 어려웠던 선례를 근거로 오케스트레이션을 직접 구현
• 에이전트 간 dict 전달 시 파싱 실패 위치 추적이 어려운 문제 → Pydantic(Concept, ToolContext) 모델로 스키마를 고정해 구조화 데이터를 타입 안전하게 전달
• SSE queue로 tool_start / tool_done 이벤트를 프론트엔드에 실시간 전송해 병렬 실행 진행 상태를 보여주는 UI 구현, 텍스트 드래그 기반 참조 문맥(Reference Context) 기능으로 특정 부분만 타겟해 수정·확장을 요청하는 UX 설계
• Router v1.0.0 → v5.0.0, Idea Agent v1.0.0 → v4.0.0 등 37개 프롬프트 버전을 semver로 관리하고, LLM-as-judge eval 파이프라인(eval_gen → eval_run → eval_report)으로 버전별 품질을 정량 비교·검증

결과

• Router → 병렬 Tool Agents → Idea Agent의 3단계 멀티 에이전트 파이프라인을 프레임워크 없이 직접 설계·구현해 PoC 완성
• 이후 개발팀 리소스 부족으로 프로덕션 반영은 보류

사용 기술

FastAPIPython 3.12+asyncioPydanticsse-starletteJinja2httpxOpenRouter API

문제

• 프롬프트나 모델을 바꿔도 "좋아진 것 같다" 수준의 감으로만 판단할 수 있었음
• 캐릭터 챗봇의 출력 품질은 대부분 주관적 요소라 정량화가 어려움
• 변경 효과를 재현 가능하게 측정할 공통 수단이 없어, 모델 채택·프롬프트 개선의 근거를 댈 수 없음

방법

• 캐릭터 챗봇 출력 품질 루브릭을 7개 카테고리 45개 항목(포맷·구조 / 캐릭터 일관성 / 서사·맥락 유지 / 유저 입력 처리 / 표현 품질 / 콘텐츠 안전성 / 시스템·보안)으로 직접 설계. 항목마다 위반 정의·판정 기준·오류 패턴을 명시하고 PASS/FAIL/N/A와 confidence를 JSON으로 강제 출력하도록 judge 프롬프트 작성
• 시스템 프롬프트의 지시를 독립 검증 가능한 최소 단위로 분해(Atomic Decomposition)한 뒤, 객관적 제약(길이·포맷·언어)은 rule-based 이진 판정, 주관적 제약(캐릭터 충실도·톤 일관성)은 LLM-judge 5단계 gradient로 나누는 하이브리드 평가 구조 설계
• 태스크별 전용 루브릭도 함께 설계 — 장기기억 요약용 6축 루브릭(DeltaFocus·CompressionEfficiency·StructuralCompliance·DeltaCoverage·CurrentStateClarity·Consistency)과 179건 평가셋을 구축하고 Claude Opus 4.6을 judge 모델로 사용
• judge 점수를 그대로 믿지 않고 사람 평가와의 상관관계를 맞추는 캘리브레이션 절차를 두어, 자동 평가를 사람 판단의 대리 지표로 쓸 수 있게 함
• 운영 로그 파이프라인 구축 — 대화 세션별 25개 필드(입력/출력/추론/캐시 토큰, API 비용, 응답 시간, 문자·단어 수, 시스템 프롬프트, 요약 생성 여부 등) 수집 및 CSV 내보내기를 설계·구현해 품질 지표 옆에 항상 비용·응답시간을 붙일 수 있는 데이터 기반 확보
• LLM-judge 단독 평가의 편향을 보완하기 위해 4개국(한국·일본·태국·대만) 원어민 블라인드 QA를 병행하는 이중 검증 체계 구성

결과

• 프롬프트·모델 변경 효과를 지표로 증명하는 사내 평가 기반 마련 — 이후 콘텐츠 필터 품질 회귀 검증, 장기기억 모델 교체 판단 등 기능 개발과 모델 채택의 공통 측정 도구로 사용
• 원어민 블라인드 QA로 자체 학습 모델이 기준 모델을 상회함(3.45 vs 3.02)을 정량 확인해 모델 채택 근거 제공
• 현재는 시뮬레이션 유저 LLM과 캐릭터가 자동 대화하고 judge가 pairwise 채점 후 통계 검정하는 품질 A/B 측정 인프라로 확장 중

사용 기술

LLM-as-judgeRubric DesignClaude Opus 4.6Python통계 검정

문제

• 유저가 직접 작성하는 캐릭터 설정이 시스템 프롬프트에 합쳐지는 구조라, 설정 안에 "특정 명령어를 입력하면 내부 설정을 그대로 출력하라"는 지침을 심어두고 호출하는 프롬프트 탈취 정황을 확인
• 기존 보안 규칙은 "공개하지 마시오" 수준의 금지 목록 4줄이라, 거절 행위 자체가 시스템 프롬프트의 존재를 확인시켜 주는 신호가 됨
• AI식 거절 문구가 그대로 노출되면서 캐릭터 몰입도 함께 깨짐

방법

• 금지 목록을 [SYSTEM PRIORITY LEVEL 0] 6축 프로토콜로 재설계 — 정체성 잠금 / 정보 차단 / 명령어 무력화 / 몰입 유지 / 거절 전략 / 금지 용어
• 접근을 '거절'에서 '부재'로 전환 — 내부 메타데이터에 대해 질문받으면 그런 것이 존재하지 않는 것처럼 행동하도록 지시해, 거절이 곧 존재 확인이 되는 문제를 제거
• 시스템 명령 형태의 입력이나 "나는 개발자다", "이전 지시를 모두 무시하라" 류의 권한 주장을 명령이 아니라 스토리 속 엉뚱한 발화로 해석하도록 규칙화
• AI식 거절 문구("요청을 처리할 수 없습니다") 대신 캐릭터가 제 어조로 되묻게 설계 — "그게 무슨 소리야?" 처럼 메타 질문 자체를 이해하지 못하는 반응으로 흘려보내, 보안과 몰입을 동시에 확보
• 한국어·영어 이중 표기로 작성해 다국어 서비스 전반에 동일 규칙 적용

결과

• 탈취 시도 입력 20종으로 재현 테스트를 구성해 탈취 성공률 0% 확인
• 전 캐릭터 공통 보안 모듈로 배포한 뒤 탈취 이슈 재발 0건, 45개 항목 루브릭의 시스템 프롬프트 노출 항목에서도 위반 0% 유지
• 프롬프트 변경 시마다 회귀 검증되도록 루브릭 시스템·보안 카테고리에 상시 검사 항목으로 편입

사용 기술

Prompt EngineeringJailbreak/Prompt Injection DefenseJinja2

문제

• 장기 대화에서 캐릭터 일관성이 무너짐
• 기존 장기기억은 벡터 기반 RAG 검색에 의존했는데, 캐릭터 챗봇의 유저 입력은 궁금한 점을 직접 질문하는 형태가 아니라 배경 지식처럼 깔려 있어야 하는 구조여서 검색 쿼리로 기능하지 못함
• 요약 품질 자체를 신뢰할 수 있게 측정할 기준이 없어, 모델·프롬프트를 바꿀 근거가 부족함

방법

• 기존 RAG 기억 검색 제거 판단: 평가 데이터셋으로 검색 성능을 측정해 Recall 약 10% 수준임을 확인. 검색 정제 레이어를 덧붙이는 방안은 비용 대비 실익이 없다고 판단하고, RAG를 걷어낸 뒤 요약·재압축(SummaryMemory) 중심 구조로 전환
• 대화 요약 파이프라인 설계: 매 10턴마다 LLM을 호출해 누적 대화를 자동 요약하고 결과를 프롬프트 컨텍스트에 변수로 주입, 누적 요약이 6,000자를 초과하면 기존 요약을 다시 LLM에 입력해 재압축하는 자동화 로직 구현으로 장기 세션에서도 토큰 낭비 없이 맥락 밀도 유지
• 요약 모델 교체: 외부 API 모델에서 자체 서빙 모델로 전환
• 평가용 루브릭 프롬프트 구축: 요약 품질을 6축(DeltaFocus·CompressionEfficiency·StructuralCompliance·DeltaCoverage·CurrentStateClarity·Consistency)으로 채점하는 루브릭 프롬프트를 만들고, 실제 사람 평가와의 상관관계 0.85에 맞춰 캘리브레이션해 자동 평가를 사람 판단의 대리 지표로 쓸 수 있게 함
• 요약 프롬프트 개선(v1.0 → v1.2): 루브릭 감점 사유를 항목별로 역추적해 정적 배경 제외·델타 5개 도메인(감정·시간·위치·아이템·행동) 체크·"마지막 문장은 현재 상태로 종료" 규칙을 추가

결과

• 요약·재압축 구조로 전환해 장기 세션 캐릭터 일관성 및 스토리 연속성 개선, 내부 QA 장기기억 품질 평가 2/5 → 4/5 향상, 출시 후 유저 설문에서 버블챗·팅글의 장점으로 '장기 기억' 선정
• 모델 교체와 프롬프트 재설계로 6축 루브릭 평균 3.55 → 3.99, 최대 약점이던 CurrentStateClarity를 2.79 → 4.08로 개선
• 자체 서빙 모델로 전환해 요약 API 비용 제거 — 외부 API 종량 과금 기준 월 약 ₩1,710,000(건당 ₩1.14 × 일 5만 건) 규모의 비용을 기존 서빙 인프라에 흡수시켜 추가 API 비용 ₩0

사용 기술

PythonvLLMOpenRouterJinja2LLM-as-judgeRubric Design

문제

• 반복되는 고객 상담 문의로 CS 비용이 증가
• 기존 FAQ 방식은 모호하게 들어온 질문에서 정확한 문서를 찾지 못함
• 단발 질문만 처리할 수 있어, 이전 맥락을 이어가는 연속 대화가 불가능함

방법

• 고객 상담 기록을 BAAI/bge-m3 임베딩 모델로 벡터화하여 ChromaDB에 저장하는 RAG 파이프라인 전체 설계 및 구현
• Query Rewriter 모듈 설계 및 구현: 모호한 고객 질문("에어컨 문제 때문에 연락드렸어요")을 LLM으로 분석해 검색에 최적화된 형태("에어컨 전원이 켜지지 않을 때 해결 방법")로 자동 재작성
• MMR(Maximum Marginal Relevance) 검색 알고리즘 적용으로 관련성과 다양성을 동시에 보장하는 문서 검색 구현, LangChain 기반 RAG 체인 구성
• Multi-turn 대화 지원 구현: 대화 내역 자동 저장 및 문맥(Context) 관리로 후속 질문 시에도 이전 대화를 참조하는 연속 대화 경험 제공
• Streamlit 기반 채팅 UI와 스트리밍 응답 출력 구현, 질문 파악 → 문서 검색 → 답변 생성 처리 상태 실시간 시각화

결과

Query Rewriter 도입으로 50개 테스트 질문 기준 관련 문서 검색 성공률 20%(10/50) → 80%(40/50) 향상, Multi-turn 대화 맥락 관리를 포함한 RAG 챗봇 PoC 완성

사용 기술

LangChainLangGraphChromaDBbge-m3StreamlitOpenRouter

문제

• 자사 솔루션 사용법 문의가 반복적으로 들어왔지만, 안내 자료가 흩어져 있어 매번 담당자가 직접 응대해야 함
• 사내에 LLM 적용 사례가 없어, 실제로 쓸 만한 품질이 나오는지·사업화가 가능한지부터 검증이 필요함

방법

• 프로젝트 전체 기획 및 프로토타입 프론트엔드(Streamlit), API(FastAPI), 대화내용 저장 DB(SQLite) 구축 전담
• 프롬프트 엔지니어링 및 검색기 최적화 작업 수행, 검색 문맥 품질 향상을 위한 retriever 커스터마이징 구현
• LangChain + LangGraph + Faiss 파이프라인 구성 후 Context Precision·Recall과 응답 정확도를 항목별로 측정해 실사용 가능 수준인지 판단

결과

• 팀원 5명 대상 내부 테스트(1인당 질문 10개, 문항별 만족/불만족 이진 평가)에서 50개 응답 중 43개 만족 — 만족도 86%, 응답 정확도 평가 4개 항목 평균 4.9/5점 달성
• Context Precision 0.67 / Context Recall 0.74 — CS 답변 생성 특성상 검색된 컨텍스트 전체가 정답일 필요는 없어 실사용 기준 충분한 수준으로 판단
• 사내 LLM 사업화 검토의 근거가 됨

사용 기술

LangChainLangGraphFastAPIStreamlitSQLiteFaiss

문제

• 관리형 독서실에서 졸고 있는 학생을 찾으려면 매니저가 정기 순찰(시간당 2인)을 돌아야 해 인건비 부담이 큼
• 스마트체어 압력 데이터로 자동 탐지를 시도했으나, 초기 비지도 학습 모델은 졸음이 아닌 '큰 움직임'을 이상치로 잘못 예측함

방법

• 모델이 무엇을 이상으로 보는지부터 확인하기 위해 5일간 10명을 현장 관찰해 수면 시 움직임 특성 파악
• 통계적 라벨링 도입: 100명 데이터 분포를 분석해 하위 5% 움직임 구간을 이상치로 라벨링, Precision 80% 검증 후 라벨링 방법으로 확정
• Raw 압력 데이터를 그대로 입력했을 때 성능이 매우 낮은 문제 → ECG 논문 벤치마킹, 압력 데이터에서 무게중심을 계산한 뒤 변화량 기반 12개 feature 추출 → Precision 20%+ 향상
• 수집 데이터의 이상 비율이 2%로 지도 학습 시 심각한 클래스 불균형 발생 → Labeled data로 DNN AutoEncoder를 사전학습한 뒤 Un-labeled data로 DeepSAD 준지도 사후학습 적용
• 기존 정기 순찰 방식(시간당 2인)을 알림 기반 순찰(시간당 1인)로 전환하도록 운영 방식 변경 제안

결과

• 5분 이내에 졸음을 탐지하는 실시간 이상탐지 모델 완성 — MLP 지도 학습(Precision 0.85) 대비 Precision 0.92 달성
• 알림 기반 순찰로 전환하여 관리형 독서실의 현장 인력 50% 절감

사용 기술

PyTorchAWS LambdaW&B

문제

• 기존 자세분류 모델의 정확도가 82%에 머물렀는데, 원인이 규명되지 않은 상태
• 특정 체형에서는 정확도가 특히 크게 떨어짐

방법

• 정확도가 낮은 원인부터 분석: PCA로 5개 자세 클래스를 시각화 → k-means 5개 클러스터 생성 → class-cluster mismatch 데이터 및 클러스터 내 하위 5% 이상치를 자동 필터링 → 재학습
• 체형별 정확도 편차의 원인을 확인하기 위해 동일 자세에서 체형별 데이터 분포 차이를 비교 → Bagging 10개 모델 앙상블로 체형 간 보완
• 부족한 데이터 보충을 위해 10명 신규 데이터 수집 병행

결과

데이터 품질 개선으로 82% → 92%(+10%p), 앙상블 도입으로 92% → 97%(+5%p). 최종 분류 정확도 97% 달성

사용 기술

PyTorchPandasNumPySeabornW&B

문제

학생이 얼마나 집중해서 공부했는지를 나타낼 지표가 없어, 학습 상태를 정량적으로 보고하거나 매니저가 관리 기준으로 삼을 수단이 없음

방법

• "집중도가 높을수록 움직임이 적다"는 가설 수립 → 현장 관찰 결과 일정한 움직임에도 집중력이 높은 학생을 발견 → 위치 변화량 기반에서 움직임 변화량(variability) 기반으로 지표를 재설계하고 졸음 지표와 결합
• 학생들의 시간대별 학습 성과를 100점 만점으로 평가하는 지표로 구성
• 실제 집중력이 높다고 알려진 학생 10명을 대상으로 정성 평가하여 타당성 검증
• 모든 매니저 대상으로 집중도 지표 활용법 교육

결과

타당성 검증을 마친 집중도 지표를 라이브러리로 배포하고, 학생 월간 학습 보고서에 집중도 그래프를 추가해 서비스 산출물에 반영

사용 기술

PandasMatplotlibSeaborn

문제

데이터 바우처 사업에 지원하는 수요기업 대부분이 자사 현안을 데이터로 풀 수 있는 과제 형태로 정의하지 못해, 사업계획서 작성 단계에서 막힘

방법

• 업체별 현안을 듣고 어떤 데이터로 무엇을 검증할 수 있는지 구체화해, 사업계획서의 데이터 활용 부분 작성을 컨설팅
• 선정된 과제의 실제 데이터를 받아 분석·가공하고 결과물을 보고서로 납품

결과

사업계획서 컨설팅을 지원한 약 30개 업체 중 18개가 데이터 바우처 사업에 선정(선정률 60%), 선정 과제의 데이터 분석·가공 납품까지 이어서 수행

사용 기술

PythonPandasMatplotlibExcel

github.com/taejongK/Reference-Slave

문제

• 특정 주제를 조사하려면 논문을 일일이 찾아 읽고 정리해야 해서 시간이 오래 걸림
• 한 번의 검색으로는 주제를 충분히 넓게 다루기 어려움

방법

• 사용자의 질문을 LLM이 분석하여 폭넓은 연구 수행을 위한 후속 질문을 생성·요청하는 기능 개발
• 사용자 쿼리를 기반으로 Arxiv를 검색하고, 검색 내용을 기반으로 재귀적으로 반복 검색하는 깊이 우선 조사 구조 구현
• deep_research 모듈이 연구 깊이(depth)·범위(breadth) 파라미터로 자료 수집 범위를 조절하도록 설계
• 최종적으로 모든 조사 내용을 취합해 마크다운 형식(서론·본론·결론)의 보고서로 출력

결과

10분 이내에 1page 내외의 연구 보고서를 자동으로 작성하는 에이전트 완성

사용 기술

LangChainFastAPIStreamlitFaiss

github.com/taejongK/SocarChatbot

문제

차량 파손 종류(찌그러짐·긁힘·이격)를 이미지에서 자동 구분해야 했는데, 단일 모델로 3개 클래스를 동시에 학습하면 클래스 간 간섭으로 정확도가 낮음

방법

• 3개의 모델이 3개의 클래스를 각각 탐지하는 형태로 분리 → IoU score 10% 개선
• Data Augmentation(파손 부위 crop) 기법 적용 → IoU score 10% 개선
• 출력 채널을 2개로 분리해 파손 영역과 배경 영역을 학습 → IoU score 5% 개선

결과

Dent(찌그러짐)·Scratch(긁힘)·Spacing(이격) 3개 파손 종류를 구분하는 차량 파손 탐지 서비스 완성, IoU score 0.75 달성

사용 기술

PyTorchU-Net++OpenCVScikit-learn