개발과 일상

지난 글에서는 질의처리기를 테스트하기 위한 테스트셋을 어떻게 만들었는지 정리했다. 질의처리 테스트셋을 만들고 나니 다음 질문이 생겼다. 테스트셋을 기준으로 작은 모델을 학습시키면, 룰 기반 질의처리기를 대체하거나 보완할 수 있을까? 검색 본경로에 큰 LLM을 그대로 넣기는 어려웠다. 프롬프팅만으로 질의처리를 맡겼을 때 정확도는 50%대에 머물렀고, 온디바이스 환경에서는 속도 부담도 컸다. 하지만 질의처리 작업 자체는 범위가 비교적 명확했다. 사용자의 입력에서 검색 키워드, 날짜, 파일 타입, 작성자, 경로 같은 정보를 JSON 형태로 뽑아내면 된다. 자유로운 답변을 생성하는 것보다 훨씬 좁은 문제였다. 그래서 작은 모델을 이 작업에 맞게 파인튜닝해보면 어떨까 생각했다. 이번 글에서는 질의처리기를 작은 모..

지난 글에서는 검색기 앞단의 질의처리 방향을 어떻게 정리했는지 적었다.테스트 결과, 사용자의 질의를 그대로 검색하는 방식이 형태소분석 후 키워드만 넘기는 방식보다 조금 더 안정적이었다. 하지만 그렇다고 질의처리가 필요 없는 것은 아니었다. 검색 본문으로 사용할 표현은 최대한 보존하되, 날짜나 지역, 파일 타입, 기관명처럼 조건으로 다룰 수 있는 정보는 별도로 구조화하는 편이 더 적절해 보였다.결국 핵심은 LLM을 쓰느냐 마느냐가 아니었다.검색어로 남길 것, 필터 조건으로 분리할 것, 제거할 것을 나누는 기준이 더 중요했다.그렇다면 다음으로 정해야 할 것은 이 기준을 어떻게 테스트할 것인가였다.검색기는 정답 문서가 검색 결과 상위에 들어오는지를 보면 된다. 하지만 질의처리기는 정답 문서를 직접 찾는 컴포넌..

지난 글에서는 RAG 검색을 개선하기 전에 테스트 기준을 먼저 정리해야 했던 이유를 적었다.테스트 기준을 정리한 뒤 여러 방식으로 검색을 비교해보니, 검색기 자체에 큰 문제가 있다고 보기는 어려웠다. 정답 문서를 회수하는 능력은 어느 정도 안정적으로 나왔고, 검색 모델이나 벡터 DB 자체를 먼저 의심할 상황은 아니었다.오히려 눈에 띈 것은 검색기 앞단의 질의처리였다.같은 검색기를 쓰더라도 사용자 입력을 어떻게 해석하고, 어떤 형태로 검색기에 넘기느냐에 따라 결과가 달라졌다. 그래서 이번 글에서는 검색기 앞단의 질의처리 방향을 어떻게 정리했는지 적어보려고 한다. 1. 질의를 그대로 쓰는 편이 조금 더 나았다가장 먼저 비교한 것은 문장을 그대로 검색하는 방식과, 형태소분석 후 키워드만 넘기는 방식이었다.처..

현재 온디바이스(On-Device) 환경에서 사용할 RAG 검색 시스템을 개선하고 있다. 처음에는 임베딩 모델을 바꾸거나, 검색어를 확장하거나, 리랭커를 붙이는 식으로 검색 성능을 올리는 데 집중했다. 그런데 실험을 하다 보니 생각보다 먼저 정리해야 할 문제가 있었다. 바로 "이 검색 시스템이 좋아졌다는 걸 무엇으로 판단할 것인가?" 였다. RAG 검색 성능을 테스트하다 보면 자연스럽게 Recall@k, MRR 같은 평가 지표를 보게 된다. 검색 결과 상위 k개 안에 정답 문서가 들어왔는지, 정답이 몇 번째에 나왔는지를 보는 방식이다. 지표 자체는 명확했다. 문제는 테스트 데이터셋이었다. 좋은 점수가 나왔다고 해서 실제 서비스 검색이 좋아졌다고 말할 수 있을까? 반대로 점수가 낮게 나왔다고 해서 지금 시..

