Evaluation |

최종 버전 확정 및 초안 배포

Fri, 21 Aug 2026 00:00:00 +0900

Version 03 Architecture

flowchart TD START([사용자 입력
prompt + pending + pendingOriginal
+ installedApps]) --> P{pending=true
AND pendingOriginal?} P -->|Yes| PR[Pending Resolver
gpt-4o-mini
LangChain] P -->|No| IC[Intent Classifier
ST + LogisticRegression
또는 heuristic
LLM 없음] PR --> A{5액션} A -->|CANCEL| C1([END
ok=false
failReason=cancelled
needsSupplement=false]) A -->|UNRESOLVED| C2([END
ok=false
needsSupplement=true
pending 유지]) A -->|CONTINUE / UPDATE| M[이전 명령 + 이번 입력
merge prompt] A -->|NEW_REQUEST| N[이번 prompt만] IC -->|reject
잡담| R([END
ok=false
failReason=chitchat
dialogIntent=reject
LLM 0회]) IC -->|extract| E M --> E[LLM Extractor
gpt-4o
function calling] N --> E E --> V[Rule Validator
코드] V -->|incomplete| ASK([END
ok=false
needsSupplement=true
재질문 / pending]) V -->|complete| MAP[App Mapper
embedding cosine
name → packageName] MAP -->|미매칭| U([END
ok=false
app_unresolved]) MAP -->|성공| OK([END
ok=true
규칙 저장])

Docker

앱 + 라이브러리 + 실행 방법을 상자에 넣어, 어디든 같은 방식으로 돌리게 하는 도구임.

현재 V3는 sentence-transformers와 같은 것들로 인해 의존성이 무거워 , EC2에 수동 pip보다는 Docker로 묶는 것이 좋다고 결정함.

우선 Docker + AWS ECR + App Runner를 활용해서, 1차적으로 배포를 먼저 진행함.

이후 부하 테스트 진행 후, 수정 사항 반영 후 재배포할 예정임.

AWS App Runner 운영 종료 이슈

이로 인해, Amazon Elastic Container Service로 배포를 진행함. (Tokyo)
배포 이후, /health 확인 완료

{
 "status": "ok",
 "promptEngine": "v3"
}

중간 점검

NotiLLM 관련

전체 소스코드에 주석 남기면서 과정을 하나하나 다시 뜯어보는 과정이 필요함
부하 테스트 반드시 진행할 것.
아직, 눈에 띄는 인사이트를 기반으로 한 발전 과정이 안보임. 너무 뻔하고 흔한 과정들로 발전시킨 것 같아, 해당 과정에 대한 고민도 필요할 것 같음.

기타

포스터 홀 개선 및 추가할 것.
코딩테스트 및 서류 및 면접 준비
통계 및 머신러닝 관련 공부도 지속적으로 진행.

Version 간 결과 비교/분석

Thu, 20 Aug 2026 00:00:00 +0900

LangGraph를 사용하기 이전(전부 4o모델) vs 모델 분기 비교 실험

결과

Metric	Baseline	Routing V2	Change (%)
Runs	85.0000	85.0000	0.0000
Total Cost ($)	0.8520	0.7277	-14.5903
Avg Cost ($)	0.0100	0.0086	-14.5903
Mean Latency (s)	4.6433	7.5294	+62.1563
P50 Latency (s)	4.2594	7.3486	+72.5282
P95 Latency (s)	7.2314	9.9255	+37.2561
P99 Latency (s)	9.4063	13.0560	+38.8006

LLM-based routing은 비용을 감소시켰지만 sequential LLM calls로 P95 latency가 너무 증가하는 문제점이 생겼다. Total Cost와 Latency의 문제를 둘 다 잡는 다른 방법에 대한 고민이 필요해보였다..

LLM Router 까지 두어서 LLM 모델을 두 번 처리하는 게 문제였기에, LLM Router를 제거하고 lightweight intent classifier로 대체 하려고 함.

기존 LLM Router 대신 sentenceTransformer + LogisticRegression 기반 classifier로 구현하고자 함.

`v1` vs `v2` vs `v3`

