Task-specific LoRA adapters: BMW가 장애 티켓 정리와 유사 장애 찾기를 8B 모델 하나로 돌린 방법
BMW와 AWS FDE 팀이 엔지니어링 장애 티켓의 제목·설명 재작성, 보완 질문, 유사 장애 매칭을 약 8B 모델 하나와 LoRA 어댑터 4개로 처리했습니다. 제목 규정 준수율은 86%로 프롬프트만 쓴 31B 모델(79%)보다 높았고, 매칭 F1은 9.6~14.7점 앞섰습니다.
BMW는 장애 티켓을 다듬고 같은 원인의 과거 장애를 찾는 네 가지 일을 약 8B짜리 소형 모델 하나에 맡겼습니다. 업무별로 학습한 LoRA 어댑터 4개를 얹었고, 프롬프트만 쓴 31B 모델과 비슷하거나 더 나은 결과를 냈습니다. 따라 하려면 티켓 수정 이력처럼 사람이 고친 기록, 통과·실패로 판정하는 업무 규칙, 학습 시점 이후 데이터로 채점하는 평가 체계가 먼저 있어야 합니다.
요약
BMW Group과 AWS Forward Deployed Engineering(고객 현장에 들어가 함께 만드는 엔지니어) 팀은 2026년 10월 29일 AWS 블로그에 12주 협업 결과를 공저로 실었습니다. 대상은 BMW 연구개발 전 과정에 걸친 엔지니어링 장애 관리 업무입니다. 차량 문제를 빨리 해결하고 설계 개선 기회를 찾는 데 쓰이는 흐름입니다. 범용 LLM은 BMW 내부 절차, 사내 분류 체계, 품질 기준을 모릅니다. 프롬프트에 규칙과 예시를 넣어도 동시에 지켜야 할 제약이 많으면 잘 지키지 못했습니다. 팀은 2B~235B 모델 16종을 독일어·영어 과제로 비교한 뒤 Gemma 4 E4B(활성 파라미터 약 4B, 전체 약 8B)를 학습 대상으로 골랐습니다. 그 위에 티켓 제목 재작성, 설명 재작성, 보완 질문 생성, 장애 매칭 네 작업용 LoRA 어댑터를 학습해 엔드포인트 하나로 서비스했습니다.
비교 상대는 약 4배 큰 Gemma 4 31B에 전체 지시문과 채점 기준을 넣은 프롬프트 모델이었습니다. 제목 재작성의 규정 준수율은 미세조정 모델 86%, 31B 79%, 학습 전 E4B 49%였습니다. 보완 질문은 100%와 87%, 설명 재작성은 98%와 99%로 거의 같았습니다. 장애 매칭에서는 후보 수와 관계없이 F1이 31B보다 9.6~14.7점 높았습니다. 차이는 주로 “맞는 과거 장애가 없다”고 판단하는 능력에서 났습니다. 저자들은 단일 실행 결과라서 이 수치를 “strong directional evidence rather than a tuned ceiling”이라고 표현했습니다. 이 작업은 3단계 계획의 1단계입니다. 아래에서 다섯 가지 작동 방식, 실제로 돌릴 때의 설정, 현업 일정 순으로 정리합니다.
핵심 메커니즘
Task-specific SFT first: 기반 모델 투자 전에 업무별 학습부터
SFT(supervised fine-tuning, 정답 예시로 하는 지도 미세조정)를 업무 하나 단위로 먼저 하는 전략입니다. BMW는 모델 맞춤을 세 단계로 나눴습니다. 1단계는 업무별 적응, 2단계는 여러 도메인으로 넓힌 적응, 3단계는 자체 foundation model(기반 모델) 개발입니다. continued pre-training(사내 문서로 사전학습을 이어 하는 방식)은 투자가 크고, 해도 그 뒤에 SFT와 강화 미세조정이 다시 필요하다는 것이 저자들의 판단입니다. 업무별 SFT는 비용이 작고 결과가 빨리 나옵니다. 그 과정에서 만든 평가 도구, 데이터 품질 규칙, 학습 방법은 다음 단계에서 그대로 다시 씁니다. 지켜야 할 규칙이 분명하고 정답 예시가 쌓여 있는 업무에 맞습니다. 정답이 정해지지 않은 탐색형 질의응답은 이 방식의 첫 대상이 아닙니다.
Edit history as supervision: 사람이 고친 기록이 정답이 된다
학습 데이터를 따로 라벨링하지 않고 업무 시스템에 이미 남은 기록에서 뽑는 방식입니다. 티켓 품질 작업은 엔지니어가 티켓을 고친 수정 이력을, 장애 매칭은 근본원인 분석에서 어떤 장애끼리 같은 원인으로 묶였는지를 정답 신호로 씁니다. 티켓은 독일어와 영어가 대략 절반씩입니다. 파이프라인은 세 단계입니다. Generate 단계에서 Amazon Bedrock 배치 추론으로 실행마다 학습 후보 쌍 수만 개를 만듭니다. 일부 샘플은 메타데이터와 설명을 일부러 지워, 막 생성된 빈약한 티켓에도 대응하게 합니다. Filter 단계에서는 생성에 쓰지 않은 별도 judge 모델이 환각, 식별자 누락, 구조 오류, 언어 불일치가 있는 쌍을 버립니다. Export 단계에서는 학습 기준 시점 이후에 생긴 장애만 평가에 쓰도록 시간 기준으로 나눕니다. 저자들은 규칙을 어긴 데이터가 남으면 모델이 그 위반을 배운다며 강하게 걸러야 한다고 권합니다.
Compliance gates + LLM judge: 통과·실패를 먼저 보고 품질은 그다음
평가를 두 층으로 나누는 설계입니다. 첫 층은 통과·실패만 가리는 compliance gate(규정 준수 관문)입니다. 재작성 작업은 환각, 내용 보존과 정보 손실, 구조, 언어를 봅니다. 보완 질문은 실제로 빠진 정보를 묻는지, 이미 있는 정보를 다시 묻지 않는지, 언어가 맞는지를 봅니다. 둘째 층은 LLM judge가 매기는 1~5점 품질 점수입니다. 제목은 형식의 정확성과 분류 담당자에게 주는 쓸모를, 설명은 명확성, 완결성, 구조, 용어를 봅니다. 장애 매칭은 생성이 아니라 판별 작업이라 F1과 exact match 같은 결정적 지표로 잽니다. 평가는 학습 파이프라인 안에서 Bedrock 배치 작업으로 돌아갑니다. 저자들은 이 자동 평가가 없으면 어디서 틀리는지, 미세조정이 효과가 있었는지, 데이터나 연산을 더 넣을지 판단할 수 없다고 봅니다.
Multi-adapter serving: 기본 모델 하나, 어댑터 여러 개
LoRA(low-rank adaptation, 모델 본체는 두고 작은 보정 가중치만 학습하는 방식)로 만든 어댑터 여러 개를 공유 기본 모델 하나에 얹어 서비스하는 구조입니다. 학습은 QLoRA(기본 모델을 4-bit로 양자화한 상태에서 하는 LoRA)와 4-bit NF4 양자화, Unsloth와 Hugging Face TRL로 SageMaker 학습 작업에서 돌렸습니다. GPU 인스턴스는 학습할 때만 띄웠습니다. 어댑터 하나는 수십 MB로, 수십 GB인 기본 모델에 비하면 아주 작습니다. GPU, CPU, 디스크 어디에 있든 밀리초 단위로 올라옵니다. 서비스는 DJL-LMI 컨테이너 위 vLLM 실시간 엔드포인트 하나가 맡고, 요청은 필요한 capability(작업) 이름을 지정합니다. 관련 작업을 하나로 묶은 joint adapter(공동 어댑터)도 시험했습니다. 티켓 품질 세 작업을 어댑터 하나로 처리해도 최선에 가까웠지만, 작업별 어댑터가 작업마다 가장 좋았습니다.
No-match recognition: “해당 없음”을 말할 줄 아는 매칭
장애 매칭은 새 장애 하나와 과거 장애 후보 1~8건을 받아, 근본원인이 같은 후보가 어느 것인지(없을 수도 있음) 고르는 작업입니다. 엔지니어가 관련 장애를 찾고 같은 조사를 두 번 하지 않게 돕는 일입니다. 미세조정 모델의 이점은 대부분 맞는 후보가 없을 때 빈 목록을 돌려주는 데서 나왔습니다. 후보가 2건일 때 no-match F1은 미세조정 70%, 31B 47%, 학습 전 E4B 25%였습니다. 후보가 1건에서 8건으로 늘자 31B는 63%에서 34%로, 학습 전 E4B는 44%에서 9%로 떨어졌습니다. 미세조정 모델은 68%에서 74%로 오히려 올랐습니다. 후보가 많아질수록 프롬프트 모델은 맞는 것이 없어도 하나를 고르는 쪽으로 기운다고 읽을 수 있습니다. 이 평가는 검색까지 포함한 전체 흐름이 아니라 고정된 후보 세트로 했습니다.
통념과 다른 주장
흔히 이렇게 봅니다규칙을 프롬프트에 더 자세히 쓰고 더 큰 모델을 쓰면 업무 규칙을 지킨다.
저자들은 이렇게 봅니다프롬프트 모델은 식별자 보존, 환각 금지, 언어 일치, 출력 구조 같은 필수 규칙을 선호 정도로 다룹니다. 업무 절차가 담긴 예시로 학습해야 이 실패가 고쳐집니다.
근거31B 프롬프트 모델은 제목 재작성의 약 19%에서 라우팅 코드를 지어냈고, 보완 질문의 약 13%에서 언어를 맞추지 못했습니다. 지시문을 더 자세히 써도 나아지지 않았습니다.
흔히 이렇게 봅니다산업 특화 AI를 하려면 사내 데이터로 기반 모델을 만들거나 사전학습부터 이어 해야 한다.
저자들은 이렇게 봅니다업무별 SFT로 먼저 가치를 내고, SFT와 강화 미세조정으로도 안 메워지는 격차가 확인될 때 사전학습이나 구조 변경에 투자합니다.
근거12주 1단계에서 약 8B 모델이 4배 큰 프롬프트 모델과 비슷하거나 나은 결과를 냈고, 평가 도구·큐레이션 템플릿·학습 파이프라인·어댑터 저장소가 다음 단계 자산으로 남았습니다.
저자가 든 사례
BMW Group: 엔지니어링 장애 관리의 네 작업을 소형 모델 하나로
| 구분 | 내용 |
|---|---|
| 상황 | 연구개발 전 과정의 장애 관리 업무. 사내 절차·분류 체계·품질 기준은 공개 학습 데이터에 없음. 프롬프트로는 여러 필수 규칙을 동시에 지키지 못함 |
| 한 일 | AWS FDE 팀과 12주 협업. 모델 16종(2B~235B) 비교 후 Gemma 4 E4B 선정. 수정 이력·근본원인 결과로 데이터 큐레이션, QLoRA로 어댑터 4개 학습, 엔드포인트 하나로 서비스 |
| 결과 | 규정 준수율 제목 86%(31B 79%), 설명 98%(99%), 보완 질문 100%(87%). judge 점수는 원래 티켓 대비 제목 +0.97, 설명 +1.03. 매칭 F1은 31B보다 9.6~14.7점 높음. 단일 seed·단일 하이퍼파라미터 실행 |
| 연결 | Task-specific SFT first, Edit history as supervision, Compliance gates, Multi-adapter serving, No-match recognition |
품질 점수(1~5)를 원래 사람이 쓴 티켓과 비교하면 제목은 3.74에서 4.71로, 설명은 2.84에서 3.87로 올랐습니다. 31B 프롬프트 모델은 제목 4.75, 설명 3.77이었습니다. 설명의 완결성은 2.78점으로 가장 낮은 항목이었습니다. 저자들은 모델이 없는 정보를 지어내지 않도록 만든 결과이며, 빠진 정보는 보완 질문 작업이 메우도록 나눴다고 설명합니다. BMW Group IT의 혁신·신기술 책임자 Andre Luckow는 이 모델이 31B 프롬프트 모델과 비슷한 품질에 이르렀고, BMW 평가에서 품질 점수가 25% 넘게 높았다고 밝혔습니다.
기술 디테일: 업무별 어댑터를 직접 만든다면
아래 필드 이름, 설정값, 판정 기준은 원문의 절차를 실제로 돌릴 때 필요한 것을 정리한 실행 제안입니다. 원문에서 온 값은 그렇다고 밝혔습니다.
모델 선정(Task-specific SFT first)을 하려면 먼저 우리 업무 언어로 된 소규모 벤치마크를 만듭니다. BMW는 엔지니어링 추론, 수학, 추출형 질의응답, 번역을 독일어·영어로 묶었습니다. 후보는 크기별로 고르게 넣고, 학습 대상은 반복 학습과 서비스 비용이 싼 소형 오픈 웨이트 모델로 둡니다. 생성과 채점에는 큰 모델을 쓰되 서로 다른 모델로 나눕니다. BMW는 티켓 품질 생성에 Qwen3-235B, 매칭 생성에 Gemma 4 31B를 썼고 judge는 Qwen3-235B로 생성 모델과 분리해 자기 확증 편향을 줄였습니다. 데이터 위치가 중요하면 생성·필터링을 데이터가 있는 리전 안에서 돌립니다. BMW는 EU 리전의 Bedrock을 썼습니다.
수정 이력으로 학습 쌍을 만들려면 티켓마다 최초 버전과 최종 승인 버전을 짝지어 한 행으로 만듭니다. 생성 모델이 만든 후보는 judge의 판정 결과를 같은 행에 붙여 두면 필터와 감사에 그대로 씁니다(가상 예시).
{
"pair_id": "TQ-TITLE-004211",
"task": "title_rewrite",
"source_ticket": {"id": "INC-2026-18833", "created_at": "2026-03-14", "lang": "de"},
"input": {"title": "Geräusch Tür hinten links", "description": null, "metadata_dropped": true},
"target": "[KAR] Klappergeräusch Fondtür links bei Schlechtwegfahrt",
"gates": {"no_hallucination": true, "identifiers_preserved": true, "valid_structure": true, "language_match": true},
"judge_model": "qwen3-235b",
"split": "train"
}metadata_dropped는 원문의 “일부 샘플은 메타데이터와 설명을 지운다”를 기록하는 칸이고, 네 개 gate 중 하나라도 false면 학습에서 뺍니다. 평가 세트는 학습 기준일(예: 2026-06-30) 이후 생성된 티켓만 쓰고, 같은 장애 묶음이 학습과 평가에 갈라지지 않게 근본원인 묶음 ID 단위로 나눕니다.
장애 매칭 출력을 정하려면 후보 1~8건에 ID를 붙여 넣고, 출력은 같은 원인인 후보 ID 목록 하나로 제한합니다. 빈 목록 []을 정상 답으로 학습 데이터에 충분히 넣는 것이 핵심입니다. 원문 결과에서 이점 대부분이 여기서 나왔기 때문입니다. 출력 예시는 {"matches": ["INC-2025-07712"]} 또는 {"matches": []}이고, 후보에 없는 ID가 나오면 형식 오류로 처리합니다. 평가는 후보 수 1, 2, 4, 8별로 F1과 no-match F1을 따로 냅니다. 운영에 붙일 때는 원문처럼 고정 후보가 아니라 검색이 후보를 뽑으므로, 검색 상위 8건 안에 정답이 들어오는 비율을 별도 지표로 잽니다.
학습과 서비스를 구성하려면 원문 구성(QLoRA 4-bit NF4, Unsloth + TRL, SageMaker 학습 작업, MLflow로 데이터부터 지표까지 계보 기록)을 출발점으로 씁니다. LoRA rank, 학습률, epoch는 원문이 밝히지 않았으므로 rank 16, alpha 32, 학습률 2e-4, 2~3 epoch 정도에서 시작해 gate 통과율로 고르는 것을 제안합니다. 원문은 단일 seed 결과이므로 운영 결정 전에는 seed 3개로 다시 돌려 통과율 차이가 3%p 안쪽인지 봅니다. 서비스는 vLLM의 multi-LoRA 기능처럼 요청에 어댑터 이름을 실어 보내는 방식으로 하고, 평가 때는 temperature 0으로 고정합니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 식별자 환각 | 라우팅 코드·부품 번호를 지어냄 | identifiers_preserved gate를 학습 데이터 필터와 운영 출력 검사 양쪽에 둠 |
| 빈약한 신규 티켓 | 설명이 없으면 내용을 지어내 채움 | 메타데이터를 지운 샘플을 학습에 섞고, 빠진 정보는 보완 질문으로 넘김 |
| 매칭 과잉 | 후보가 많을수록 억지로 하나를 고름 | 빈 목록 정답 비중 확보, 후보 수별 no-match F1 추적 |
| 어댑터 수 증가 | 작업마다 어댑터가 늘어 관리 부담 | 비슷한 작업은 joint adapter로 묶고 핵심 작업만 개별 어댑터 유지 |
| 언어 혼용 | 독일어 티켓에 영어로 답함 | language_match gate, 언어별 통과율을 따로 보고 |
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 맡는 일 |
|---|---|
| 품질·장애 관리 프로세스 오너 | 작업 범위와 티켓 작성 기준 확정, 12주 뒤 진행 여부 판정 |
| 장애 분류 담당 엔지니어(2~3명) | 좋은 제목·설명의 기준 정리, judge 채점 표본 50건 검토, 시범 사용 피드백 |
| 근본원인 분석 담당 | 같은 원인 장애 묶음 데이터 확인, 매칭 결과 표본 검토 |
| 데이터 엔지니어 | 티켓 수정 이력·근본원인 연결 데이터 추출, 시간 기준 분할 |
| ML 엔지니어(벤더 FDE 포함) | 큐레이션·학습·평가 파이프라인, 어댑터 서비스, 주간 결과표 |
준비물. 최근 2~3년치 장애 티켓과 수정 이력, 근본원인 분석에서 장애를 묶은 기록, 티켓 작성 규칙 문서(제목 형식, 필수 식별자, 설명 구조), 지금 티켓 품질에 대한 기준선(분류 담당자가 다시 묻는 비율, 중복 조사 건수), 데이터를 둘 리전과 반출 규칙이 필요합니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 작업 4개 정의, gate 항목과 judge 채점표 합의, 후보 모델 벤치마크 | 평가 정의서, 모델 선정 결과 |
| 3~5주 | 수정 이력·근본원인 데이터 추출, 후보 생성과 judge 필터, 시간 기준 분할 | 학습·평가 세트, 필터 통과율 |
| 6~9주 | 어댑터 학습, 프롬프트 기준선과 비교, 실패 유형 분석 후 재학습 | 작업별 결과표, 실패 유형 목록 |
| 10~12주 | 엔드포인트 하나로 서비스, 분류 담당자 시범 사용, 진행 판정 | 시범 사용 기록, 판정 보고서 |
현업에 물을 것.
- 분류 담당자가 티켓을 받고 다시 물어보는 정보는 주로 무엇입니까?
- 제목에서 절대 바뀌면 안 되는 식별자는 무엇입니까?
- 같은 원인 장애를 나중에 묶은 기록은 어디에 어떤 형식으로 남습니까?
- 매칭 결과가 틀렸을 때, 놓치는 것과 잘못 묶는 것 중 무엇이 더 비쌉니까?
- 티켓 원문을 모델이 고쳐 쓸 때 원래 작성자의 확인을 거쳐야 합니까?
진행 판정 기준(예시). 평가 세트에서 작업별 gate 통과율이 프롬프트 기준선 이상이고, 식별자 환각이 1% 미만이어야 합니다. 매칭은 후보 8건 조건에서 no-match F1이 기준선보다 10점 이상 높아야 합니다. 시범 사용에서는 분류 담당자가 되묻는 비율이 20% 이상 줄어야 합니다. 못 채우면 실패 유형 중 가장 많은 것 하나를 골라 데이터를 보강하고 3주를 더 봅니다.
AX 적용 제언. 이 사례에서 옮길 것은 “큰 모델 하나에 긴 프롬프트” 대신 “작은 모델 하나에 업무별 어댑터”라는 구성입니다. 첫 후보는 사람이 고친 이력이 시스템에 남는 업무입니다. 제조 품질 클레임 접수, IT 서비스 데스크 티켓, 설계 변경 요청서, 협력사 불량 보고가 여기에 맞습니다. 순서는 형식 규칙이 분명한 재작성 작업으로 평가 체계와 데이터 파이프라인을 먼저 세우고, 그 위에 유사 사례 매칭 같은 판별 작업을 얹는 편이 좋습니다. 벤더와 함께 할 때는 BMW처럼 작업 정의, 평가 기준, 정제한 데이터, 어댑터 산출물을 고객 소유로 남긴다는 점을 계약 초기에 문서로 정해 둡니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 글 | AWS for Industries 블로그, 2026.10.29 게재 |
| 저자 | BMW Group 3명(Johannes Klepsch, Marvin Erdmann, Saltuk Kezer)과 AWS FDE 5명 공저 |
| 협업 | 12주, 3단계 계획(업무별 적응 → 다중 도메인 적응 → 기반 모델 개발) 중 1단계 |
| 작업 | 생성 3개(제목 재작성, 설명 재작성, 보완 질문), 판별 1개(장애 매칭, 후보 1~8건) |
| 모델 | 16종 벤치마크(2B~235B). 학습 대상 Gemma 4 E4B, 생성 Qwen3-235B·Gemma 4 31B, judge Qwen3-235B, 기준선 Gemma 4 31B 프롬프트 |
| 데이터 | 티켓 수정 이력, 근본원인 연결 결과, 독일어·영어 반반, 실행당 후보 쌍 수만 개, 시간 기준 분할 |
| 학습·서비스 | QLoRA 4-bit NF4, Unsloth·TRL, SageMaker Pipelines 2개, MLflow, vLLM 엔드포인트 1개에 어댑터(수십 MB) |
| 규정 준수율 | 제목 86/79/49%, 설명 98/99/94%, 보완 질문 100/87/89%(미세조정 E4B/프롬프트 31B/프롬프트 E4B) |
| 품질 점수 | 제목 원래 티켓 3.74 → 4.71, 설명 2.84 → 3.87(1~5점) |
| 매칭 | F1이 31B보다 9.6~14.7점 높음. no-match F1 후보 1→8건: 68→74%, 63→34%, 44→9% |
| 단서 | 단일 seed·단일 하이퍼파라미터, 고정 후보 세트 |
핵심 개념
- Gemma 4 E4B
- Google의 오픈 웨이트 소형 모델. 추론 때 쓰는 활성 파라미터는 약 4B, 전체는 약 8B입니다.
- NF4
- 4-bit NormalFloat. 가중치 분포에 맞춰 4비트로 압축하는 양자화 형식으로, QLoRA에서 기본 모델을 담는 데 씁니다.
- LLM-as-a-judge
- 다른 LLM이 정해진 채점표로 출력의 품질을 매기는 평가 방식입니다.
- temporal split
- 학습 기준일 이전 데이터로 학습하고 이후 데이터로 평가해, 실제 운영 조건을 흉내 내고 정보 누출을 막는 분할입니다.
- no-match F1
- 맞는 후보가 없는 경우를 얼마나 정확히 "없음"으로 답하는지 재는 F1입니다.
- DJL-LMI
- AWS가 대형 모델 추론용으로 제공하는 서빙 컨테이너입니다. 안에서 vLLM 같은 추론 엔진을 돌립니다.
- Forward Deployed Engineering
- 벤더 엔지니어가 고객 팀 안에 들어가 문제 정의부터 운영까지 함께 만드는 방식입니다.
내 메모
TODO: 내 생각 추가
원문은 AWS for Industries 블로그의 「How BMW builds toward industry AI on Amazon SageMaker AI」(BMW Group·AWS Forward Deployed Engineering 공저, 2026.10.29 게재)입니다. 요약, 핵심 메커니즘, 통념과 다른 주장, 사례는 원문 내용을 AX Partners가 다시 정리한 것이고, 기술·현업 실행 디테일의 JSON 필드, LoRA 설정 제안, 12주 일정, 판정 기준, 인포그래픽과 표는 새로 작성했습니다. 원문은 LoRA rank, epoch, 학습 데이터 건수, 비용, 지연 시간을 밝히지 않았습니다. 전체 내용은 원문에서 볼 수 있습니다.