LangTailor페이지 목차
이 페이지에서 검색
로컬 LLM
이 페이지에 묻기
로컬 LLM · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.
생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.
LOCAL · LLM
로컬 LLM
생성 수정
로컬 모델 실행과 GPU·메모리 이해부터 서빙·RAG·도구 호출·업무형 앱 구현까지 차례로 살펴봅니다.
42개 문서 · 4일차 · 32 / 42
31차시 · 로컬 LLM 업무형 앱 구현
지도 위치 : 4일차 · ⑤애플리케이션 층 — 네 가지 업무 기능을 기능마다 다르게 만든다 | 이전: 30차시 Tool Calling 이해 및 활용 | 다음: 32차시 AI 애플리케이션 통합 키워드 : 요약 · 분류 · 정보추출 · 텍스트 생성 등 업무 기능 구현
이 차시를 다 읽으면
- 문의봇의 네 기능을 (기법 · temperature · 출력 형식 · 평가 방법 · 사람 검토) 매트릭스로 설명할 수 있다.
- 분류는 정확도 , 추출은 필드별 정확도 + 원문 대조 로 평가하는 이유를 말할 수 있다.
- 요약을 포함 항목 체크리스트(루브릭) 로 채점할 수 있다.
- 답변 초안에 사람 검토가 필수 인 이유를 말할 수 있다.
- 분류 → 추출 → 요약 → 초안 파이프라인 순서의 이유를 말하고, 평가셋을 기능별로 확장할 수 있다.
0. 이 차시의 판별 축
| # | 축 | 왼쪽 (0) | 오른쪽 (1) | 이 축으로 갈리는 것 | 큰 축 (README 5장) |
|---|---|---|---|---|---|
| 1 | 답이 원문 안에 있는가 | 원문 안 (분류 · 추출) | 원문 밖에서 새로 씀 (요약 · 초안) | 코드로 채점 ↔ 루브릭 · 사람 | ⭐ ⑧ 구문 ↔ 의미 |
| 2 | 같은 입력에 같은 출력인가 | temperature 0 | temperature > 0 | 분류 · 추출 ↔ 초안 | 결정론 ↔ 확률론 (⑧의 파생) |
| 3 | 사람이 손을 대는가 | 매 건 사람 검토 | 자동 반영 | 답변 초안 ↔ 분류 | 사람이 손을 대는가 (⑦의 파생, HITL — 29차시 4절) |
| 4 | 한 덩어리인가 단계인가 | 거대 프롬프트 하나 | 기능별 단계의 사슬 | 어디서 틀렸는지 보이는가 | ⑤ 하나 ↔ 여럿 (6절 체인) |
앞에서 이어집니다 — 28차시(프롬프트), 29차시(구조화 출력), 30차시(도구)는 부품 이었습니다. 이 차시는 그 부품으로 업무 기능 네 개 를 조립합니다. 그리고 README 9장에서 당신이 쥐는 세 가지 중 하나였던 평가셋 을 기능별로 키웁니다. AI의 "품질이 좋습니다"를 직접 채점 하는 도구가 이것입니다.
1. ⭐ 네 기능 매트릭스
| 기능 | 하는 일 | 주로 쓰는 기법 | temperature | 출력 형식 | 평가 방법 | 사람 검토 |
|---|---|---|---|---|---|---|
| 분류 | 문의를 다섯 값 중 하나로 | 정의를 쓴 시스템 프롬프트 + few-shot + enum | 0 | enum 한 값 | 정확도 · 혼동표 | "수동 분류 필요" 건만 |
| 정보추출 | 고객명 · 주문번호 · 연락처 · 요청사항을 칸에 | JSON 스키마 강제 + null 허용 | 0 | JSON | 필드별 정확도 + 원문 대조 | 대조 실패 건 |
| 요약 | 상담원이 30초 안에 파악하게 | 포함 항목 · 길이 지시 | 0 ~ 0.3 | 짧은 글 | 포함 항목 체크리스트 | 표본 |
| 생성 (답변 초안) | 고객에게 보낼 답의 초안 | 역할 · 톤 · 금지 + 도구 결과 + 스트리밍 | 0.3 ~ 0.7 | 자유 글 | 루브릭 + 금지 표현 검사 | ⭐ 매 건 필수 |
(temperature는 예시 범위입니다. 모델 카드의 권장값을 함께 보세요 — 28차시 6절.)
⭐ 같은 모델, 같은 서버인데 기능마다 설정이 전부 다릅니다. "문의봇 프롬프트 하나"가 아니라 기능 네 개 입니다. 각 기능은 28차시의 프롬프트 파일 하나씩(prompts/classify.md 등)과 짝을 이룹니다.
1.1 추출과 생성을 가르는 한 줄
정보 추출 (Information Extraction) — [텍스트 처리]인데, [ 본문에 이미 있는 값을 정해진 칸에 옮겨 담는다 ]는 점에서 원문에 없던 글을 새로 쓰는 생성과 구별된다.
| 추출 · 분류 | 요약 · 생성 | |
|---|---|---|
| 답이 어디에 | 원문 안 (또는 닫힌 목록 안) | 원문 밖 — 새로 쓴 문장 |
| 정답 | 하나 | 여러 개가 다 맞을 수 있음 |
| 채점 | 코드로 비교 | 체크리스트 · 사람 |
⭐ 이 구분이 평가 방법을 정합니다. 답이 원문 안에 있으면 원문과 대조해 지어낸 값을 잡을 수 있습니다(3절). 원문 밖이면 그럴 수 없으니 사람의 루브릭 이 필요합니다(4 · 5절). LLM은 같은 입력에도 매번 다른 문장을 낼 수 있으므로(28차시 6절) 정답 문장과 글자 단위로 비교하는 테스트는 성립하지 않습니다.
2. 분류 — 닫힌 답, 정확도와 혼동표
29차시의 Category enum과 temperature 0으로 모양과 재현성 을 잡고, 평가셋으로 정확도 를 잽니다.
정확도 하나로는 어디서 틀리는지 모릅니다. 정답과 예측을 교차한 혼동표 를 봅니다(예시, 실측 아님).
| 정답 ＼ 예측 | 배송지연 | 교환·반품 | 결제오류 | 상품문의 | 기타 |
|---|---|---|---|---|---|
| 배송지연 | 11 | 0 | 0 | 0 | 1 |
| 교환·반품 | 0 | 7 | 2 | 0 | 0 |
| 결제오류 | 0 | 0 | 6 | 0 | 0 |
| 상품문의 | 0 | 1 | 0 | 7 | 0 |
| 기타 | 1 | 0 | 0 | 0 | 4 |
🔍 읽는 포인트 — 대각선이 맞힌 것입니다. 대각선 밖의 "교환·반품 → 결제오류" 2건 이 눈에 띕니다. 환불 요청을 결제 문제로 본 것이고, 28차시 4절의 "경계 혼동 → 규칙 칸의 정의" 를 고칠 신호입니다.
| ⚠️ 주의 | 내용 |
|---|---|
| 쏠린 데이터 | 문의의 60%가 배송지연이면 전부 "배송지연"이라고 답해도 60%. 분류값별로 따로 봅니다 |
| 작은 모델로도 되는가 | 분류는 닫힌 답이라 작은 모델로 충분한 경우가 많습니다. 실무에서 흔한 조합은 분류 · 전처리는 작고 빠른 모델이, 긴 글 생성 같은 무거운 작업은 그 뒤에서 큰 모델이 맡는 것입니다. 글을 만들지 않고 분류만 하도록 학습된 수억 파라미터급 모델(예: 한국어 ELECTRA 계열인 KcELECTRA)도 후보가 됩니다. 단, 바꿀 때는 같은 평가셋으로 확인 |
3. 정보추출 — 답이 원문 안에 있다
29차시의 InquiryExtraction 스키마로 모양을 잡고, 필드마다 따로 채점합니다(예시, 실측 아님).
| 필드 | 맞음 | 틀린 이유 (사람이 읽고 분류) |
|---|---|---|
customer_name | 38/40 | 서명란 대신 본문 속 가족 이름 을 뽑음 |
order_id | 39/40 | 주문번호가 없는데 지어냄 1건 |
contact | 33/40 | 6건은 형식 차이 (010-1234-5678 ↔ 01012345678) — 사실은 맞음 |
request | 사람 판정 | 서술 필드 — 글자 비교 불가 |
⚠️ 셋째 줄처럼 비교 전에 정규화 (공백 · 하이픈 제거)를 하지 않으면 맞는 답을 틀렸다고 셉니다. 채점 규칙도 검수 대상입니다.
3.1 ⭐ 원문 대조 — 운영 중에도 할 수 있는 의미 검사
def grounded(value: str | None, source: str) -> bool:
if value is None: # "없음"은 지어낸 게 아님
return True
norm = lambda s: re.sub(r"[\s\-]", "", s)
return norm(value) in norm(source) # 원문에 글자 그대로 있는가
🔍 읽는 포인트
False가 나오면 그 값은 원문에 없는 값 — 지어낸 값일 가능성이 큽니다. 그 필드를 비우고 "확인 필요" 로 표시해 상담원에게 넘깁니다.- 29차시 5절의 💡 "의미 검사의 일부를 규칙으로 끌어온다"가 이 함수입니다. 평가셋 없이 매 요청 돌릴 수 있습니다. 30차시의 도구 인자(주문번호)에도 그대로 씁니다.
- ⚠️
request처럼 바꿔 말한 필드에는 쓸 수 없습니다. 원문의 표현과 다르기 때문입니다.
4. 요약 — 포함 항목 체크리스트
요약은 정답 문장이 하나가 아닙니다. 그래서 문장을 비교하지 않고 "반드시 들어가야 할 것"을 체크 합니다. 평가셋의 문의마다 체크리스트를 함께 적어 둡니다.
문의 #17 요약 체크리스트
[ ] 무엇을 샀나 — 운동화
[ ] 무엇이 문제인가 — 사이즈가 큼
[ ] 원하는 조치 — 한 치수 작은 것으로 교환
[ ] 시급성 · 감정 신호 — 주말 전 필요, 두 번째 문의
[ ] (감점) 원문에 없는 내용이 들어갔는가
| 채점 규칙 | 이유 |
|---|---|
| 점수 = 체크한 항목 ÷ 전체 항목 | 빠진 정보를 셈 |
| 원문에 없는 내용이 있으면 0점 | 상담원이 요약만 믿고 일하므로, 빠진 것보다 지어낸 것이 더 위험 |
| "3줄 이내" 같은 길이는 코드로 | 형식(구문)은 기계에게 |
| 채점자는 사람 , LLM 채점은 보조 | 같은 모델이 만든 답을 같은 모델이 채점하면 관대함 (README 9장) |
💡 처음에는 20건이면 충분합니다. 앞에서 배운 "실제 사례 20~50개를 사람이 직접 읽기 → 오류 분류 → 자동 평가기" (28차시 4절) 순서입니다.
5. 생성 (답변 초안) — 사람 검토는 필수
고객에게 나가는 글은 회사의 약속 입니다. 앞에서 배운 "되돌릴 수 없는 작업" 목록에 메일 발송이 들어 있었습니다 (30차시 4.4). 그래서 초안은 언제나 초안 입니다.
| 루브릭 항목 | 무엇을 보나 | 누가 |
|---|---|---|
| 사실 일치 | 도구 결과(30차시)와 출고일 · 상태가 같은가 | 사람 (+ 날짜 · 상태 문자열 대조는 코드) |
| 약속 금지 | "보상해 드리겠습니다", "환불이 승인되었습니다" 같은 확정 표현이 없는가 | ⭐ 코드 — 금지 표현 목록 검사 |
| 다른 고객 정보 | 이 문의의 고객이 아닌 이름 · 주문번호가 없는가 | 코드 — 27차시 세션 사고 탐지 |
| 필요한 안내 | 교환 절차, 다음 단계가 있는가 | 사람 |
| 톤 | 정중하고 과하지 않은가 | 사람 |
[초안 생성 (스트리밍)] ─▶ [금지 표현 · 다른 고객 정보 검사 (규칙)] ─▶ [상담원이 읽고 고침] ─▶ [상담원이 발송]
앞에서 배운 HITL — 시스템은 좋은 초안을, 확정은 사람이 (29차시 4절)의 정확한 모양입니다. 발송 버튼은 상담원 화면에만 있습니다.
💡 운영 중에는 상담원이 초안을 얼마나 고쳤는가 (수정 비율)를 기록해 두면 그 자체가 품질 지표가 됩니다. 거의 안 고치면 좋은 초안이고, 매번 다 지우고 새로 쓰면 이 기능은 아직 쓸모가 없는 것입니다.
6. 파이프라인 — 왜 이 순서인가
문의 메일 ─▶ ① 분류 ─▶ ② 추출 ─▶ ③ 요약 ─▶ ④ 답변 초안 (+ 주문 조회 도구)
enum, t=0 JSON, t=0 짧은 글 자유 글, 스트리밍, 사람 검토
| 순서의 이유 | 내용 |
|---|---|
| 앞 결과가 뒤를 고른다 | 분류가 "배송지연"이면 ④에서 주문 조회 도구가 필요하고, "상품문의"면 필요 없음 |
| 앞 결과가 뒤의 재료가 된다 | ② 주문번호 → 도구 인자(30차시) · 대화 고정 정보(27차시 4절) |
| 싼 것부터 | ① ②는 출력이 짧고 결정론적 → 빠르고 쌈. 긴 출력은 ④ 하나 |
| ⚠️ 오류가 뒤로 번진다 | 추출이 주문번호를 틀리면 초안은 남의 주문으로 답함 → 앞 단계 평가가 먼저 |
체인 (Chain) — [LLM 작업 구성 방식]인데, [ 단계들을 정해진 순서로 한 줄로 이어 앞 단계의 출력을 다음 단계의 입력으로 쓴다 ](A → B → C)는 점에서 조건에 따라 갈라지거나 되돌아오는 그래프 구조와 구별된다. 문의봇 파이프라인이 바로 체인입니다.
| 거대 프롬프트 하나 (네 기능을 한 번에) | 단계별 사슬 | |
|---|---|---|
| LLM 호출 | 1회 | 3~4회 |
| temperature | 하나만 고를 수 있음 | 기능마다 다르게 |
| 실패 위치 | 어디서 틀렸는지 모름 | 단계별로 보임 |
| 평가 | 섞여서 불가 | 기능별 평가셋 |
💡 ①과 ②는 둘 다 닫힌 답 · temperature 0이라 한 스키마로 묶어도 무리가 적습니다. 29차시의 InquiryExtraction이 이미 category를 함께 담고 있는 이유입니다. 묶을지 나눌지는 평가셋 점수로 정합니다.
7. 평가셋 확장 — 기능별 열
6차시에 만든 평가셋(실제 문의 30~100건 + 기대 결과, 개인정보는 가명)에 기능별 정답 열 을 붙입니다.
{"id": 17, "text": "(가명 처리된 원문)", "tags": ["긴메일", "여러요청"],
"category": "교환·반품",
"extract": {"customer_name": "홍길동", "order_id": "20261128-017", "contact": null, "request": "한 치수 작은 것으로 교환"},
"summary_checklist": ["운동화", "사이즈가 큼", "작은 치수로 교환", "주말 전 필요"],
"draft_forbidden": ["보상", "환불이 승인"],
"expected_tools": ["get_order"]}
🔍 읽는 포인트 — tags가 중요합니다. 결과를 태그별로 나눠 보면 약점이 보입니다. "긴메일" 태그에서만 추출 정확도가 떨어진다면 13차시의 num_ctx 잘림 을 의심합니다. 꼭 넣을 태그는 긴 메일 · 인젝션(28차시) · 정보 없음(29차시) · 여러 요청 섞임 · 도구 불필요(30차시) 입니다.
앞으로 다시 만납니다 — 33차시(요구사항 분석)에서 이 평가셋이 "충분한 품질"의 기준선 이 되고, 34차시에서 모델 · 양자화를 고를 때, 39차시에서 성능 최적화 후 품질이 떨어지지 않았는지 볼 때 같은 평가셋 을 다시 돌립니다.
8. 실습 — 맡기고 검수하기
지시
문의봇의 네 기능(분류·추출·요약·초안)을 파이프라인으로 연결하고, 기능별 평가 리포트를 만들어줘.
- 순서: 분류 → 추출 → 요약 → 초안. 기능별로 prompts/*.md 파일과 temperature를 따로 둘 것
- 분류: enum, 정확도와 혼동표 / 추출: 필드별 정확도(비교 전 공백·하이픈 정규화) + grounded() 원문 대조 실패 목록
- 요약: 평가셋의 summary_checklist 항목이 요약에 들어갔는지 표로 뽑되, 최종 판정은 내가 할 수 있게 "근거 문장"을 같이 보여줘
- 초안: 금지 표현·다른 고객 정보 자동 검사 결과
- 평가셋 eval/munuibot.jsonl 만 사용, 결과는 tags 별로도 나눠서
맥락: 지금까지 만든 25~30차시 코드 구조(포트·어댑터)를 유지할 것. 추측하지 말고 실행 출력 원문을 붙여.
보고 형식: [기능 | 지표 | 전체 | 태그별(긴메일/인젝션/정보없음/여러요청)] 표 + 실패 사례 원문
받을 증거
- 평가 리포트 표와 실행 출력 원문
- 혼동표, 원문 대조 실패 목록 (필드 · 추출값 · 원문 일부)
- 초안 금지 표현 검사에 걸린 사례 원문
내가 직접 볼 것
| 볼 것 | 왜 내가 보는가 |
|---|---|
| 요약 10건을 직접 체크리스트로 채점 | 요약 품질은 업무를 아는 사람만 판정 가능. AI의 자동 판정과 내 판정이 다르면 자동 판정을 믿지 않음 |
| 초안 10건을 직접 읽기 | 약속 표현 · 톤 · 사실 오류는 결국 사람이 고객 입장에서 읽어야 보임 |
| 원문 대조 실패 사례 | 지어낸 값인지, 형식만 다른 값인지 |
| 태그별 표에서 유독 낮은 칸 | 다음에 고칠 곳 — 프롬프트인지, 컨텍스트 길이인지, 모델인지(28차시 4절) |
부록 A. 스스로 확인하기
| # | 질문 | 답이 있는 곳 |
|---|---|---|
| 1 | 네 기능의 temperature와 사람 검토 여부는? | 1 |
| 2 | 추출과 생성을 유와 종차로 가르면? 그것이 평가 방법을 어떻게 바꾸나? | 1.1 |
| 3 | 정확도만 보지 않고 혼동표를 보는 이유는? | 2 |
| 4 | 필드별 채점 전에 정규화가 필요한 이유는? | 3 |
| 5 | 원문 대조가 잡는 것과 못 잡는 것은? | 3.1 |
| 6 | 요약 채점에서 지어낸 내용이 빠진 내용보다 무겁게 다뤄지는 이유는? | 4 |
| 7 | 답변 초안에서 코드가 검사할 것과 사람이 볼 것은? | 5 |
| 8 | 분류 → 추출 → 요약 → 초안 순서의 이유 세 가지와 위험 하나는? | 6 |
| 9 | 평가셋에 태그를 붙이는 이유는? | 7 |
부록 B. 자주 하는 실수
| 실수 | 바로잡기 |
|---|---|
| 네 기능을 같은 프롬프트 · 같은 temperature로 | ❌ 기능마다 기법 · 형식 · 평가 가 다름 |
| 분류를 전체 정확도 하나로만 판단 | ⚠️ 쏠린 데이터에서 속음. 분류값별 · 혼동표 |
| 형식만 다른 정답을 틀렸다고 셈 | ⚠️ 비교 전 정규화 |
| 요약을 정답 문장과 글자 비교 | ❌ 정답 문장은 하나가 아님. 포함 항목 체크리스트 |
| 요약 · 초안 채점을 같은 LLM에게 맡김 | ⚠️ 관대한 채점. 사람이 기준 |
| 답변 초안을 자동 발송 | ❌ 메일 발송은 되돌릴 수 없음. 상담원이 확정 |
| 네 기능을 한 프롬프트로 묶고 "어디서 틀렸는지 모르겠다" | ⚠️ 단계로 나누면 보임 |
부록 C. NotebookLM 복습 프롬프트
이 31차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"네 기능 매트릭스", "추출과 생성의 차이가 평가 방법을 바꾸는 이유", "원문 대조", "요약 체크리스트", "답변 초안의 사람 검토"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.