Metric	V1 Baseline	V2 LLM Router	V3 Classifier
Runs	85	85	85
Total Cost ($)	0.8557	0.7401	0.7224
Avg Cost / Run ($)	0.0101	0.0087	0.0085
Mean Latency (s)	4.1386	6.2194	3.3433
P50 Latency (s)	3.1119	5.4087	3.1164
P95 Latency (s)	7.4149	11.0379	7.0132
P99 Latency (s)	12.9387	11.9233	8.7200
API Calls	85	85	67
API Call Rate (%)	100.00	100.00	78.82
Extract Rule Correctness	0.8941	0.9048	0.9024
Extract Rule Correctness (if routed)	-	0.9048	0.8780
Route Correctness	-	1.0000	0.9756

V3는 V1 대비 비용 15.58%, 평균 Latency 19.22% 감소했고, LLM API 호출도 21.18% 절감함.
정확도는 V1 0.8941 → V3 0.9024로 유지·소폭 개선되어, 성능 저하 없이 비용과 응답 속도를 함께 개선함.

LangGraph 도입 검토 및 데이터셋 설계

Mon, 17 Aug 2026 00:00:00 +0900

`LangGraph` 도입하는 게 맞을까?

LangGraph를 비용 최적화 를 위해 도입하는 게 좋을 거 같음.

현재 version은 ChatGPT 4o 모델을 활용해 사용자 자연어 처리를 함.
- 현재 얼마의 비용이 청구되는 지에 대한 정확한 판단이 필요함. 문제 설정 필요
- 하지만 사용자 명령이 만약 안녕, ㅎ2, ㅎㅎ 라면? 굳이 모든 명령들을 전부 4o 모델로 처리할 필요가 있을까??
- 사용자의 명령을 중요도 낮음, 약간 중요, 매우 중요 등으로 나눠서, 이에 맞는 수준의 모델로 라우팅해주는 게 좋을 거 같음. 나중에 구현할 기능

Version 01.

flowchart TD START([사용자 입력
prompt + pending 플래그]) --> R{의도 라우터
gpt-4o-mini} R -->|잡담 / 인사 / ㅎㅎ| S[단순 응답
gpt-4o-mini
tool 없음] S --> END1([END
채팅 응답만]) R -->|알림 규칙 관련| P{pending?} P -->|false| E[규칙 추출
gpt-4o
extract_notification_rule] P -->|true| C[재질문 후속 분류
gpt-4o-mini] C -->|supplement
보충| M[이전 명령 + 보충
합친 prompt] C -->|new_command
새 명령| N[이번 prompt만] M --> E N --> E E -->|tool 성공| OK[confirm 문장
gpt-4o] E -->|정보 부족| ASK[재질문 메시지
ok=false] OK --> END2([END
규칙 저장]) ASK --> END3([END
앱이 pending 유지])

Version 02.

flowchart TD START([사용자 입력
prompt + pending + pendingOriginal]) --> ENTRY{pending=true
AND pendingOriginal 있음?} ENTRY -->|Yes| RP[resolve_pending] ENTRY -->|No| R[의도 라우터
gpt-4o-mini
route_intent] R -->|chitchat
잡담/인사/ㅎㅎ| S[단순 응답
gpt-4o-mini
tool 없음] S --> END1([END
ok=false
failReason=chitchat
needsSupplement=false]) R -->|extract
알림 규칙 관련| RP RP --> C{pending 분류?
gpt-4o-mini} C -->|pending 아님| N[이번 prompt만] C -->|supplement
보충| M[이전 명령 + 보충
합친 prompt] C -->|new_command
새 명령| N M --> E[규칙 추출
gpt-4o
function calling] N --> E E -->|성공| OK[confirm 문장
gpt-4o] E -->|정보 부족| ASK[재질문
ok=false
needsSupplement=true] E -->|충돌/앱 미해결 등| FAIL[실패
ok=false
needsSupplement=false] OK --> END2([END
규칙 저장]) ASK --> END3([END
앱이 pending 유지]) FAIL --> END4([END
pending 해제])

LangGraph 도입 시 (`Routing 버전`을 추가), 확인 사항

A버전에 비해 B버전에서, 정확도가 많이 떨어지지 않는지
비용 및 속도가 얼마나 줄어드는지

