Solbi Lee님의 블로그

https://huggingface.co/solbi12/ax4-mongodb-query-generator solbi12/ax4-mongodb-query-generator · Hugging Face🚀 A.X-4.0-Light MongoDB Query Generator 한국어 자연어를 MongoDB 쿼리로 변환하는 AI 모델 SKT A.X-4.0-Light 기반으로 파인튜닝된 전문 데이터베이스 쿼리 생성 모델 📋 모델 개요 이 모델은 SKT의 A.X-4.0-Lighthuggingface.co 왜 이런 걸 만들게 됐나?MongoDB 쿼리 문법이 정말 골치 아프다. SQL은 그나마 직관적인데, MongoDB의 aggregate 파이프라인이나 복잡한 find 조건들은 매번 구글링하게 된다. "브랜드별 평균 가..

현재 파악한 아키텍처 흐름보고서 생성 시스템의 전체 데이터 흐름을 정리해보니:MongoDB (원시 데이터) → 데이터 추출 & 가공 → 모델 입력 형태 → KoBART → 보고서 출력각 단계마다 어떤 처리가 필요한지 구체적으로 파악해야 겠다.MongoDB에서 추출해야 할 데이터 유형 분석이커머스 보고서에 필요한 핵심 데이터매출 관련 데이터// orders 컬렉션에서 추출할 데이터{ "date_range": "2024-03-01 to 2024-03-31", "total_revenue": 1200000000, "order_count": 15847, "avg_order_value": 75692, "revenue_growth": 15.3 // 전월 대비 %} 고객 행동 데이터// users, user..

https://cat-b0.tistory.com/147 AI/ML 핵심 기술 분석: LoRA, RAG, Large Language Diffusion Models(LLDM)오늘 하루 종일 파인튜닝이라는 개념을 파헤쳤다. 처음엔 단순히 "모델은 내 데이터로 다시 학습시키는 것" 정도로만 이해했는데 학습 기법에도 여러가지가 있었다. 파인튜닝이 뭔지 이해하려cat-b0.tistory.com 보고서 생성 분야 현황 분석검색을 통해 보고서 생성 분야의 현황을 파악해봤다. 생각보다 훨씬 큰 시장이고 실제 기업들이 활발하게 도입하고 있는 분야였다.시장 규모와 성장 전망글로벌 자연어 생성 시장이 2024년 8.8억 달러에서 2028년 19.1억 달러로 성장할 것으로 예상된다고 한다. 연평균 성장률이 21.4%라니 정말 ..

오늘 하루 종일 파인튜닝이라는 개념을 파헤쳤다. 처음엔 단순히 "모델은 내 데이터로 다시 학습시키는 것" 정도로만 이해했는데 학습 기법에도 여러가지가 있었다. 파인튜닝이 뭔지 이해하려고 삽질한 과정 Q. 왜 처음부터 학습하면 안되는가? GPT나 BERT 같은 모델들이 이미 완성된 상태인데 왜 또 학습을 시켜야되는지 의문이었다. 여러 자료를 찾아보니 핵심은 일반화 VS 특화 였다. 대형 언어 모델들은 인터넷의 거의 모든 텍스트로 학습되어있다. 위키피디아, 뉴스, 소설, 논문, 댓글까지 이렇게 학습된 모델은 일반적인 언어 패턴은 잘 이해하지만 내가 원하는 특정 작업(보고서 작성) 에는 최적화되어있지 않다. 예를 들어보자면 GPT-4는 일반적인 대화는 잘하지만, 내가 만약 의료진을 위한 AI를 만들고 싶..

프로젝트 배경 회사에서 넘쳐나는 데이터를 자연어로 쉽게 가져오고, 분석까지 해주는 솔루션을 만들고 싶었다. 프로젝트 구조 분석 실제로 3개의 다른 AI 모델이 협력하는 시스템 1단계: 자연어 → MongoDB 쿼리 변환목적 : "지난 달 서울 지역 매출 데이터 가져와줘" → MongoDB 쿼리 필요 모델- Text-to-SQL/NoSQL 모델 (몽고DB를 사용할 예정이니 MQL)- 또는 LLM + 프롬프트 엔지니어링 (GPT, Claude 등) 2단계 : 데이터 예측 / 분석목적 : 추출된 데이터로 패턴 분석, 예측 필요 모델 : 전통적인 ML 모델 ( scikit-learn, XGBoost 등 ) 또는 딥러닝 모델 (시계열 예측 등) 3단계 : 보고서 생성 목적 : 분석 결과를 자연어 보고서로 작..

