로컬 AI 모델용 더 나은 프롬프트 쓰는 법

로컬 모델은 최상급 채팅 제품을 작게 줄인 복사본이 아니에요. 쓸모 있는 컨텍스트가 더 짧고, 지시 따르기가 약하고, 모호한 표현을 덜 참아요. 아래 수정은 평범한 집 PC에서 출력을 바꾸는 것들이에요. 작업을 앞에 두고, 형식을 고정하고, 작업을 작게 유지하고, 프롬프트를 쉬운 말로 쓰고, 점검이 필요한 작업에만 점검을 더하고, 길이를 제한하세요.

이 패턴을 바로 복사할 수 있는 판은 로컬 LLM을 위한 최고의 프롬프트 템플릿에 있어요. 더 긴 시험 메모는 실제로 통하는 것에 있어요.

1. 지시를 원문보다 앞에 두세요

많은 로컬 모델은 프롬프트의 끝보다 시작을 더 무겁게 봐요. 긴 글을 붙여 넣고 나서야 “요약해 주세요”라고 하면, 모델이 글을 이어 쓰거나, 앞부분만 요약하거나, 원문 안에 있던 질문에 답할 수 있어요. 역할, 작업, 규칙을 먼저 적으세요. 그다음 본문:처럼 분명한 라벨 아래에 텍스트를 붙여 넣으세요.

통하는 예

아래 본문을 글머리 4개로 요약하세요. 각 글머리는 한 문장이에요. 조언은 더하지 마세요. 본문: [글을 여기에 붙여 넣으세요]
당신은 Python 검토자예요. 버그만 나열하세요. 파일을 다시 쓰지 마세요. 코드: [붙여넣기]
아래 본문을 독일어로 번역하세요. URL은 그대로 두세요. 번역 뒤에 메모는 넣지 마세요. 본문: [붙여넣기]

반대 예

[글 이천 단어를 먼저 붙여 넣음] 아 그리고 이것도 요약해 줄 수 있어요? 좋게 만들어 주세요.

실패하는 이유: 지시가 늦고, 짧고, 막연해요. 모델은 이미 글 자체가 작업인 것처럼 “읽고” 있어요. “좋게 만들어 주세요”는 좋은 것이 무엇인지 말하지 않아요. 구체적인 요약 지시를 첫 줄로 옮기고 “좋게 만들어 주세요”는 지우세요.

2. 분위기가 아니라 형식을 이름 붙이세요

“좋게”, “전문적으로”, “통찰 있게” 같은 말은 형식이 아니에요. 형식은 개수, 모양, 또는 금지예요. 로컬 모델은 취향보다 개수와 금지를 더 자주 따라요.

통하는 예

정확히 글머리 3개로 답하세요. 각 글머리는 20단어 미만이에요. 서두는 넣지 마세요.
키가 title과 summary인 JSON을 반환하세요. summary는 한 문장이에요. 마크다운 코드 펜스는 쓰지 마세요.
함수만 쓰세요. 그 뒤에 설명하지 마세요. 테스트는 넣지 마세요.

반대 예

이걸 좋고 전문적인 방식으로 요약하고, 통찰이 정말 돋보이게 해 주세요.

실패하는 이유: 길이도, 요점 개수도, 서두 금지도 없어요. 제목, 들뜬 서두, 고르지 않은 문단 다섯 개, “도움이 되었으면 합니다”가 자주 나와요. 개수와 문장 제한으로 바꾸세요.

3. 산출물은 하나만 요청하세요

초안, 번역, 제목 목록, 소셜 캡션을 한 프롬프트에 넣으면 작업이 네 개예요. 작은 모델에서는 뒤의 작업이 빠지거나 첫 작업에 섞여요. 나누세요. 직접 이을 수 있어요. 초안을 받아서 새 프롬프트를 시작하고, 번역만 요청하세요.

통하는 예

120단어 제품 설명을 쓰세요. 설명 다음에 멈추세요.
다음에 붙여 넣을 설명을 써서, 제목 후보 5개를 한 줄에 하나씩, 각각 8단어 미만으로 쓰세요.
이 고객 이메일에 90단어 미만으로 답하세요. 할인을 제안하지 마세요.

반대 예

스탠딩 책상에 대한 블로그 글을 쓰고, 프랑스어로 번역하고, 트윗 10개를 만들고, 슬라이드 개요를 설계해 주세요. 창의적으로요.

실패하는 이유: 출력이 네 개이고, 길이가 없고, “창의적으로”가 일관성과 싸워요. 모델은 대개 짧은 영어 글을 쓰고 나머지는 대충 가리켜요. 프롬프트 네 개로 나누거나, 더 큰 모델이 있고 출력에 번호를 매기면 많아야 두 개까지로 하세요.

4. 프롬프트는 출력보다 더 쉬운 말로 쓰세요

격식 있는 메모를 요청할 수 있어요. 지시 자체는 여전히 짧은 문장이어야 해요. 중첩된 절, 겹친 부정, 시스템 프롬프트 안의 전문어에서 작은 모델이 실을 놓아요.