Evaluation Dataset 구성 기준

Evaluation Dataset이 특정 유형에 편중되지 않도록, 주요 평가 축을 intent, time, target으로 나누고 각 카테고리 별 최소 케이스 수를 정의했습니다.

전체 Dataset: 85 cases
주요 카테고리 별 최소 5 cases 이상 확보
ok=true 케이스에서는 time, target 세부 유형이 모두 포함되도록 구성

Coverage 확인

모든 주요 카테고리에서 최소 5개 이상의 평가 케이스를 확보하여, 특정 입력 유형이 Dataset에서 완전히 누락되는 것을 방지했습니다.

축	값	개수	기준	상태
A. intent	`mute`	44	≥5	OK
A. intent	`allow`	14	≥5	OK
A. intent	`reject`	27	≥5	OK
B. time (ok=true 58건)	`duration`	38	≥5	OK
B. time	`until_absolute`	5	≥5	OK
B. time	`relative_delay`	5	≥5	OK
B. time	`daily`	5	≥5	OK
B. time	`weekly`	5	≥5	OK
C. target (ok=true 58건)	`all`	11	≥5	OK
C. target	`single_app`	29	≥5	OK
C. target	`multi_app`	5	≥5	OK
C. target	`content`	6	≥5	OK
C. target	`app_and_content`	7	≥5	OK

References

LangGraph 도입해야 한다면 내 프로젝트 서비스를 최적화시켜줄 수 있는 최적의 참조 논문은..?

Reasoning과 Action을 번갈아 수행하면서 외부 환경 / 도구와 상호작용하는 구조

같은 LLM이 Generator, Feedback Provider, Refiner 역할을 수행하면서 반복적으로 결과 개선
별도의 Supervised Training이나 RL 없이도 여러 task에서 one-shot generation보다 성능 개선 보고

자연어 reflection 형태로 memory에 저장하고 다음 attempt에 활용하는 구조
LangGraph에서 state / memory / retry loop를 설계할 때 굉장히 자연스럽게 연결

틀린 모델이 자기 답을 평가하면 틀릴 수 있음.
검색엔진, 코드 실행기 같은 외부 도구의 피드백을 사용해 검증

여러 reasoning candidate를 만들고 평가하면서 search / branching / backtracking

전체 문제를 먼저 작은 subtask로 나눈 뒤 실행
특히 Zero-shot CoT에서 발생하는 missing-step 등의 문제를 해결하려는 접근

reasoning과 tool observation을 분리

Tool Calling의 중요한 초기 연구
LLM이 언제 어떤 API를 사용할지를 결정하는 것 자체를 연구한 논문

같은 여러 Agent 간 interaction을 일반화한 프레임워크 연구
LLM, human input, tool을 조합한 customizable/conversable agent를 구성하고 다양한 conversation pattern을 정의

사용자 재질문 처리 전략

Sun, 16 Aug 2026 00:00:00 +0900

pending flag를 활용해 재질문 처리용 LLM 추가

backend/app/pending.py 추가

Sequence Diagram

이전 대화에서 사용자 질문 의도 파악 불가로 재질문 + 사용자 보충 질문 추가하는 경우

sequenceDiagram participant U as 사용자 participant App as Android PromptEngine participant API as FastAPI handle participant C as gpt-4o-mini 분류 participant E as gpt-4o 추출 U->>App: 카톡만 받아줘 App->>API: pending=false API->>E: extract E-->>API: ok=false + 재질문 API-->>App: ok=false App->>App: pendingOriginal 저장 U->>App: 1시간 App->>API: pending=true + pendingOriginal API->>C: 이전+이번 분류 C-->>API: supplement API->>E: 합친 prompt로 extract E-->>API: ok=true + 규칙 API-->>App: ok=true App->>App: 규칙 저장, pending clear

`classify_pending_turn` 함수

재질문 대기 중일 때, 이번 입력이 보충인지 새 명령인지 LLM으로 판별 한다.

pending_original: 재질문 전 사용자 명령
current_prompt: 재질문 후 사용자 입력
supplement: 이전 명령에 대한 보충 (예: 1시간)
new_command: 이전과 무관한 새 규칙

