교육과정 추천 — 평가 지표로 구조를 고른 PoC

대기업 고객사 사내 교육 플랫폼에서 임직원 한 명의 업무목표·이력·행동을 읽어 교육과정과 사내 숏폼 영상을 추천하는 과제다. 같은 과제 안에서 두 갈래 일을 했다. ① 검색 백엔드 이중화 — 운영용 사내 RAG 플랫폼과 로컬 pgvector를 같은 코드로 오가게 만든 일, ② 추천 품질 평가 — pgvector 갈래의 검색 앱에서 검색 → 필터 → 후처리 → LLM 판독 → 개인화의 단계별 품질을 잰 일이다. 평가는 추천을 만들지 않은 별도 LLM이 적합도를 채점한 오프라인 평가이고, 운영 성과가 아니다.

• 운영 검색은 사내 RAG 플랫폼에서만 되는데 로컬에는 그 API가 없어, 로컬 개발·검증 결과와 운영 결과를 맞추기 어려웠다. 그 플랫폼은 기간(range) 필터도 지원하지 않았다.
• 벡터 검색·공동수강 그래프·LLM 판독·개인화 보정 중 무엇을 넣을지, 「추천이 좋아졌다」를 감이 아니라 지표로 판단해야 했다.

구현·문서는 AI 에이전트(Claude Code)가 했다. 아래는 결정 기록이 있는 것과 이력서에 본인이 적은 범위다.

• 벡터화 대상과 요구사항을 구분해 정리했다.
• 추천 PoC를 기획했다 — 업무목표·전문분야·수강이력·행동신호 4개 신호를 비교 대상으로 정하고, 품질 변동성과 개인정보 리스크를 이유로 1차 범위에서 업무목표를 뺐다.
• 검증 진행 방식(단계별 자동 검증)을 결정했고(2026.05), 그래프 추천을 중간 판정 없이 끝까지 만들어 벡터와 비교하도록 정했다(2026.06).
• 운영 전환 권고안을 냈다 — 추천 방식 5종을 운영 전환 속도·데이터 갱신성으로 비교해 「벡터 후보 생성 + 관계 테이블 필터·후처리 + 사용자별 추천 캐시」를 권장했다(설계 문서 단계).

1. 같은 도메인을 두 백엔드로 구현하고, 결과 동일성을 1순위로 둔다 — 검색 저장소를 추상화하고 환경변수 한 줄로 임베딩·검색 저장소·DB를 함께 바꾼다. 로컬 임베더가 사내 임베딩 API의 응답 형식까지 흉내 내야 호출부에 분기가 생기지 않는다.
2. 플랫폼의 기능 차이는 감추지 않고 토글로 남긴다 — 기간 필터는 후처리로 우회하되 설정 토글로 남겼고, 다중 업무목표는 순차 대신 병렬로 검색해, 사용자 5명 표본의 최대 검색시간이 약 4.17배 줄었다(원문 P95(max)).
3. 벡터를 주축으로, 그래프는 보강으로 — 같은 수강이력 질의 12건에서 벡터가 P@10 0.80·nDCG@10 0.70, 공동수강 그래프가 0.51·0.38이었지만, 두 방식의 상위 10개는 0.8%만 겹쳤고 그래프만 찾은 관련 과정이 58건이었다. 그래서 벡터 주축 + 그래프 보강으로 방향을 정하고 별도 그래프 DB 도입은 보류했다.
4. LLM 판독은 사전 계산으로, 개인화는 질의 종류별로 — 로컬 gemma 31B는 후보 25개에 약 200~300초가 걸려 실시간 경로에 맞지 않았다. 개인화 보정(난이도 맞춤)은 전문분야·수강이력·행동기반 질의에서 정밀도를 올렸지만 업무목표 질의에서는 떨어뜨려, 일괄 적용하지 않기로 했다.

① 검색 백엔드 이중화 (2026.04 ~ 05)

• 검색 방식 4종·엔진 3종 비교 문서가 나왔다. 가상 과정 10,000건 벤치에서 필터를 걸면 BM25만 상위 100개를 채우지 못했다.
• 사내 RAG 백엔드는 검색·필터·후처리를 나눈 파이프라인으로 Step 7(API + 적재)까지 구현됐고, pgvector 쪽은 로컬 실행 환경이 M0~M5까지 세워졌다(검증 23항목 자동화). 벡터화·검색 작업은 마지막 기록(2026.07)상 진행 중이고 이후 상태는 확인되지 않았다. 로컬 시험 데이터의 매칭 예외를 분리해 개발 검증이 멈추지 않게 했다.

