Palantir Foundry(4) - 온톨로지 Deep Dive, Model

Palantir Learn 의 파운드리 기초 과정 을 따라가며 공부하고 정리한 기록입니다.

데이터를 깐 다음 단계는 모델입니다. 이번 글의 결론은 짧게 한 줄로 두고 시작합니다.

모델을 학습시키는 건 어디서나 합니다. Foundry 가 풀고 있는 건 학습된 모델이 어떻게 운영 워크플로로 들어가서, 어떻게 계속 학습되며, 어떻게 신뢰받는가라는 그 다음 문제입니다.

모델은 Foundry 안에만 살지 않습니다

먼저 짚어둘 점 한 가지. Foundry 가 모델 빌딩 도구를 강요하지 않습니다.

• AWS SageMaker
• DataRobot
• IBM Watson
• Vertex AI

이미 다른 환경에서 학습된 모델을 그대로 끌어와 Foundry 안에서 사용할 수 있습니다. 반대로 Foundry 내부의 Model Workbench 를 써서 처음부터 학습시켜도 됩니다. 어느 쪽이든 결과물은 같은 모델 라이브러리에 등록되고, 같은 방식으로 다뤄집니다.

이 자체는 큰 자랑거리는 아닙니다. 진짜 흥미로운 건 이 모델들이 온톨로지에 어떻게 붙는가입니다.

데이터 사이언티스트의 실제 질문들

데이터 사이언티스트가 모델을 운영에 올리려고 할 때 부딪히는 질문들이 있습니다.

• 이 모델은 어떤 데이터셋으로 학습됐는가?
• 프로덕션 데이터를 어떻게 안전하게 다시 학습에 흘려보내는가?
• 모델을 업그레이드했을 때 이전 모델과 결과를 비교하려면 어떻게 해야 하는가?

이 질문들에 답하지 못하면 모델은 결국 R&D 벤치에 갇혀 있게 됩니다. 운영팀은 검증되지 않은 모델을 신뢰하지 않고, 신뢰받지 못한 모델은 결정에 영향을 주지 못합니다.

Foundry 는 이걸 Modeling Objectives 라는 프레임워크로 풀어냅니다.

Modeling Objectives: 모델의 라이프사이클을 시스템화

Modeling Objectives 는 모델의 제출, 평가, 출시, 프로덕션 배포, 지속 모니터링까지를 한 흐름에 묶은 구조입니다.

• 제출: 학습된 모델을 등록
• 평가: 정의된 메트릭으로 자동 평가 + 사람 리뷰
• 출시: 어떤 워크플로에 어떤 버전을 쓸지 결정
• 프로덕션 배포: 온톨로지에 연결, 동적 속성 갱신 시작
• 모니터링: 입력 분포 변화, 예측 분포 변화, 실측 대비 차이 추적

핵심은 이 모든 단계가 같은 시스템 안에서, 같은 객체에 대해 일어난다는 점입니다. 모델 A 가 어떤 데이터셋에서 학습됐고, 어떤 평가를 통과했고, 어떤 워크플로에 어떤 버전이 올라가 있고, 지금 그 결과가 어떤 운영 결정에 쓰이고 있는지가 끊김 없이 연결되어 있습니다.

Code Workbook 과 학습 데이터의 진짜 문제

모델 학습 자체를 위한 도구도 있습니다. Code Workbook 은 노드 그래프 기반의 환경으로, R, Python, SQL 을 지원합니다. 각 노드는 데이터 또는 모델이고, 클릭하면 그 안의 코드가 보입니다. TensorFlow, Keras, scikit-learn 같은 오픈소스 라이브러리도 그대로 씁니다.

겉모습은 다른 ML 환경과 크게 다르지 않습니다. 다른 건 학습 데이터를 만드는 단계까지 같은 온톨로지 위에서 처리할 수 있다는 점입니다.

의료 사례 하나를 가져와 보겠습니다. 의료 영상에 주석을 다는 도구를 Foundry 안에서 Workshop 으로 직접 빌드합니다. 의료 전문가가 이 도구로 영상에 주석을 답니다.

그런데 여기서 중요한 디테일.

이 주석 도구를 프로덕션 워크플로에도 그대로 사용합니다.

즉 의사는 학습 데이터를 만드는 도구와 실제 환자 진료에 사용하는 도구가 같은 인터페이스라는 뜻입니다. 모든 주석은 온톨로지에 피드백되고, 그 데이터는 다시 모델의 다음 학습에 사용됩니다.

이게 가능한 이유는 단순합니다. 학습 환경과 프로덕션 환경이 분리되어 있지 않기 때문입니다.

Code Workbook 에서는 각 노드를 클릭해 그 노드의 기본 코드를 바로 보고, 데이터의 모든 조각과 인풋/아웃풋의 정체와 위치를 추적할 수 있습니다.

모델이 온톨로지에 붙는다는 것의 의미

모델이 단순히 API 엔드포인트로 배포되는 것과, 온톨로지에 붙는다는 것은 무엇이 다른가요.

• API 엔드포인트는 호출되어야 작동합니다. 누군가 명시적으로 코드를 짜서 부르지 않으면 영향이 없습니다.
• 온톨로지에 붙은 모델은 객체의 동적 속성이 됩니다. 그 객체를 들여다보는 모든 사용자, 모든 어플리케이션이 그 결과를 자동으로 보게 됩니다.

다시 의료 사례로 돌아가면, 환자 객체에는 2년 생존 가능성 이라는 동적 속성이 붙어 있습니다. 이 값은 모델이 산출합니다. 방사선 전문의가 환자를 보면 이 값이 보입니다. 임상의가 환자를 보면 이 값이 보입니다. 어플리케이션은 이 값에 따라 추가 스캔이 필요하다는 알림을 띄울 수도 있고, 담당 임상의에게 자동 통보할 수도 있습니다.

모델은 더 이상 데이터 사이언스 팀이 보관하는 자산이 아닙니다. 조직의 객체에 자리잡은 능력이 됩니다.

정리

모델 단계에서 Foundry 가 풀고 있는 것은:

• 어디서 만든 모델이든 같은 라이브러리로 모으기
• 모델의 라이프사이클을 시스템화 (Modeling Objectives)
• 학습용 도구와 프로덕션 도구를 일치시켜 데이터 피드백 루프 닫기
• 모델을 온톨로지의 동적 속성으로 만들어 자동 노출

다음 글은 마지막입니다. 이 모든 데이터와 모델을 사람이 실제로 들여다보고, 만지고, 결정하는 단계, Analytics 를 봅니다.