`resolve_extract_prompt` 함수

handle 앞에서 추출용 prompt 문자열을 만드는 진입점 역할을 한다.

prompt: 이번 사용자 입력
pending: 앱이 보낸 재질문 대기 여부
pending_original: 재질문 전 원문
(extract_prompt, classification): 추출 LLM에 넣을 문장 + 분류 결과 [None: 분류 안함]

추가 재질문 (Pending 처리) LLM이 실 기기에서 동작하는 지에 대한 테스트 진행 필요

baseline_v1_auto_map Evaluation 및 개선

Fri, 14 Aug 2026 00:00:00 +0900

Evaluation에서 확인된 부분을 기반으로 코드 수정

LangSmith를 기반으로 53문항의 테스트를 진행했고, 개선 수행.

에서는 여러 앱의 메타데이터도 같이 넣어서, context기반 cosine 유사도 계산 방식을 추천했으나, 메타데이터를 불러올 적절한 방법을 찾지 못함.

앱 관련 시스템 정보에는 메타데이터가 존재하지 않았음. 전부 null 필드.
Google Play Store에서 API 형태로 앱의 Description을 가져오는 것도 생각해 보았으나, 서비스가 너무 무거워질 것으로 예상되어 유의어 사전을 만드는 방식을 채택함.

코드 개선 전, Baseline 테스트 결과

총 53개 테스트 데이터
정답률 : 0.87

Error Case 1.

“카톡 2분만 받지마”

output
- “ok”: false
ground truth
- 현재 시간부터 2분동안 카톡을 받지 않도록 설정함.
피드백
- 시스템 프롬프트에 현재 시간이 정의되어 있지 않으면 현재 시간 부터라는 내용을 추가해 넣어줘야 할 거 같음.

Error Case 2.

“지금부터 1시간 문자만 받아줘”

output
- 문자 앱이 아닌 com.samsung.android.mdecservice 다른 앱의 cosine 유사도가 가장 높았고, 이 마저도 0.5 이하여서 ok=false 반환.
ground truth
- packages에 “com.samsung.android.messaging"이 담겨야 함.
피드백
- Cosine 유사도 판단 오류. “문자"와 “메시지"의 코사인 유사도가 낮게 나옴.

Error Case 3.

“지금부터 2시간 문자 스팸 알림 받지마”

output
- name 필드는 비어있고, content=[“문자”, “스팸”]
ground truth
- name=“메시지”, content=“스팸” 이 담겨야 함.
피드백
- 스팸이 name인지 앞서 나온 “문자"에 대한 “스팸"인지 확인할 수 있어야 함.

Error Case 4.

“지금부터 2시간 문자에서 ‘스팸’이라는 단어가 들어간 알림 받지마”

output
- 문자 앱이 아닌 com.samsung.android.mdecservice 다른 앱의 cosine 유사도가 가장 높았고, 이 마저도 0.5 이하여서 ok=false 반환.
ground truth
- packages에 “com.samsung.android.messaging"이 담겨야 함.
피드백
- Cosine 유사도 판단 오류. “문자"와 “메시지"의 코사인 유사도가 낮게 나옴.

Error Case 5.

“지금부터 2시간 플레이스토어 업데이트 알림 받지마”

output
- com.android.vending 앱이 아닌 com.samsung.android.smartsuggestions 다른 앱의 cosine 유사도가 가장 높았음. 즉, 잘못된 앱의 이름을 설정함.
ground truth
- packages에 “com.android.vending"이 담겨야 함.
피드백
- Cosine 유사도 판단 오류.

Error Case 5. [제외 케이스]

“지금부터 12시간 카톡 홍보, 프로모션이나 카드 알림은 띄우지마”

output
- name=“카카오톡”, content=“홍보, 프로모션, 카드” 가 들어감.
ground truth
- 현재 구조로는 해결이 불가능. ok=false
피드백
- 아직 해결 불가능.

Error Case 6.

“지금부터 5분 카톡 메세지 알림 받지마”

output
- name=“카카오톡”, content=“메세지” 가 들어감.
ground truth
- “카톡 메세지” 라고 말을 해도, 사실상 “카톡"을 의미하는 것이므로, name=“카카오톡” 이고 content는 비워야 함.
피드백
- 추출 오류.