② 추천 품질 오프라인 평가 (2026.05 ~ 06)

• pgvector 갈래에서 하이브리드 검색(BM25 + KNN → RRF)·필터·후처리 위에 LLM 적합 판독과 개인화 보정을 더한 5계층 검색 앱이 구성됐다.
• LLM 판독: 로컬 gemma 31B가 후보마다 적합도 0~3점을 매기고 2점 이상만 통과시켰다. 사용자 3명의 과정 후보 75개 중 17개(약 22.7%)가 걸러졌다. 걸러낸 것이 품질 개선인지는 그 시점에 따로 검증하지 않았다.
• 3원 비교: 같은 후보에서 「검색만 / +LLM 판독 / +개인화 보정」 세 추천을 별도 LLM이 같은 기준으로 채점했다(질의군당 5건, 과정·숏폼 영상).

③ 운영 전환 권고 (2026.06, 설계 문서)

• 1차는 학습형 추천 모델이 아니라 벡터 후보 생성 + 관계 테이블 필터·후처리 + 사용자별 추천 캐시로 가고, 경량 재정렬 모델은 2차, two-tower·E2E 모델은 3차 이후로 미루는 PRD 초안이 나왔다. Codex 검토가 성공 지표·권한 처리 등을 보완하라고 지적했고, 구현 기록은 없다.

• ① 환경변수 한 줄로 백엔드가 바뀌는 파이프라인, 다중 목표 병렬 검색의 최대 검색시간 약 4.17배 단축(사용자 5명 표본, 원문 P95(max)).
• ② 과정 추천 P@10(적합 2점 이상 비율, 질의군당 5건, 별도 LLM 채점, 2026.06, 오프라인):

• 표의 행동기반 77%(0.77)와 핵심 판단 3의 0.80은 둘 다 P@10이지만 평가 대상과 조건이 달라 직접 비교할 수 없다 — 0.80은 수강이력 질의 12건에서 벡터 검색만의 결과를 관련 라벨로 판정한 값이고, 0.77은 행동기반 질의 5건에서 LLM 판독·개인화 보정까지 거친 추천을 채점한 값이다.
• 사용자 효과는 근거가 없다(운영 적용 전).

• 모든 품질 수치는 오프라인·LLM 채점·소표본이다. 3원 비교는 질의군당 5건을 시연 가치 순으로 골라 숙련자 쪽에 치우쳤고, 벡터 vs 그래프는 판정자 하나·12건이다. 통계적 유의성은 없다.
• 수치는 채점 기준에 크게 좌우된다. 같은 추천을 주제 적합 기준으로 다시 채점하면 LLM 판독 추천의 과정 P@10은 질의군별 62~97%로 달라졌다.
• 업무목표 질의의 업무목표 데이터는 임의로 만든 검증용 표본이었다. 숏폼 영상은 로컬에 자막이 없어 그래프 비교를 못 했고, 개인화 효과도 수강이력 질의 말고는 보합·소폭 악화였다.
• Codex 검토는 「제거율만으로는 품질 향상을 증명하지 못한다」, 「행동기반 0.77은 행동 데이터가 없는 사용자 비율·매칭률을 함께 봐야 한다」고 지적했다.

• 검색: BM25 + KNN(cosine) → RRF 결합, pgvector HNSW, Elasticsearch(라이선스 제약 시 KNN 자동 폴백), ChromaDB
• 임베딩: BGE-M3 1024차원(로컬 Ollama·sentence-transformers / 운영 사내 임베딩 API), 모든 행에 임베딩 출처 4축 기록
• 판독·평가: mlx-lm + gemma-4-31B(MLX, 로컬), 평가 채점은 추천 생성 모델과 다른 별도 LLM
• 서버·데이터: Python FastAPI, PostgreSQL + pgvector, MySQL, Docker compose, pytest

• 도구가 한 일: 백엔드·검색 앱·평가 스크립트 구현과 문서 작업은 Claude Code로 진행했다. 추천 단계의 적합 판독은 로컬 gemma 31B가 맡았고, 평가는 추천을 만들지 않은 별도 LLM이 채점해 자기 채점을 피했다. PRD 초안은 Codex가 독립 검토했다.
• 본인이 한 일: 무엇을 비교할지와 1차 범위를 정하고, 검증 진행 방식을 결정하고, 평가 결과를 근거로 권고안을 냈다.
• 수치를 다루는 방식: 제거율처럼 동작을 보여 주는 값과 적합도 개선을 보여 주는 값을 나눠 적고, 채점 기준이 바뀌면 두 기준의 결과를 함께 남겼다.