Independent research notes on financial AI, model risk management, and agentic systems. Papers, decisions, failed experiments — from a three-person team building in public.https://bluethestyle.github.io/enhttps://bluethestyle.github.io/2026/05/12/ep8-honest-negatives-en/https://bluethestyle.github.io/2026/05/12/ep8-honest-negatives-en/Record from four months — how adaTT converged to a null effect at 13-task scale, why GradSurgery was rejected on VRAM overhead, Paper 3 WIP status, and real-data metrics pending after 2026-04-30. Why what did not work matters as much as what did.Tue, 12 May 2026 03:00:00 GMTfinai-buildadattgradsurgerynegative-resultsfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/12/ep8-honest-negatives-ko/https://bluethestyle.github.io/2026/05/12/ep8-honest-negatives-ko/4개월의 기록. 13개 태스크 환경에서 무의미한(Null) 수치로 수렴해버린 adaTT, 심각한 VRAM 오버헤드로 기각된 GradSurgery, 여전히 WIP인 Paper 3, 그리고 2026년 4월 30일부터 수집이 시작된 실 프로덕션 메트릭의 현재 상태. 작동하지 않은 것들이 작동한 것들만큼이나 중요한 이유를 기록한다.Tue, 12 May 2026 03:00:00 GMTfinai-buildadattgradsurgerynegative-resultsfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/08/ep7-distillation-serving-en/https://bluethestyle.github.io/2026/05/08/ep7-distillation-serving-en/Teacher is PLE, student is per-task LightGBM, serving is AWS Lambda. Why this combination, what happens when teacher-student fidelity fails, and the role division across the 5-agent Bedrock pipeline.Fri, 08 May 2026 03:00:00 GMTfinai-builddistillationservinglambdabedrockSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/08/ep7-distillation-serving-ko/https://bluethestyle.github.io/2026/05/08/ep7-distillation-serving-ko/교사(Teacher)는 무거운 PLE, 학생(Student)은 가벼운 태스크별 LightGBM, 그리고 서빙 인프라는 AWS Lambda. 왜 하필 이 조합이어야만 했는가? 교사-학생 간의 충실도(Fidelity)가 무너지면 어떤 심각한 일이 벌어지는지, 그리고 AWS Bedrock 위에서 춤추는 5-에이전트 파이프라인의 치열한 역할 분담을 해부한다.Fri, 08 May 2026 03:00:00 GMTfinai-builddistillationservinglambdabedrockSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/05/ep6-uncertainty-weighting-bug-en/https://bluethestyle.github.io/2026/05/05/ep6-uncertainty-weighting-bug-en/For weeks sigmoid gating seemed to beat softmax. Fixing an uncertainty-weighting implementation bug flipped the result. A case study in how a training-environment bug contaminates architectural conclusions.Tue, 05 May 2026 03:00:00 GMTfinai-builddebuggingmethodologyfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/05/ep6-uncertainty-weighting-bug-ko/https://bluethestyle.github.io/2026/05/05/ep6-uncertainty-weighting-bug-ko/몇 주 동안 Sigmoid 게이트가 Softmax를 이기는 것처럼 보였다. 그러나 불확실성 가중치(Uncertainty Weighting) 모듈의 사소한 부호 버그 하나가 수정되자 그 견고하던 결과가 하루아침에 뒤집혔다. 훈련 환경의 버그가 어떻게 거대한 아키텍처 결론을 조용히 오염시키는지를 보여주는 유의미한 사례 연구.Tue, 05 May 2026 03:00:00 GMTfinai-builddebuggingmethodologyfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/05/mrm-ep6-modular-adaptability-en/https://bluethestyle.github.io/2026/05/05/mrm-ep6-modular-adaptability-en/The early design temptation was a single ComplianceReporter class parametrised on jurisdiction. We rejected it after walking through what amendment-driven change would look like. The five separate generators, sitting on a regulation-agnostic substrate of audit log + XAI + retrieval, are the structural bet that pays off only when regulations actually start to move.Tue, 05 May 2026 03:00:00 GMTmrmmodularityregulationfinancial-aiai-basic-acteu-ai-actSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/05/mrm-ep6-modular-adaptability-ko/https://bluethestyle.github.io/2026/05/05/mrm-ep6-modular-adaptability-ko/한국 AI 기본법 시행령, EU AI Act 개정안, 미래의 미국 규제 프레임워크 — 이 모든 변화는 언젠가 현실이 될 것이다. 5개의 규제 산출물 생성기는 동일한 감사 로그 기반 위에서 동작하는 5개의 독립된 모듈이지, 매번 새로 작성해야 하는 5개의 문서가 아니다. 아키텍처의 모듈성이 왜 앞선 다섯 에피소드의 논의를 비로소 의미 있게 만드는 장기적인 베팅인지 살펴본다.Tue, 05 May 2026 03:00:00 GMTmrmmodularityregulationfinancial-aiai-basic-acteu-ai-actSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/01/ep5-data-integrity-hunt-en/https://bluethestyle.github.io/2026/05/01/ep5-data-integrity-hunt-en/Before any architecture debate — three chained label-leakage detections, the deterministic-leakage rationale behind the 18→13 task reduction, and the self-replicating features that surfaced across synthetic-data iterations v2→v3→v4.Fri, 01 May 2026 03:00:00 GMTfinai-builddata-integrityleakagefinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/01/ep5-data-integrity-hunt-ko/https://bluethestyle.github.io/2026/05/01/ep5-data-integrity-hunt-ko/화려한 아키텍처 논쟁에 뛰어들기 전에 반드시 풀어야만 했던 복잡한 문제들. 레이블 리키지(Label Leakage) 3건의 연쇄 탐지 과정, 18개에서 13개로 태스크를 축소해야만 했던 결정론적 리키지의 배경, 그리고 합성 데이터 반복 개선(v2→v3→v4) 과정에서 드러난 중요한 교훈을 다룬다.Fri, 01 May 2026 03:00:00 GMTfinai-builddata-integrityleakagefinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/01/mrm-ep5-rag-lancedb-en/https://bluethestyle.github.io/2026/05/01/mrm-ep5-rag-lancedb-en/We started with the idea that the audit log was a write-only archive. The first time a risk officer needed similar-case context inside a five-minute decision window, that idea broke. RAG over LanceDB is what came out of refusing to maintain two copies of the same source of truth — and what unlocked human oversight, fairness monitoring, and quarterly aggregation as queries on the same store.Fri, 01 May 2026 03:00:00 GMTmrmraglancedbauditretrievalfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/05/01/mrm-ep5-rag-lancedb-ko/https://bluethestyle.github.io/2026/05/01/mrm-ep5-rag-lancedb-ko/감사 로그는 단순한 쓰기 전용 데이터가 아니다. 질의 가능한 지식 베이스다. 운영 및 감사 검색 인프라를 컬럼형, 버전 인식, 시간 여행 기능이 결합된 RAG와 LanceDB로 구성한 이유를 설명한다. 그리고 그 결과로 인적 감독, 운영 파이프라인 위에서의 공정성 모니터링, 분기별 집계 문제가 어떻게 해결되는지 살펴본다.Fri, 01 May 2026 03:00:00 GMTmrmraglancedbauditretrievalfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/29/commentary-pia-disclosure-en/https://bluethestyle.github.io/2026/04/29/commentary-pia-disclosure-en/PIPA-grounded Privacy Impact Assessment and the Financial Services Commission's quarterly public-disclosure report, both delivered as automatic byproducts of the audit log rather than documents written from scratch. How they quietly ride on top of Ep 3's `log_*` tables, and what remains on the MRM committee's desk.Wed, 29 Apr 2026 03:00:00 GMTcommentarypiapipadisclosuremrmfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/29/commentary-pia-disclosure-ko/https://bluethestyle.github.io/2026/04/29/commentary-pia-disclosure-ko/PIPA 기반 개인정보 영향평가(PIA)와 금융위 공시용 분기 리포트가 서면 작성이 아니라 감사 로그의 자동 부산물로 떨어지는 구조. 두 산출물이 어떻게 Ep 3 의 `log_*` 테이블 위에 조용히 얹히는지, 그리고 MRM 위원회에는 무엇이 남는지.Wed, 29 Apr 2026 03:00:00 GMTcommentarypiapipadisclosuremrmfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/28/ep4-seven-experts-en/https://bluethestyle.github.io/2026/04/28/ep4-seven-experts-en/Why seven experts, why these seven. The cross-disciplinary scan with Gemini surfaced eleven fields; the feasibility review with Opus narrowed to DeepFM, Temporal Ensemble, HGCN, PersLay, Causal, LightGCN, and Optimal Transport.Tue, 28 Apr 2026 03:00:00 GMTfinai-buildarchitecturepleexpert-poolfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/28/ep4-seven-experts-ko/https://bluethestyle.github.io/2026/04/28/ep4-seven-experts-ko/왜 7명인가, 그리고 왜 하필 이 7명인가. 11개 학문 분야를 넓게 훑어보고, 엄격한 기술 검증을 거쳐 최종적으로 살아남은 DeepFM·Temporal·HGCN·PersLay·Causal·LightGCN·OT 7개 전문가의 치열한 도출 과정을 다룬다.Tue, 28 Apr 2026 03:00:00 GMTfinai-buildarchitecturepleexpert-poolfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/28/mrm-ep4-xai-foundation-en/https://bluethestyle.github.io/2026/04/28/mrm-ep4-xai-foundation-en/Post-hoc XAI (SHAP, LIME) wobbled on us when we ran the cost and stability numbers. We chose architectural XAI instead — the gate weights of seven heterogeneous PLE experts as the explanation, with CEH attribution and Mahalanobis OOD as the second and third layers. FD-TVS is the operational scoring philosophy that grew out of fixing the on-prem per-product weights model.Tue, 28 Apr 2026 03:00:00 GMTmrmxaiexplainabilityplefd-tvsfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/28/mrm-ep4-xai-foundation-ko/https://bluethestyle.github.io/2026/04/28/mrm-ep4-xai-foundation-ko/사후적 XAI(SHAP·LIME)는 운영 환경에서 불안정하며 모델과도 분리되어 있다. 우리는 PLE의 7개 이종 전문가 모델 위에서 게이트 가중치 자체를 설명으로 활용하는 방식을 택했다. 추론 경로의 자연스러운 결과물로 매 예측의 근거를 확보하는 구조다. FD-TVS는 그 위에 얹어진 운영 스코어링 철학이다.Tue, 28 Apr 2026 03:00:00 GMTmrmxaiexplainabilityplefd-tvsfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/24/commentary-causal-guardrail-en/https://bluethestyle.github.io/2026/04/24/commentary-causal-guardrail-en/If MRM Ep 3's audit log guarantees *record integrity*, who judges whether *each individual prediction* is trustworthy? A prediction-level guardrail that detects OOD signals via Mahalanobis distance on the Causal Expert's latent space, and how it pairs with CEH attribution to fold into the audit trail.Fri, 24 Apr 2026 03:00:00 GMTcommentarycausalguardrailmrmpaper-3financial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/24/commentary-causal-guardrail-ko/https://bluethestyle.github.io/2026/04/24/commentary-causal-guardrail-ko/MRM Ep 3 의 감사 로그가 *기록의 무결성* 을 보증한다면, 각각의 개별 예측이 *신뢰할 만한가* 는 누가 판정하는가. Causal Expert 의 latent space 위에서 Mahalanobis 거리로 OOD 신호를 잡아내는 예측-단위 guardrail, 그리고 이것이 CEH attribution 과 쌍을 이뤄 감사 추적에 편입되는 방식.Fri, 24 Apr 2026 03:00:00 GMTcommentarycausalguardrailmrmpaper-3financial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/24/ep3-guardrails-en/https://bluethestyle.github.io/2026/04/24/ep3-guardrails-en/The mechanisms that kept three parallel AI-agent teams from breaking at integration — the CLAUDE.md constitution, the migration from a manual memory bank to Claude Code auto-memory, and the interface-key diff check run after every parallel session.Fri, 24 Apr 2026 03:00:00 GMTfinai-buildclaude-codearchitecturefinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/24/ep3-guardrails-ko/https://bluethestyle.github.io/2026/04/24/ep3-guardrails-ko/3명과 AI 에이전트들이 병렬로 달리면서도 통합 지점에서 시스템이 무너지지 않도록 지탱해 준 세 가지 장치들 — `CLAUDE.md` 기본 규약, 수동 메모리 뱅크에서 자동 기억(auto-memory)으로의 진화, 그리고 매 작업 직후에 수행되는 인터페이스 계약 검증 프로세스를 살펴본다.Fri, 24 Apr 2026 03:00:00 GMTfinai-buildclaude-codearchitecturefinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/24/mrm-ep3-chain-of-custody-en/https://bluethestyle.github.io/2026/04/24/mrm-ep3-chain-of-custody-en/Seven audit tables and an HMAC hash chain give you 'continuity of record'. But who verifies the record? The trap of the single-LLM auditor, multi-agent consensus with α/β/γ perspectives, a minority-report-that-never-gets-deleted design, and why AWS parallel voting and on-prem 2-round deliberation chose different paths.Fri, 24 Apr 2026 03:00:00 GMTmrmauditconsensussr-11-7regulationfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/24/mrm-ep3-chain-of-custody-ko/https://bluethestyle.github.io/2026/04/24/mrm-ep3-chain-of-custody-ko/7개 감사 테이블과 HMAC 해시 체인이 '기록의 연속성'을 보장한다면, 그 기록을 누가 검증하는가. 단일 LLM 판정의 함정과 다중 에이전트 컨센서스(α·β·γ) 구조, 소수 의견을 지우지 않는 설계, 그리고 AWS 병렬 투표와 온프렘 2-Round 심의가 서로 다른 방식을 택한 이유.Fri, 24 Apr 2026 03:00:00 GMTmrmauditconsensussr-11-7regulationfinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/21/ep2-ai-collaboration-en/https://bluethestyle.github.io/2026/04/21/ep2-ai-collaboration-en/Five phases, four tools — how Gemini, Claude Opus, Cursor, and Claude Code each took a specific slot (ideation / technical validation / scaffolding / implementation / paper writing). Why tool separation beat tool uniformity on both speed and quality.Tue, 21 Apr 2026 03:00:00 GMTfinai-buildclaude-codearchitecturefinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/21/ep2-ai-collaboration-ko/https://bluethestyle.github.io/2026/04/21/ep2-ai-collaboration-ko/Gemini, Claude Opus, Cursor, Claude Code를 프로젝트 5개 단계에 맞게 분업시킨 방식. 단일 도구 활용보다 단계별 목적에 맞춘 도구 분리가 개발 속도와 품질 측면에서 유리했던 이유를 살펴본다.Tue, 21 Apr 2026 03:00:00 GMTfinai-buildclaude-codearchitecturefinancial-aiSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/21/mrm-ep2-champion-challenger-en/https://bluethestyle.github.io/2026/04/21/mrm-ep2-champion-challenger-en/A Monday-3am walkthrough of `_decide_promotion()` — the 4-step short-circuit ladder (force-promote, bootstrap, fidelity floor, competition) that replaces a 2-to-4-week MRM committee cycle with seconds, and every outcome writes one HMAC-signed audit entry.Tue, 21 Apr 2026 03:00:00 GMTmrmsr-11-7regulationfinancial-aiauditSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/21/mrm-ep2-champion-challenger-ko/https://bluethestyle.github.io/2026/04/21/mrm-ep2-champion-challenger-ko/월요일 새벽 3시 `_decide_promotion()` 안에서 일어나는 일 — 4단계 단락 평가 사다리(force-promote · bootstrap · fidelity floor · competition)가 2-4주짜리 MRM 위원회 주기를 수초로 대체하고, 모든 판정이 HMAC 서명 감사 엔트리를 남긴다.Tue, 21 Apr 2026 03:00:00 GMTmrmsr-11-7regulationfinancial-aiauditSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/20/adatt-4-training-loop-loss-weighting-optimizer-en/https://bluethestyle.github.io/2026/04/20/adatt-4-training-loop-loss-weighting-optimizer-en/The adaTT sub-thread closes — 2-Phase Training Loop, Loss Weighting strategies (Uncertainty / GradNorm / DWA), Optimizer + Scheduler configuration, CGC–adaTT synchronization, memory and performance notes. With the adaTT tech reference PDF attached.Mon, 20 Apr 2026 06:00:00 GMTstudy-threadadatttraining-looploss-weightingoptimizerspecsSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/20/adatt-4-training-loop-loss-weighting-optimizer-ko/https://bluethestyle.github.io/2026/04/20/adatt-4-training-loop-loss-weighting-optimizer-ko/adaTT 서브스레드 마무리 — 2-Phase Training Loop, Loss Weighting 전략 (Uncertainty · GradNorm · DWA), Optimizer · Scheduler 설정, CGC ↔ adaTT 동기화, 메모리·성능 노트. adaTT 기술 참조서 PDF 첨부.Mon, 20 Apr 2026 06:00:00 GMTstudy-threadadatttraining-looploss-weightingoptimizerspecsSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/20/adatt-3-transfer-loss-group-prior-schedule-en/https://bluethestyle.github.io/2026/04/20/adatt-3-transfer-loss-group-prior-schedule-en/adaTT's Transfer Loss in full — transfer weights with the G-01 clamp and target-task masking, task-group Prior matrix with Prior Blend Annealing, the 3-Phase Schedule (Warmup → Dynamic → Frozen), and the Negative Transfer detection-and-block mechanism.Mon, 20 Apr 2026 05:00:00 GMTstudy-threadadatttransfer-lossgroup-priorschedulenegative-transferSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/20/adatt-3-transfer-loss-group-prior-schedule-ko/https://bluethestyle.github.io/2026/04/20/adatt-3-transfer-loss-group-prior-schedule-ko/adaTT Transfer Loss 전체 — 전이 가중치와 G-01 Clamp·target 미존재 태스크 마스킹, 태스크 그룹 기반 Prior 행렬과 Prior Blend Annealing, 3-Phase Schedule (Warmup → Dynamic → Frozen), Negative Transfer 감지·차단 메커니즘.Mon, 20 Apr 2026 05:00:00 GMTstudy-threadadatttransfer-lossgroup-priorschedulenegative-transferSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/20/adatt-2-task-affinity-gradient-cosine-en/https://bluethestyle.github.io/2026/04/20/adatt-2-task-affinity-gradient-cosine-en/TaskAffinityComputer — the engine that actually measures task-to-task affinity. Gradient cosine similarity with EMA smoothing, why cosine over Euclidean, and the `torch.compiler.disable`-handled gradient extraction path.Mon, 20 Apr 2026 04:00:00 GMTstudy-threadadattgradientcosine-similarityemaSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/20/adatt-2-task-affinity-gradient-cosine-ko/https://bluethestyle.github.io/2026/04/20/adatt-2-task-affinity-gradient-cosine-ko/TaskAffinityComputer — 태스크 간 친화도를 실제로 측정하는 엔진. Gradient cosine similarity 수식과 EMA 평활화, 유클리드 거리 대신 코사인을 쓰는 이유, 그리고 `torch.compiler.disable` 로 처리한 gradient 추출 경로.Mon, 20 Apr 2026 04:00:00 GMTstudy-threadadattgradientcosine-similarityemaSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/20/adatt-1-adaptive-tower-motivation-en/https://bluethestyle.github.io/2026/04/20/adatt-1-adaptive-tower-motivation-en/The adaTT sub-thread opens — why fixed task towers hit a ceiling in multi-task learning, how Transformer Attention reframes the adaptive-tower problem, and where adaTT sits in the lineage of conditional computation and hypernetworks.Mon, 20 Apr 2026 03:00:00 GMTstudy-threadadattattentionhypernetworkmtlSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/20/adatt-1-adaptive-tower-motivation-ko/https://bluethestyle.github.io/2026/04/20/adatt-1-adaptive-tower-motivation-ko/adaTT 서브스레드 시작 — 멀티태스크 학습에서 고정 타워가 닿는 한계, Transformer Attention 이 적응형 타워 문제를 재해석하는 방식, 그리고 조건부 계산·Hypernetwork 계보에서 adaTT 의 위치.Mon, 20 Apr 2026 03:00:00 GMTstudy-threadadattattentionhypernetworkmtlSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-6-interpretability-uncertainty-specs-en/https://bluethestyle.github.io/2026/04/19/ple-6-interpretability-uncertainty-specs-en/The PLE study sub-thread closes — Sparse Autoencoder for expert interpretability, Evidential Deep Learning for per-prediction uncertainty, the full 18-task spec and paper-vs-implementation comparison. With the full 56-page PLE tech reference PDF attached.Sun, 19 Apr 2026 08:00:00 GMTstudy-threadplesaeuncertaintyevidentialspecsSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-6-interpretability-uncertainty-specs-ko/https://bluethestyle.github.io/2026/04/19/ple-6-interpretability-uncertainty-specs-ko/PLE 서브스레드 마지막 — 전문가 해석성을 위한 Sparse Autoencoder, 예측별 불확실성을 정량화하는 Evidential Deep Learning, 18개 태스크 전체 사양과 논문 대 구현 비교. 56쪽 PLE 기술 참조서 PDF 첨부.Sun, 19 Apr 2026 08:00:00 GMTstudy-threadplesaeuncertaintyevidentialspecsSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-5-basket-logit-tower-en/https://bluethestyle.github.io/2026/04/19/ple-5-basket-logit-tower-en/Once routing is stable, three decisions remain on the task-private side — per-task expert memory (GroupTaskExpertBasket), explicit cross-task dependencies (Logit Transfer's three modes), and loss balance for the final Task Tower.Sun, 19 Apr 2026 07:00:00 GMTstudy-threadplelogit-transfertask-towergroup-encoderSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-5-basket-logit-tower-ko/https://bluethestyle.github.io/2026/04/19/ple-5-basket-logit-tower-ko/라우팅이 안정된 뒤 task-private 쪽에 남는 세 결정 — 태스크별 전용 전문가 메모리(GroupTaskExpertBasket), 태스크 간 명시적 의존(Logit Transfer 3 모드), 그리고 최종 Task Tower 의 손실 균형.Sun, 19 Apr 2026 07:00:00 GMTstudy-threadplelogit-transfertask-towergroup-encoderSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-4-cgc-hmm-routing-en/https://bluethestyle.github.io/2026/04/19/ple-4-cgc-hmm-routing-en/Two problems surface when the seven heterogeneous experts actually train — dim-asymmetry collapse toward the 128D expert, and customers not living at one time scale. The response: a two-stage CGC gate (CGCLayer + CGCAttention) plus HMM Triple-Mode routing.Sun, 19 Apr 2026 06:00:00 GMTstudy-threadplecgchmmregularizationSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-4-cgc-hmm-routing-ko/https://bluethestyle.github.io/2026/04/19/ple-4-cgc-hmm-routing-ko/7명 이종 전문가를 실제로 학습시키면 동시에 두 문제가 드러난다 — 128D 전문가로 쏠리는 dim-asymmetry collapse 와 고객이 단일 시간 스케일에 살지 않는다는 사실. 해법은 2단계 CGC 게이트 (CGCLayer + CGCAttention) 와 HMM Triple-Mode 라우팅.Sun, 19 Apr 2026 06:00:00 GMTstudy-threadplecgchmmregularizationSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-3-heterogeneous-expert-pool-en/https://bluethestyle.github.io/2026/04/19/ple-3-heterogeneous-expert-pool-en/Why seven experts, and why these seven — seat by seat, the mathematical gap each one fills (DeepFM · Temporal · HGCN · PersLay · LightGCN · Causal · Optimal Transport), the alternatives considered, and why each specific one won.Sun, 19 Apr 2026 05:00:00 GMTstudy-threadpleexpert-poolhmmshared-expertsSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-3-heterogeneous-expert-pool-ko/https://bluethestyle.github.io/2026/04/19/ple-3-heterogeneous-expert-pool-ko/왜 7명인가, 왜 이 7명인가 — 자리별로 어떤 수학적 빈틈을 메우는지 (DeepFM · Temporal · HGCN · PersLay · LightGCN · Causal · Optimal Transport), 어떤 후보들을 밀어냈고 왜 이 사람이 뽑혔는지 하나씩.Sun, 19 Apr 2026 05:00:00 GMTstudy-threadpleexpert-poolhmmshared-expertsSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-2-progressive-layered-extraction-en/https://bluethestyle.github.io/2026/04/19/ple-2-progressive-layered-extraction-en/Picking up from MMoE's Expert Collapse — PLE's three chained decisions: explicit Shared/Task expert separation, the heterogeneous Shared Expert pool, and the CGC gate that learns how much of each expert to use per task.Sun, 19 Apr 2026 04:00:00 GMTstudy-threadplecgctang2020mtlSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-2-progressive-layered-extraction-ko/https://bluethestyle.github.io/2026/04/19/ple-2-progressive-layered-extraction-ko/MMoE 의 Expert Collapse 가 끝난 지점에서 시작 — PLE 가 이어서 내린 세 가지 결정: Shared/Task Expert 명시적 분리, 이종 Shared Expert 풀, 태스크마다 각 전문가를 얼마나 쓸지 학습하는 CGC 게이트.Sun, 19 Apr 2026 04:00:00 GMTstudy-threadplecgctang2020mtlSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-1-mtl-evolution-en/https://bluethestyle.github.io/2026/04/19/ple-1-mtl-evolution-en/Multi-task learning from the root motivation — why one recommender has to predict dozens of targets at once, the mathematical face of Negative Transfer, and where Shared-Bottom and MMoE each break down. Setup post for PLE's fix.Sun, 19 Apr 2026 03:00:00 GMTstudy-threadplemmoemtlshared-bottomSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/19/ple-1-mtl-evolution-ko/https://bluethestyle.github.io/2026/04/19/ple-1-mtl-evolution-ko/멀티태스크 학습의 뿌리 — 추천 시스템이 왜 수십 개 타겟을 동시에 예측해야 하는가, Negative Transfer 의 수식적 모습, Shared-Bottom 과 MMoE 가 각각 어디서 무너지는가. PLE 가 풀어낸 지점으로 가기 전의 도입편.Sun, 19 Apr 2026 03:00:00 GMTstudy-threadplemmoemtlshared-bottomSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/18/ep1-premise-ko/https://bluethestyle.github.io/2026/04/18/ep1-premise-ko/Airflow DAG 80개 규모의 ALS 추천기를 3명의 팀원과 데스크톱 GPU 한 대로 대체하게 된 배경. 기존 시스템의 설명 가능성 및 다중 태스크 처리 한계가 아키텍처 선택을 어떻게 규정했는지 살펴본다.Sat, 18 Apr 2026 03:00:00 GMTfinai-buildarchitectureclaude-codefinancial-aipleSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/18/ep1-premise-en/https://bluethestyle.github.io/2026/04/18/ep1-premise-en/What three people with one desktop GPU set out to replace — an 80-DAG ALS recommender that could not explain itself and could not scale past one task — and how that starting constraint shaped every later architectural choice.Sat, 18 Apr 2026 03:00:00 GMTfinai-buildarchitectureclaude-codefinancial-aipleSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/18/mrm-ep1-architecture-ko/https://bluethestyle.github.io/2026/04/18/mrm-ep1-architecture-ko/검증 우선의 MRM 체계는 모델이 LLM 에이전트 파이프라인으로 전환될 때 한계를 가진다. 다단계 실패 모드와 검증 주기 내 드리프트 등의 문제를 해결하기 위해, MRM 의무를 사후 검토 캘린더가 아니라 아키텍처 자체에 반영해야 하는 이유를 설명한다.Sat, 18 Apr 2026 03:00:00 GMTmrmsr-11-7regulationfinancial-aiauditSeonkyu Jeonghttps://bluethestyle.github.io/2026/04/18/mrm-ep1-architecture-en/https://bluethestyle.github.io/2026/04/18/mrm-ep1-architecture-en/The validation-first view of Model Risk Management breaks once the model becomes an LLM agent pipeline — multi-step attack surface, non-traditional failure modes, drift between validation cycles. Push MRM into the architecture itself, not the review calendar.Sat, 18 Apr 2026 03:00:00 GMTmrmsr-11-7regulationfinancial-aiauditSeonkyu Jeong