LIKAS: on-device Gemma 4 E2B로 구동되는 필리핀을 위한 오프라인 재난 동반자

이 글은 Gemma 4 Challenge: Build with Gemma 4에 제출하는 결과물입니다.

내가 만든 것
LIKAS — 국가에 재난이 닥쳤을 때 당신의 동반자가 되어줄 서비스입니다. 필리핀어로 Likas는 '자연'을 의미하며, 동시에 '대피하다'라는 뜻도 가지고 있습니다. LIKAS는 자연이 위협으로 변할 때 필리핀 사람들이 안전하게 대피할 수 있도록 돕는 오프라인 AI 기반 재난 동반자입니다.

필리핀에서 재난이란 곧 연결성 중단(connectivity outage)을 의미합니다. 2024년 태풍 시즌에만 30일 동안 6개의 주요 폭풍이 발생했습니다. 필리핀은 연평균 약 20개의 태풍, 100~150회의 체감 지진, 그리고 반복되는 화산 활동을 겪으며, 인구의 74%가 재난 취약 지역에 거주하고 있습니다. 태풍이 상륙하거나 단층이 파열되면, 가족들이 가장 가까운 대피소가 어디인지, 어떻게 가야 하는지를 알아야 하는 바로 그 순간에 기지국이 무너지고 인터넷이 끊깁니다. 제가 시도해 본 모든 "재난 앱"들은 재난 상황에서 결코 사실이 아닌 한 가지, 즉 '작동하는 네트워크'를 전제로 설계되어 있었습니다.

LIKAS는 휴대폰을 독립적인 생존 도구로 바꿔주는 React Native 앱(Android/iOS)입니다. 지도, 대피소, 미리 계산된 OSM(OpenStreetMap) 보행자 경로 그래프, NDRRMC/PAGASA/PHIVOLCS 프로토콜, 그리고 미세 조정(fine-tuned)된 Gemma 4 E2B 모델이 설치 시점에 모두 번들로 포함됩니다. 실행 시점(runtime)에는 네트워크 호출이 전혀 없습니다. 이는 차선책(fallback)이 아니라 의무 사항입니다.

핵심은 의도적으로 챗봇처럼 행동하지 않는 AI 어시스턴트입니다. 안전 조언을 자유 형식으로 내뱉는 2B 모델은 위험 요소가 될 수 있지만, 의도(intent)를 근거 데이터(grounded data)로 연결하는 모델은 자산이 됩니다. 따라서 LIKAS는 Gemma 4를 작업 특화형 도구 디스패처(task-specific tool-dispatcher)로 사용합니다. 모델은 매 턴마다 정확히 하나의 JSON 봉투(envelope) — 즉, 도구 호출(tool call) 또는 음성 답변만을 출력하며, 그 주변에 산문(prose)을 덧붙이지 않습니다.

실제 쿼리의 엔드 투 엔드(end to end) 예시: 사용자가 타글리시(Taglish)로 "Saan kami pwedeng lumikas? May aso at lola ako" ("어디로 대피할 수 있을까요? 강아지와 할머니가 계세요")라고 입력합니다.

Turn 1 — 모델은 {"action":"tool","name":"route_to_nearest_evacuation","args":{}}를 출력합니다.

이 앱은 이 모든 과정을 완전히 온디바이스 (on-device)로 해결합니다: 보행자 그래프 (pedestrian graph) 상의 다익스트라 (Dijkstra) 알고리즘이 보행 가능한 경로를 찾으면, 가중치 점수 산정 방식 (distance·0.4 + pwd·0.3 + pet·0.2 + capacity·0.1)을 통해 대피소를 순위화합니다. 2단계 — 결과를 입력받은 모델은 온디바이스 프로필 (on-device profile)을 기반으로 개인화된 최종 답변을 생성합니다. 질문이 타글리시 (Taglish, 타갈로그어와 영어가 혼합된 형태)로 강아지와 할머니(lola)를 언급했기 때문에, 모델은 반려동물 친화적이고 장애인(PWD) 접근이 가능한 대피소를 제시합니다. 단 1바이트의 데이터도 휴대폰을 벗어나지 않았습니다. 4개의 도구 (tools)는 모든 안전 필수 답변을 모델의 파라미터 (parameters)가 아닌 권위 있는 데이터에 근거하여 제공합니다: get_protocol은 NDRRMC/PHIVOLCS/PAGASA의 절차를 그대로 인용합니다 (안전 수칙을 임의로 만들어내는 것은 금지됩니다), route_to_nearest_evacuation은 오프라인 상태에서 프로필을 인식하여 경로를 탐색합니다, find_nearby는 오프라인 POI (Point of Interest) 검색 (병원, 학교, 체육관, 다목적 홀, 실내 코트)을 수행합니다, get_user_profile은 온디바이스 개인화 정보 (건강 상태, 동반자, 만남의 장소)를 제공합니다.