문제점

“다른 기기에서도 전화/문자하기”(“com.samsung.android.mdecservice”) 와 “메시지”(“com.samsung.android.messaging”)가 있을 때, “문자"라는 단어가 “메시지"에 매핑되도록 하려면 어떻게 해야 하나?
“퍼스널 데이터 인텔리전스”(“com.samsung.android.smartsuggestions”) 와 “Play 스토어”(“com.android.vending”)가 있을 때, “플레이스토어"라는 단어가 “Play 스토어"에 매핑되도록 하려면 어떻게 해야 하나?

나의 해결책

처음에는 사이트에서 관련 메타데이터를 찾을 수 있는 방법을 고민함.
- 하지만 해당 필드가 전부 비어있는 값으로 나와 사용할 수 없었음.
- 따라서 유의어 사전 을 만드는 방법을 채택함.
  1. LLM이 뽑은 **앱 이름(name, “문자”)**으로 찾음
  2. 유의어 사전에 그 그룹 단어를 [“문자”, “메시지”, “SMS”, …] 로 확장
  3. (확장된 각 단어) X (설치 앱 각 라벨) : Cosine
  4. 각 앱마다 그 중 가장 높은 점수로 대표
  5. 전 앱 중 최고 + Threshold 로 최종 package 결정
시스템 프롬프트 few-shot learning 추가

...
- **"N분(만/동안/간) …" 처럼 기간만 있고 시작 시각이 없으면 → 지금부터. delivery=현재, expires=현재+N분**
 - 예: "카톡 2분만 받지마", "카톡 5분동안 받지마" 모두 현재부터.
...

코드 개선 이후

정답률 : 0.91

“매일 밤 10시부터 새벽 4시까지 조용히”

“매일 밤 10시부터 아침 6시까지 모든 알림 받지마”

주기성 명령의 경우 delivery와 expires 시간 계산에서 예측값과 실제값이 다르게 나옴. 하지만 이것이 결과에는 영향을 주지 않음
- 프롬프트 변경을 통해 해결함.
  - 구간 전: 다음 회차
  - 구간 안: 진행 중 회차
  - 구간 끝남: 다음 밤 회차
  - 지난 회차 금지. overrnight면 expires = delivery + 1

LangSmith를 활용한 Evaluation 설계

Wed, 12 Aug 2026 00:00:00 +0900

Phoenix 기반 DeepLearningAI의 강의 코드를 참조해, 동일한 로직을 LangSmith로 구현함

Evaluation 설명

기존 시스템은 Kotlin 기반 Android 앱 내부의 PromptEngine.kt에서 자연어 입력을 LLM에 전달하고, Function Calling 결과를 바탕으로 알림 규칙을 생성하는 구조였다.

하지만 Android 플랫폼 로직과 LLM Extraction 로직이 하나의 코드에 강하게 결합되어 있어, LLM 성능만 독립적으로 평가하거나 Prompt 변경에 따른 성능 변화를 반복적으로 검증하기 어려운 구조 였다.

이에 기존 PromptEngine.kt에서 수행하던 자연어 조건 추출 로직을 분리하여, FastAPI + LangChain 기반의 AI Backend 로 이전하였다.

이를 통해 Android 앱은 사용자 입력을 AI Backend로 전달하고 결과를 받아 실제 알림 규칙으로 저장하는 역할에 집중하고, AI Backend에서는 LLM 호출, Function Calling, 결과 후처리 및 Evaluation을 독립적으로 수행할 수 있도록 구조를 분리하였다.

FastAPI 기반 AI Backend 부분 설명

FastAPI 기반 AI Backend의 핵심 로직은 크게 다음 4단계 로 구성하였다.

시스템 프롬프트 few shot learning 관련 코드
현재 시간을 지정해 function calling용 Tool Schema 리스트를 return 해주는 코드
LLM의 추론으로 반환된 Function Calling 결과를 내 서비스에서 사용하기 쉽도록 후처리하는 코드
메인 처리 로직 : (사용자 프롬프트, 현재 시간) 입력 -> (targetFixed, condition 포함한 Response Json) 반환