문제 정의부터 시작했다기존 내비게이션이 완벽해 보이는데 굳이 새로 만들 필요가 있나? 처음엔 의문이었다.하지만 데이터를 보니 명확했다:T-map, 네이버맵: 일반 보행자 기준계단/육교/에스컬레이터 = 물리적 장벽 미고려엘리베이터 고장, 공사 구간 = 실시간 반영 불가결론: 필요하다. 기술 스택 결정 과정Backend 선택: Spring BootNode.js도 고려했지만 기각했다.이유:- 복잡한 경로 알고리즘 → Java 안정성 필요- 지리 정보 쿼리 → MyBatis 적합- 인증 시스템 → Spring Security 검증됨 Frontend: ReactVue.js보다 단순한 이유들:지도 API 레퍼런스 많음컴포넌트 재사용성 높음React Router 직관적 Database: MySQLNoSQL 검토했지..

YOLOv3 벌 탐지 프로젝트: 커스텀 NMS, A/B테스트 중독, 증상 분석 문제의 발견프로젝트 요구사항은 명확했다. YOLOv3로 벌을 탐지하고 ResNet-18로 종을 분류하는 파이프라인을 구축하는 것. 하지만 처음부터 불안했다.(강사님께서 어차피 성능 제대로 안나올 거라고 하셨기 때문)GPU 자원은 제한적이고 학습 시간도 부족했다. 그래서 처음부터 전략을 바꿔 잡았다. 모델 아키텍처에 매달리지 말고 후처리에 집중하기로 했다.벌집 데이터의 특성을 관찰해보니 몇 가지 문제가 보였다. 벌들이 서로 겹쳐 있고, 벌집과 벌이 시각적으로 유사한 경우가 많았다. 일반적인 NMS로는 이런 복잡한 상황을 제대로 처리하기 어려울 것 같았다.그래서 커스텀 후처리를 설계하기로 했다. IoU 기반 군집화를 통해 겹치는 ..

YOLOv3 벌 탐지 모델 구현과 성능 저하의 미스터리 - 완전 해부 분석기들어가며: 완벽했던 모델이 왜 갑자기 0이 되었나꿀벌 객체 탐지 프로젝트에서 정상 동작하던 YOLOv3가, 코드 리팩토링 이후 mAP@0.5=0.0000으로 붕괴했다. Loss는 줄어드는데, 평가 지표는 전부 0. “학습 문제가 아니라 추론/평가 경로가 엉킨 것”이라고 직감했다. 그래서 성능이 잘 나오던 **v1(정상판)**과 리팩토링 후 **v2(붕괴판)**를 라인별로 대조하며 원인을 끝까지 추적했다. 아래는 내가 실제로 고민하고, 고쳤고, 배웠던 모든 것을 일기처럼 남긴 기록이다.1) 왜 YOLOv3였나 — 벌 데이터의 특성과 FPN 선택겹침(occlusion): 벌이 군집을 이루며 붙어 있음 → 경계가 모호크기 다양성(sca..

1. 데이터셋 확정8월 15일 회의에서 팀은 최종적으로 AI Hub의 꿀벌 데이터셋을 사용하기로 결정했다.👉 AI Hub 벌 데이터셋 바로가기 클래스 구성: 수일벌(AB) / 여왕벌(QB) × 이탈리안(LI), 카니올란(CA), 호박벌(BI), 한봉(AP) 총 8종류 (AB_LI, QB_LI, AB_CA, QB_CA, AB_BI, QB_BI, AB_AP, QB_AP) 제외 클래스: 알, 애벌레, 번데기, 질병 데이터 즉, 우리는 성체 꿀벌 중심의 객체 탐지 + 분류를 목표로 한다. 2. YOLOv2 vs YOLOv3 역할 분담팀원 간 역할을 분담해 YOLOv2와 YOLOv3를 병렬 학습하기로 했다.나는 YOLOv3를 담당했다.YOLOv3의 특징 요약 :Darknet-53 백본..

1. 과제 설계의 핵심이번 과제의 구조는 명확했다.“검출 → 크롭 → 분류”의 두 단계 파이프라인을 구성하는 것이다.YOLO로 객체를 검출한 뒤,해당 영역을 crop하여ResNet, EfficientNet, 혹은 간단한 MLP/SVM 같은 별도의 분류 모델에 전달한다.이는 실제 산업 현장에서도 자주 활용되는 접근법이기도 하다.예를 들어 동전 인식, 과일 분류, 교통 표지판 인식 같은 응용 문제들이 대표적이다. 2. 주제 선정 과정에서의 고민초기에는 다양한 아이디어를 검토했다.동전 인식: 동전 검출 후 금액 합계 계산과일 바구니: 과일 검출 후 종류별 개수 산출교통 표지판: 표지판 검출 후 세부 클래스 분류각각 나름의 기술적 도전과 실용성을 갖추고 있었지만, 데이터셋 확보의 현실적 제약을 반드시 고려해야 ..