데모 📺 비디오 워크스루 (Video walkthrough): https://www.youtube.com/watch?v=kHHcDSyip-Q
코드 🔗 GitHub: https://github.com/JpCurada/likas
지원 아티팩트 (모두 공개):
리소스 | 링크
학습 데이터셋 (Training Dataset) | https://www.kaggle.com/datasets/jeypiic/likas-ai-datasets/
파인튜닝 (Fine-Tuning) 노트북 (Unsloth) | https://www.kaggle.com/code/jeypiic/likas-fine-tuning-gemma-4-e2b-with-unsloth
GGUF 내보내기 (Export) 노트북 | https://www.kaggle.com/code/jeypiic/likas-with-llama-ccp-llama-rn-gguf-export
샘플 프롬프트 (Sample Prompts) 노트북 | https://www.kaggle.com/code/jeypiic/likas-sample-prompts-for-the-fine-tuned-model
파인튜닝된 모델 (Fine-Tuned Model, GGUF) | https://huggingface.co/jpcurada/likas-gemma4-e2b-gguf
LoRA 어댑터 (LoRA Adapter) | https://huggingface.co/jpcurada/likas-gemma4-e2b-lora

Gemma 4 활용 방법
저는 Gemma 4 E2B — 유효 파라미터가 2B인 엣지 (edge) 변형 모델 —를 선택했습니다. LIKAS의 전체 전제 조건이 모델이 신호가 끊긴 휴대폰 내부에서 작동해야 한다는 것이기 때문입니다. 4B 및 31B 변형 모델이 더 유능했겠지만, 동시에 구현이 불가능했을 것입니다.

E2B는 Q4_K_M 양자화 (quantization, ~1.8 GB)를 적용했을 때, MapLibre, 보행자 그래프(pedestrian graph), 그리고 OSM POI 데이터와 함께 사용자가 이미 보유하고 있는 중급형 Android 스마트폰의 RAM 예산 내에 여유롭게 들어갈 수 있는 유일한 모델 버전이었습니다. 심사위원들의 질문인 "왜 당신의 모델이 이 작업에 적합한 도구인지 보여달라"는 요구에 대해 여기에는 명확한 답이 있습니다. 재난 상황은 통신 두절이며, 따라서 모델은 재난이 발생하는 바로 그 현장에서 작동해야 하고, 오직 E2B만이 그것을 수행할 수 있기 때문입니다. 하지만 안전이 직결된 경로(safety-critical path)에 2B 모델을 배치하기 위해서는 이 제출물에서 가장 흥미로운 두 가지 설계적 움직임이 필요했습니다.

1. Gemma 4 E2B를 더 나은 챗봇이 아닌, 단 하나의 특정한 생사 결단의 과업을 위해 미세 조정(Fine-tuning)하는 것. Unsloth의 LoRA 파이프라인을 사용하여, 앱에 탑재된 것과 동일한 9가지 규칙 시스템 프롬프트(system prompt)를 바탕으로 Gemma 4 E2B를 학습시켰습니다: 즉, 프로토콜의 문구 그대로 인용(verbatim protocol quoting), 안전/대피 문의 시 도구 사용(tool use) 의무화, 프로필 개인화, 주제 이탈 거부, 그리고 영어/필리핀어/타글리시(Taglish) 간의 동일 언어 응답 유지입니다. 학습(training)과 추론(inference)이 동일한 프롬프트를 그대로 공유하기 때문에, 평가용 노트북과 실제 휴대폰 사이의 분포 변화(distribution shift)가 전혀 발생하지 않습니다. 데이터셋 구축이 가장 어려운 부분이었습니다. v3 버전에서 692개의 대화 세트를 생성했지만, 어시스턴트 답변의 약 30%만이 고유(unique)했습니다(문구 그대로 인용 규칙 때문에 많은 의역된 질문들이 동일한 프로토콜 텍스트로 매핑되었기 때문입니다). 징후는 명확했습니다: 검증(validation) 손실은 거의 움직이지 않는 동안 학습(train) 손실이 24단계 만에 3.47에서 0.31로 급락했습니다. 해결책은 규칙을 보존하는 의역 생성기(rule-preserving paraphrase generator)를 사용하는 것이었습니다. 이 생성기의 extract_rules() 단계는 소스에서 모든 NDRRMC/PHIVOLCS 단계를 파싱하여 추출하고, 모든 변형 문구에 해당 내용이 포함되어 있는지 확인합니다. 이를 통해 안전 지침을 단 하나도 놓치지 않으면서도 표면적 형태(간결함 / 번호 매기기 / 긴급함 / 안심시키기 등)를 다양하게 변화시킬 수 있었습니다.