AI Backend 코드에 대한 Kotlin 연결부 : FastAPI LLM 서버에 요청하고 결과를 기존 Android 규칙 시스템에 연결

LangSmith를 활용한 LLM 실행 추적

LangSmith를 활용해서 현재 LangChain 기반 LLM Function Calling을 추적 했다.

handle 함수안의 두 ChatOpenAI.invoke 함수를 자동으로 추적하고 있는 것을 확인할 수 있었다!

Code-based Evaluation 설계 과정

evals 폴더 생성 후, 평가에 사용할 샘플 5개 JSON 데이터셋(input, output) 생성
dataset_upload.py : Jsonl 확장자 파일에서 정의한 데이터셋을 LangSmith Dataset에 업로드
System Few Shot 부분도 전체적으로 어떻게 프롬프팅 했는지 점검해봐야 함.
evaluators.py 파일과 run_experiment.py 파일 생성해서 LangSmith 기반 테스트 진행함. (정답률 : 100%, 샘플 5개 적용)

Evaluators.py 코드에 대해서..

def extract_rule_correctness(
 outputs: dict,
 reference_outputs: dict,
) -> dict:

 """
 ExtractRule JSON 정답 일치도 (binary code metric).
 LangSmith evaluate()가 Example마다 호출:
 outputs ← Target(handle) 반환값
 reference_outputs ← Dataset example.outputs
 Returns:
 key/score 형태 dict — UI 지표명과 0~1 점수
 comment — 필드별 pass/fail (디버깅용)

 delivery/expires 는 currentTime이 고정이므로 ISO 문자열 exact match.
 """

 pred = outputs or {}
 exp = reference_outputs or {}
 checks: dict[str, bool] = {}

 # ok (성공/실패) — router 성격
 checks["ok"] = bool(pred.get("ok")) == bool(exp.get("ok"))

 # 정답이 실패면 구조 필드 없음 → ok만 채점
 # 예: "카톡만 받아줘" (시간 없음) → ok=false
 if not exp.get("ok"):
 return {
 "key": "extract_rule_correctness",
 "score": 1.0 if checks["ok"] else 0.0,
 "comment": str(checks),
 }

 # 성공 정답 → targetFixed / condition 필드 비교
 # 정답에 있는 키만 검사 (부분 reference 허용)
 pt = pred.get("targetFixed") or {}
 et = exp.get("targetFixed") or {}
 pc = pred.get("condition") or {}
 ec = exp.get("condition") or {}

 if "mute" in et:
 checks["mute"] = bool(pt.get("mute")) == bool(et.get("mute"))
 if "name" in et:
 checks["name"] = _as_set(pt.get("name")) == _as_set(et.get("name"))
 if "content" in et:
 checks["content"] = _as_set(pt.get("content")) == _as_set(et.get("content"))
 if "recurrence" in ec:
 checks["recurrence"] = pc.get("recurrence") == ec.get("recurrence")
 if "delivery" in ec:
 checks["delivery"] = _abs(pc.get("delivery")) == _abs(ec.get("delivery"))
 if "expires" in ec:
 checks["expires"] = _abs(pc.get("expires")) == _abs(ec.get("expires"))

 passed = all(checks.values()) if checks else False

 return {
 "key": "extract_rule_correctness",
 "score": 1.0 if passed else 0.0,
 "comment": str(checks),
 }

LangSmith에서 Target(handle) 반환값과 Dataset example.outputs 의 결과값을 비교해 0, 1 점(binary)으로 수치화함.
handle 함수의 결과값 JSON 필드는 예상과 정확하게 나와야 하기 때문에, Code Based Evaluation 을 진행함.

Dataset 생성

예전 학부연구생 생활하면서, 같은 연구실 동기들에게 받은 32개의 예시에는 ok=False가 너무 많아 평가가 편향될 것으로 예상되어, 10개로 줄였다.
ok = True 는 40개 / ok = False 는 10개로 개수를 맞춰 테스트를 진행할 예정이다.
본 Evaluation에서는 사용자 자연어 요청으로부터 앱, 콘텐츠, 알림 허용/차단 및 시간 조건을 구조화된 JSON으로 정확하게 추출하는지를 검증하며, 콘텐츠의 의미적 분류 정확도는 평가 범위에서 제외 한다.