나는 그동안 클라우드나 온프레미스 웹 서비스 개발을 주로 해오다가, 이번에 처음으로 온디바이스(On-device) 솔루션 환경 개발을 맡게 됐다. 그러다 보니 서버를 .exe 파일로 빌드해서 배포하는 생소한 경험을 하게 됐는데, 백그라운드 루프가 별도의 에러 없이 꺼지는 현상을 발견했다. 에러 로그가 없다보니 어느 시점에 종료되는지 정도만 파악할 수 있었는데... LLM에게 코드 재검토를 맡겨보니 asyncio가 Segmentation Fault(Segfault) 에러를 발생시킬 수 있다는 걸 처음 알게 됐다. 왜 하필 다른데서는 다 잘 되다가 온디바이스(Windows/EXE) 환경에서 문제가 발생했을까? 결론부터 말하자면, 메모리 관리의 '관대함' 차이 때문이다. 넉넉한 리소스의 리눅스 서버에선 가비지..

서버 개발을 하다 보면 일단 응답을 내보내서 화면은 동작시키고, 서버 백그라운드에서 작업을 하도록 만들고 싶은 경우가 있다. 이런 작업을 보통 비동기 작업이라고 하는데, 스프링(Spring)에서는 @Async가 주로 쓰인다 스프링 부트에서 초간단 멀티쓰레드 구현하기 : @Async FastAPI 기반으로 개발하면서 이런 상황에서 어떤 걸 쓸까 고민하며 찾아보니, 주로 asyncio와 BackgroundTasks라는 도구를 사용하고 있었다. 하지만 이 둘은 동작 방식과 시점이 크게 다르기 때문에, 각각 어떤 특징이 있고 주의할 점은 무엇인지 정리해 보려고 한다. 1. asyncio파이썬에서 기본 제공하는 라이브러리로, 가장 핵심적인 비동기 처리 방식이다. 특징이 있다면 응답이 나가는 걸 대기하지 않고 ..

현재 온디바이스(On-Device) 환경에서 사용할 RAG 솔루션을 개발 중에 있다. 매번 하드웨어의 제약이 사실상 없는 클라우드 환경에서만 개발하다가, 리소스 제약이 심한 온디바이스 환경으로 넘어와 초기 RAG 시스템을 개선하려다 보니 고민해야 할 부분들이 정말 많았다. 전체 구조를 도식화하면 다음과 같다. 이 그림이 대부분의 RAG 시스템을 설명해준다. 그림을 보고 다시 생각해보니 사실 안 중요한 부분이 없긴 한데...그래도 그 중에서 조금 더 중요하다고 생각하는 부분부터 하나씩 정리해보자. 1. 임베딩을 하기 위한 데이터 정제현재는 사내에서 자체 개발한 문서 분석 툴을 사용하고 있다. 데이터 정제 과정이 중요한 이유는, 이 전처리를 얼마나 잘하느냐에 따라 표나 이미지에 포함된 정보에 대한 질문을 ..

AI 솔루션 개발팀으로 이동하게 되면서 개발 환경에 큰 변화가 생겼다. 기존 클라우드 환경에서 온디바이스(On-Device) 타겟으로 작업 영역이 변경되었고, 이에 맞춰 언어는 Python 네이티브로, 백엔드 프레임워크는 FastAPI로 통일되었다. 이번 포스팅에서는 4~5년간 사용했던 Spring Boot 환경에서 넘어와 약 한 달간 FastAPI를 실무에서 사용해보며 체감했던 장단점을 정리해보려 한다. 가장 크게 다가왔던 차이점들을 키워드로 꼽자면 다음과 같다. 장점: 핫리로드(Hot Reload), Pydantic, 비동기 제어단점: 의존성 주입(DI)과 객체 생명주기 관리의 어려움, 명시적 트랜잭션 관리, 싱글톤 정의의 모호함 이 글에서는 위 내용들을 하나씩 상세하게 비교해 보겠다.장점 1. 핫리..