제약회사 연구원의 블로그

‘모르기 때문에 안전했던 시기’가 끝난다1️⃣ 문제 ①: “과잉 해석(over-interpretation)”의 폭발기존:대부분의 feature는 unknown해석 가능한 신호만 제한적으로 사용보수적 결론 가능bottleneck 붕괴 이후:수천 개 feature에 구조 class 추정pathway 연결 가능biological 의미 자동 생성👉 문제는 여기서 시작됩니다.위험한 문장 예시“이 환자군에서 산화 스트레스 증가가 관찰됨”“지질 대사 이상이 암 진행과 관련됨”이 문장들이:실제 causal 관계가 아니라annotation 알고리즘의 편향일 가능성2️⃣ 문제 ②: False plausibility의 증가Foundation model 또는 고급 annotation 시스템은“그럴듯한 설명”을 매우 잘 만들..

실험 도구가 아니라 “검증된 시스템”이 되기 위해1️⃣ 모델의 역할 정의: “보조”인지 “결정”인지SOP에 포함되기 위해 가장 먼저 명확해야 할 것:모델 역할 분류역할설명규제 부담보조 도구QC flag, 이상치 탐지낮음의사결정 지원재분석 권고, batch reject 제안중간자동 결정결과 승인/거부매우 높음👉 대부분의 조직은 보조 도구 단계에서 시작해야 현실적입니다.2️⃣ 입력 데이터 범위와 전처리 고정AI 모델은 입력이 달라지면 결과가 달라집니다.SOP에 포함되려면 다음이 고정되어야 합니다.허용 데이터 형식 (raw, centroid, mzML 등)전처리 방법 (smoothing, baseline correction)feature extraction 방식normalization 방법👉 “데이터가 조..

rule 기반 판단에서 ‘패턴 이해’로의 이동1️⃣ 기존 LC-MS 해석의 출발점: “이 피크는 무엇인가?”전통적인 LC-MS 해석은 항상 단일 질문에서 시작합니다.이 피크의 m/z는 무엇인가RT가 맞는가fragment가 reference와 일치하는가library hit score가 기준을 넘는가즉, 해석의 구조는 늘 이랬습니다.관측 → 기준 대조 → 일치 여부 판단이 방식은 정확하지만, 근본적인 한계를 갖습니다.2️⃣ 기존 방식의 구조적 한계 (annotation bottleneck의 본질)① reference가 없는 것은 해석 불가novel metaboliteunexpected fragmentin-source fragmentationmatrix-specific adduct→ “모르겠다”로 끝남② 피크..

– “판정”이 아니라 “조기 징후 탐지”로 위치를 바꿔라1️⃣ QC fail은 ‘사후 판정’, anomaly detection은 ‘사전 신호’다먼저 개념부터 분리해야 합니다.QC fail의 본질명확한 acceptance criteriabinary decision (pass / fail)규제 문서에 직접 들어감되돌릴 수 없는 판정Anomaly detection의 본질정상 패턴 대비 상대적 이탈연속적인 위험 신호판단 보조용 정보되돌릴 수 있는 경고👉 이 둘을 같은 레벨에 두는 순간,anomaly detection은 규제적으로 즉시 탈락합니다.2️⃣ 실패하는 팀의 공통 착각: “AI가 QC를 더 잘할 것”PoC에서 자주 나오는 문장:“기존 QC rule보다 anomaly detection이 더 민감합니다”이..

– 성능보다 먼저 필요한 건 “이 결과를 누가 책임질 수 있는가”다1️⃣ LC-MS 분석은 ‘맞추는 기술’이 아니라 ‘설명해야 하는 기술’이다일반적인 AI 적용 사례에서는정확도가 어느 정도 높으면 실사용이 가능하다.하지만 LC-MS는 다르다.결과 하나가 임상 의사결정으로 이어지고규제 문서에 포함되며수년 뒤 audit에서 다시 꺼내진다즉 LC-MS 결과는 항상 이 질문을 동반한다.“왜 이렇게 나왔는가?”Explainable AI가 없으면이 질문에 답할 방법이 없다.👉 LC-MS 분석에서 설명 불가능한 결과는틀린 결과와 동일한 취급을 받는다.2️⃣ QA와 규제는 ‘모델’을 보지 않고 ‘판단 경로’를 본다현장에서 자주 벌어지는 장면이 있다.데이터 사이언티스트:“이 모델은 accuracy가 98%입니다”QA의..

모델은 맞았지만, 아무도 책임질 수 없었다1️⃣ PoC의 목표 자체가 잘못 설정된다대부분의 AI-LC-MS PoC는 이렇게 시작한다.“AI로 이거 할 수 있나요?”그래서 PoC의 성공 기준이:accuracy 몇 %anomaly detect 성공사람보다 잘 맞춤같은 기술 데모 수준에 머문다.하지만 운영 단계의 질문은 완전히 다르다.이 결과로 무엇을 결정할 것인가?이 판단의 책임자는 누구인가?이 결과가 틀렸을 때 어디까지 허용되는가?👉 PoC는 “가능한가?”에 답하지만,👉 운영은 “써도 되는가?”에 답해야 한다.이 간극을 처음부터 설계하지 않으면PoC는 성공해도 프로젝트는 멈춘다.2️⃣ AI가 ‘판단’을 대신하도록 설계된다PoC 단계에서 가장 흔한 설계 오류는 이거다.“AI가 batch 이상 여부를 판단..

코드를 설명하지 말고, “통제되고 있다”는 느낌을 만들어라1️⃣ QA가 R 자동화를 불신하는 이유부터 직시해야 한다QA가 R 자동화 결과를 처음 볼 때, 머릿속에는 거의 항상 이 질문들이 떠 있다.이 계산이 항상 같은 방식으로 수행된다는 걸 어떻게 보장하지?누가 언제 로직을 바꿀 수 있고, 바꾸면 어떻게 알지?이 결과가 틀렸을 때 추적 가능한 흔적이 남아 있나?이 자동화가 판단을 대신하지는 않나?중요한 사실은 이거다.👉 QA는 R을 싫어하지 않는다.👉 QA는 통제되지 않는 판단을 싫어한다.그래서 문서의 목적은“이 스크립트가 얼마나 똑똑한가”가 아니라👉 “이 자동화는 사람보다 더 예측 가능하다”는 걸 보여주는 데 있다.2️⃣ 실패하는 문서의 공통점: 코드 설명부터 시작한다QA 신뢰를 못 얻는 문서들은..

값을 비교하지 말고, “정상이라고 말할 수 있는 범위”를 비교하라1️⃣ Batch 비교 자동화가 실패하는 이유는 거의 하나다자동화를 시작할 때, 대부분 이렇게 묻는다.“이 batch가 이전 batch랑 얼마나 다른가요?”이 질문 자체가 이미 함정이다.왜냐하면:이전 batch는 기준이 아니고다르다는 말에는 방향도, 의미도 없기 때문이다.그래서 실패하는 자동화는:batch A vs batch B값 차이 %, fold changethreshold 초과 여부같은 숫자 비교에 머문다.👉 하지만 batch 비교의 목적은“다른지”가 아니라“정상 범위 안에 있는지”다.2️⃣ 비교 기준의 출발점은 ‘reference batch’가 아니다많은 조직이 이렇게 시작한다.“Golden batch랑 비교하자”“지난 run 평균..