의미적 분류 정확도는 현재 오류로 검증하지 않았지만, 개선 사항임.
extra_rule_correctness = 0.76 : 왜 이 테스트 결과값이 나왔는지 점검 해봐야 한다.

전체 NotiLLM Schedule 및 Architecture 설계

Tue, 11 Aug 2026 00:00:00 +0900

Schedule

단순히 기능을 추가하는 방식이 아니라, 측정 가능한 기준을 세우고 반복적으로 개선하는 과정을 중심으로 프로젝트를 진행했습니다.

아래와 같이 단순한 LLM 기능 구현을 넘어, Evaluation - Optimization - Validation - Production 으로 이어지는 AI Engineering 전 과정을 경험하는 것을 목표로 합니다.

순서	할 일	핵심 산출물	키우는 역량
1	현재 시스템 Baseline 고정	v1 구조/성능 기준	System Design
2	Evaluation Dataset 구축	Ground Truth Dataset	LLM Evaluation
3	자동 Evaluation 구현	평가 코드 + 지표	AI Engineering
4	Error Analysis	실패 유형/원인	Problem Solving
5	구조/Prompt 개선	v2	LLM Engineering
6	LangGraph 도입 검토	Stateful Agent	Agent Engineering
7	재평가 + 통계 검증	v1 vs v2 결과	Experimentation
8	Reliability 강화	Retry/Fallback/Validation	Production AI
9	실제 사용자 배포	테스트 사용자	Product Engineering
10	Analytics/Crashlytics 분석	실사용 데이터	Product Analytics
11	사용자 실험/A-B Test	Product 효과 검증	Experiment Design
12	최종 포트폴리오 정리	GitHub/Portfolio	취업

본격적인 Evaluation을 진행하기에 앞서서, 전체 Architecture를 먼저 설계해 어느 부분을 평가할 지에 대한 계획을 수립했습니다.

Baseline Ver.1 Architecture

Mermaid 목적 : Evaluation 시, 어느 Component에서 문제가 발생하는지 특정 하기 위함
ChatGPT-4o 모델로 Function Calling 전체 처리