통하는 예

격식 있는 메모를 쓰세요. 독자: 재무팀. 길이: 180단어. 포함할 것: 비용, 날짜, 필요한 결정. 프로젝트의 역사는 넣지 마세요.
DNS를 새로 온 사무 관리자에게 설명하세요. 짧은 문장을 쓰세요. 예는 하나: 브라우저가 사이트를 찾는 일. 예 다음에 멈추세요.
비밀번호를 재설정하는 단계를 나열하세요. 번호를 붙이세요. 최대 6단계. 회사 브랜드에 대한 내용은 빼세요.

반대 예

통상적인 단계별 추론 도출 패러다임과는 대조적으로, 잠재된 도구 사용 가능성을 전제하지 않은 채, 명료성과 이해관계자 공명과 인식론적 겸손을 동시에 조작화하는, 다면적이되 중복되지 않는 산출물을 종합하세요.

실패하는 이유: 지시가 작업보다 어려워요. 모델이 전문어를 따라 하거나 막연한 글로 얼어붙을 수 있어요. 누구를 위한 것인지, 얼마나 긴지, 무엇을 넣을지를 말하세요.

5. 잘 깨지는 작업에만 자체 점검을 더하세요

출력이 모양과 맞아야 할 때 자체 점검이 도움이 돼요. JSON, 고정된 글머리 개수, 산문이 들어가면 안 되는 코드. 가벼운 다시 쓰기에는 도움이 안 되고, 작은 모델에서는 답 대신 점검을 출력하게 만들 수 있어요. 한 줄만, 끝에 두세요.

통하는 예

키가 name과 date인 JSON을 반환하세요. 값이 없으면 null을 쓰세요. 답하기 전에 두 키가 있는지 확인하세요. 없으면 JSON을 고치세요. 점검을 설명하지 마세요.
글머리를 정확히 5개 쓰세요. 4개나 6개를 썼다면, 5개가 되도록 한 번 다시 쓰세요. 글머리만 출력하세요.
Python 함수만 반환하세요. 초안에 설명이 있으면 설명을 지우고 함수를 다시 반환하세요.

반대 예

아주 신중하게 생각하고, 추론을 성찰하고, 세 가지 철학적 관점에서 자신을 비판한 다음, Sam에게 생일 쪽지를 쓰세요.

실패하는 이유: 점검이 작업보다 무거워요. 원했던 것은 쪽지예요. 추론에 대한 문단과 끝에 딱딱한 쪽지가 자주 나와요. 생일 쪽지라면 자체 점검은 빼고 단어 수 제한을 두세요.

6. 프롬프트와 실행기 모두에서 길이를 제한하세요

프롬프트도 앱도 상한을 두지 않으면 로컬 모델은 늘어져요. 둘 다 정하세요. 프롬프트에는 단어 수나 글머리 수를 쓰세요. Ollama, LM Studio, Jan에서는 그 개수보다 조금 위에 최대 토큰 제한을 두어, 마지막 문장이 단어 중간에 잘리지 않고 끝나게 하세요. 프롬프트 자체의 길이가 불확실하면, 긴 원문 문서를 붙이기 전에 토큰 계산기에 넣어 보세요.

통하는 예

변경을 80에서 100단어로 설명하세요. 제목은 더하지 마세요.
글머리 4개를 주세요. 각 글머리는 한 문장이에요. 4번 글머리 다음에 멈추세요.
커밋 메시지를 쓰세요. 제목 줄은 50자 미만. 본문: 최대 2문장.

반대 예

백업에 대해 아는 것을 모두 말해 주세요. 깊게 들어가세요. 아끼지 마세요.

실패하는 이유: 끝이 없어요. 로컬 모델은 실행기의 최대 토큰에 닿을 때까지 일반적인 팁을 나열하고, 자주 반복해요. 독자와 길이를 적으세요. “집 PC 사용자에게 백업 단계 6개를, 각각 한 문장으로 주세요.”

짧은 이전과 이후

같은 요청이에요. 첫 번째는 사람들이 자주 치는 방식이고, 두 번째는 7B 모델이 따를 수 있는 판이에요.

통화 메모 좀 보고 더 좋게 만들어 주고, 할 일도 뽑아 주세요. 고마워요
이 통화 메모를 정리하세요. 목록 두 개만 반환하세요. 결정과 할 일. 할 일은 동사로 시작하세요. 담당 이름이 없으면 “담당: 적혀 있지 않음”이라고 쓰세요. 메모에 없는 할 일은 더하지 마세요. 메모: [붙여넣기]

한 번 더 다듬고 싶다면, 같은 프롬프트에서 “더 좋게도 만들어 주세요”라고 같은 모델에 요청하지 마세요. 정리된 메모와 새로운 지시 하나만 담은 새 프롬프트를 시작하세요.

이것이 고치지 못하는 것

관련 가이드와 도구