2. GBNF 문법(grammar)을 활용하여 llama.cpp를 통해 Gemma 4를 온디바이스(on-device)로 실행하는 것. 미세 조정된 모델은 Q4_K_M GGUF로 양자화되었으며, llama.rn ( ^0.12.0 )을 통해 완전히 온디바이스로 실행됩니다. 이는 휴대폰 내부 프로세스에서 전체 llama.cpp 엔진이 작동함을 의미합니다 (n_ctx: 4096, n_threads: 4, 전체 GPU 레이어 오프로드(GPU-layer offload), 서버 없음).

샘플링은 낮은 수치로 고정되었습니다 (temperature 0.4): 재난 파견사(disaster dispatcher)는 창의적일 필요가 없습니다. 모든 턴은 서버에 재시도를 요청할 수 없는 휴대폰 환경에서, 정확히 한 번에 파싱 가능한 봉투(envelope) 형태여야 합니다. 프롬프팅(Prompting)만으로는 이를 보장할 수 없기에, 디코더(decoder)는 실시간 도구 레지스트리(tool registry)로부터 구축된 GBNF 문법(grammar)에 의해 제약됩니다. 즉, 하나의 speak 프로덕션(production) 또는 도구 이름과 인자 열거형(argument enums)이 리터럴(literals)로 포함된 네 가지 도구 프로덕션 중 하나만을 생성해야 합니다. 디코더는 물리적으로 유효하지 않은 도구 이름이나 미완성된 객체를 출력할 수 없습니다. 문법은 선택이 아닌 형태(shape)를 보장합니다. 미세 조정(fine-tuned)된 모델은 신뢰할 수 있지만 일관성이 부족합니다. 대피 관련 질문에 대해 때로는 깔끔한 도구 호출(tool call)을 생성하지만, 때로는 speak 응답 내부에 도구 내용을 서술해 버려 가장 중요한 순간에 지도에 아무것도 남기지 못하기도 합니다. 따라서 파견 루프(dispatch loop)는 결정론적인 구조(deterministic rescue)로 감싸져 있습니다. 사용자의 메시지가 대피나 근처의 관심 지점(POI)을 명확하게 요청했음에도 일치하는 도구가 실행되지 않았다면, 앱은 모델이 어떤 형태를 선택했는지와 관계없이 직접 해당 도구를 호출하고 경로/핀을 지도에 표시합니다. 또한 완전한 비-LLM(no-LLM) 폴백(fallback) 기능도 갖추고 있습니다. 모델 로드에 실패하거나 배터리가 15% 미만인 경우에도, 동일한 키워드 라우터(keyword router)가 온디바이스(on-device) 데이터를 기반으로 대피 및 POI 쿼리를 여전히 해결합니다. 모델이 작동하지 않더라도 근거(grounding)는 유지됩니다. 이러한 분리가 제가 Gemma 4를 사용하는 핵심입니다. 엣지(edge)에서의 네이티브 함수 호출(native function calling)은 작은 모델이 정직함을 유지하도록 만듭니다. Gemma는 자신이 잘하는 것, 즉 혼란스럽고 코드 스위칭(code-switched)된 필리핀어 의도를 파싱하고 유창하며 개인화된 응답을 생성하는 일을 담당합니다. 장치는 절대 환각(hallucination)이 발생해서는 안 되는 것들, 즉 경로, 거리, 프로토콜 텍스트, 개인 데이터를 담당합니다. 모델은 안전 단계를 기억해내는 것이 아니라, 이를 가져오는(fetch) 것입니다. 이것이 바로 2B 모델을 대피 중인 사람 앞에 놓아도 될 만큼 신뢰할 수 있게 만드는 요소입니다.

모든 것이 검증 가능합니다: Likas/src/services/aiAssistantService.ts가 디스패치 루프 (dispatch loop)를 실행하고, aiGrammar.ts가 도구 레지스트리 (tool registry)로부터 GBNF를 구축하며, Likas/scripts/build_dataset_v4.py에는 과적합 (overfit) 수치들이 포함되어 있고, notebooks/Likas_Sample_Prompts.ipynb는 동일한 n_ctx=4096 설정에서 실제 프로덕션 프롬프트 (production prompt)와 문법 (grammar)을 그대로 재현합니다. 따라서 앱을 빌드하지 않고도 온디바이스 (on-device) 동작을 조사할 수 있습니다.