flowchart TB user((User)) router["Router
GPT-4o w/
function calling"] user -->|chat command| router router -->|reply| user parse[Parse User Intent] choose[Choose mute / allow tool] router --> parse --> choose cond["extract_notification_condition
(time / recurrence)"] mute["extract_mute_target
(name / content)"] allow["extract_allow_target
(name / content)"] choose -->|function call| cond choose -->|function call| mute choose -->|function call| allow c1[Infer delivery / expires] c2[Set recurrence / window] m1[Extract mute apps / keywords] m2[Normalize app names] a1[Extract mute apps / keywords] a2[Normalize app names] cond --> c1 --> c2 mute --> m1 --> m2 allow --> a1 --> a2 c2 -.->|tool result| router m2 -.->|tool result| router a2 -.->|tool result| router merge["PromptEngine Merge
(target + condition)"] inj[Inject mute flag] build[Build target JSON] cm[ContextManager] mapPkg[Map app name to package] validate[Validate delivery before expires] save[Save rule to SQLite] db[(SQLite)] router -->|two JSONs| merge merge --> inj --> build --> cm --> mapPkg --> validate --> save save -->|Persist mode / apps / window| db classDef userNode fill:#7eb8da,stroke:#4a90b8,color:#fff classDef routerNode fill:#e8a0a0,stroke:#c07070,color:#222 classDef stepRed fill:#fff5f5,stroke:#c07070,color:#b33 classDef toolNode fill:#90c9a0,stroke:#5a9a6a,color:#222 classDef stepGreen fill:#f3faf5,stroke:#5a9a6a,color:#2a7a3a classDef dbNode fill:#a8d5b5,stroke:#5a9a6a,color:#222 class user userNode class router routerNode class parse,choose,c1,c2,m1,m2,a1,a2 stepRed class cond,mute,allow toolNode class merge,cm stepGreen class inj,build,mapPkg,validate,save stepGreen class db dbNode

평가 방식

각 Tools (extract_notification_condition, extract_mute_target, extract_allow_target) 에 따라 어떤 평가 방식을 사용해야 할까?

지금 평가 대상이 자유로운 자연어 답변이 아니라 스키마가 정해진 구조화된 JSON이고, 이미 Ground Truth를 만들 수 있다. 그래서 굳이 또 다른 LLM의 주관적 판단을 끼워 넣을 필요가 없다고 판단했습니다.

평가 방식 선정

Code-based evals 선정

Function Calling의 출력이 정해진 JSON Schema를 따르는 구조화된 데이터이므로, 각 필드를 Ground Truth와 직접 비교하는 Code-based Eval 방식 을 사용하기로 결정했습니다.

Function Calling이 현재 출력하는 JSON 필드

extract_notification_condition

{
"name": "extract_notification_condition",
"parameters": {
"type": "object",
"additionalProperties": false,
"properties": {
"delivery": {
"type": "object",
"additionalProperties": false,
"properties": {
"absolute": { "type": "string" }
},
"required": ["absolute"]
},
"activity": {
"type": ["string", "null"]
},
"location": {
"type": ["string", "null"]
},
"expires": {
"type": "object",
"additionalProperties": false,
"properties": {
"absolute": { "type": "string" }
},
"required": ["absolute"]
},
"recurrence": {
"type": "string",
"enum": ["none", "daily", "weekly"]
},
"days_of_week": {
"type": "array",
"items": {
"type": "integer"
}
},
"window_start": {
"type": ["string", "null"]
},
"window_end": {
"type": ["string", "null"]
}
},
"required": [
"delivery",
"activity",
"location",
"expires",
"recurrence",
"days_of_week",
"window_start",
"window_end"
]
}
}

extract_mute_target

{
"name": "extract_mute_target",
"parameters": {
"type": "object",
"additionalProperties": false,
"properties": {
"name": {
"type": "array",
"items": {
"type": ["string", "null"]
}
},
"content": {
"type": "array",
"items": {
"type": ["string", "null"]
}
}
},
"required": [
"name",
"content"
]
}
}

extract_allow_target

{
"name": "extract_allow_target",
"parameters": {
"type": "object",
"additionalProperties": false,
"properties": {
"name": {
"type": "array",
"items": {
"type": ["string", "null"]
}
},
"content": {
"type": "array",
"items": {
"type": ["string", "null"]
}
}
},
"required": [
"name",
"content"
]
}
}

Evaluation |

최종 버전 확정 및 초안 배포

Version 03 Architecture

Docker

AWS App Runner 운영 종료 이슈

중간 점검

NotiLLM 관련

기타

Version 간 결과 비교/분석

결과

v1 vs v2 vs v3

LangGraph 도입 검토 및 데이터셋 설계

LangGraph 도입하는 게 맞을까?

Version 01.

Version 02.

LangGraph 도입 시 (Routing 버전을 추가), 확인 사항

Evaluation Dataset 구성 기준

Coverage 확인

References

사용자 재질문 처리 전략

backend/app/pending.py 추가

classify_pending_turn 함수

resolve_extract_prompt 함수

baseline_v1_auto_map Evaluation 및 개선

코드 개선 전, Baseline 테스트 결과

Error Case 1.

Error Case 2.

Error Case 3.

Error Case 4.

Error Case 5.

Error Case 5. [제외 케이스]

Error Case 6.

코드 개선 이후

LangSmith를 활용한 Evaluation 설계

Evaluation 설명

FastAPI 기반 AI Backend 부분 설명

LangSmith를 활용한 LLM 실행 추적

Code-based Evaluation 설계 과정

Evaluators.py 코드에 대해서..

Dataset 생성

전체 NotiLLM Schedule 및 Architecture 설계

Schedule

Baseline Ver.1 Architecture

평가 방식

평가 방식 선정

Function Calling이 현재 출력하는 JSON 필드

References

`v1` vs `v2` vs `v3`

`LangGraph` 도입하는 게 맞을까?

LangGraph 도입 시 (`Routing 버전`을 추가), 확인 사항

`classify_pending_turn` 함수

`resolve_extract_prompt` 함수