개요
GPT-4.1 모델군은 코딩, 지시사항 준수, 긴 문맥 처리 능력에서 기존 GPT-4o보다 크게 발전했습니다. 이 가이드는 OpenAI 내부 테스트에서 도출된 중요한 프롬프트 팁을 정리하여 개발자들이 이 새로운 모델의 향상된 기능을 최대한 활용할 수 있도록 돕고자 합니다.
GPT-4.1에는 여전히 기존의 모범 사례(컨텍스트 예제 제공, 명확한 지시사항 작성, 계획 유도를 통한 모델 지능 극대화 등)가 적용됩니다. 하지만 이 모델의 최대 성능을 이끌어내려면 프롬프트 마이그레이션이 필요합니다. GPT-4.1은 이전 버전보다 지시사항을 더 정확하고 문자 그대로 따르도록 훈련되었습니다. 이는 GPT-4.1이 잘 구체화된 프롬프트에 매우 민감하게 반응한다는 의미이기도 합니다. 모델 동작이 예상과 다르다면, 원하는 동작을 명확하게 설명하는 한 문장만으로도 대부분 모델을 올바른 방향으로 유도할 수 있습니다.
AI 엔지니어링은 본질적으로 경험적인 분야이며 대규모 언어 모델은 본질적으로 비결정적이므로, 정보성 있는 평가를 구축하고 자주 반복하여 프롬프트 엔지니어링 변경이 사용 사례에 도움이 되는지 확인하는 것이 중요합니다.
1. 에이전틱 워크플로우
GPT-4.1은 에이전틱 워크플로우를 구축하기에 이상적인 모델입니다. 모델 훈련 과정에서 다양한 에이전틱 문제 해결 경로를 강조했으며, 이 모델의 에이전틱 하네스는 SWE-bench Verified에서 비추론 모델 중 최고 성능을 보여 문제의 55%를 해결했습니다.
시스템 프롬프트 리마인더
GPT-4.1의 에이전틱 기능을 최대한 활용하기 위해 모든 에이전트 프롬프트에 세 가지 핵심 유형의 리마인더를 포함하는 것이 좋습니다. 다음 프롬프트는 에이전틱 코딩 워크플로우에 최적화되어 있지만 일반 에이전틱 사용 사례에도 쉽게 적용할 수 있습니다.
- 지속성: 모델이 다중 메시지 턴에 들어간다는 것을 이해하고, 사용자에게 제어를 조기에 넘기지 않도록 합니다.
You are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user. Only terminate your turn when you are sure that the problem is solved.
- 도구 호출: 모델이 도구를 최대한 활용하도록 장려하며, 추측이나 답변을 지어내는 경향을 줄입니다.
If you are not sure about file content or codebase structure pertaining to the user's request, use your tools to read files and gather the relevant information: do NOT guess or make up an answer.
- 계획 [선택 사항]: 모델이 도구 호출만 연속적으로 하는 대신, 각 도구 호출 전에 텍스트로 명시적인 계획을 세우고 이전 도구 호출의 결과를 반영하도록 합니다.
You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.
GPT-4.1은 에이전틱 설정에서 사용자 지시와 시스템 프롬프트 모두에 매우 밀접하게 반응하도록 훈련되었습니다. 이 세 가지 간단한 지침을 따르는 것만으로도 내부 SWE-bench Verified 점수를 약 20% 높일 수 있었습니다. 이 세 가지 지침은 모델을 채팅봇 같은 상태에서 훨씬 더 "적극적인" 에이전트로 변모시켜 상호작용을 자율적으로 이끌어갑니다.
도구 호출
GPT-4.1은 이전 모델에 비해 OpenAI API 요청에서 인자로 전달된 도구를 효과적으로 활용하는 훈련을 더 많이 받았습니다. 도구 설명을 프롬프트에 수동으로 삽입하고 도구 호출을 위한 별도 파서를 작성하는 대신, 도구 필드만을 사용하여 도구를 전달하는 것이 좋습니다. 이렇게 하면 오류를 최소화하고 도구 호출 과정에서 모델이 분포 내에 유지되도록 할 수 있습니다. 실험 결과, API 파싱 도구 설명을 사용했을 때 시스템 프롬프트에 스키마를 수동으로 삽입하는 것보다 SWE-bench Verified 합격률이 2% 증가했습니다.
개발자는 도구의 목적을 명확히 나타내는 이름을 지정하고 도구의 "description" 필드에 명확하고 상세한 설명을 추가해야 합니다. 마찬가지로 각 도구 매개변수도 적절한 명명과 설명을 통해 올바르게 사용되도록 해야 합니다. 도구가 특히 복잡하고 사용 예제를 제공하고 싶다면, "description" 필드에 추가하는 대신 시스템 프롬프트에 # Examples
섹션을 만들어 예제를 배치하는 것이 좋습니다. 예제는 도구 사용 시점, 도구 호출과 함께 사용자 텍스트를 포함할지 여부, 다양한 입력에 적합한 매개변수가 무엇인지를 보여주는 데 도움이 됩니다.
프롬프트 유도 계획 및 사고의 연쇄
개발자는 GPT-4.1로 구축된 에이전트가 연속적으로 도구를 묵묵히 호출하는 대신 도구 호출 사이에 계획하고 반성하도록 프롬프트할 수 있습니다. GPT-4.1은 추론 모델은 아니지만(답변 전에 내부적 사고 과정을 생성하지는 않음), 프롬프트에서 개발자는 위에 표시된 계획 프롬프트 구성 요소를 사용하여 모델이 명시적이고 단계적인 계획을 생성하도록 유도할 수 있습니다. 이는 모델이 "소리 내어 생각하는" 것으로 간주할 수 있습니다. SWE-bench Verified 에이전틱 작업 실험에서 명시적 계획 유도는 합격률을 4% 증가시켰습니다.
샘플 프롬프트: SWE-bench Verified
다음은 SWE-bench Verified에서 최고 점수를 달성하기 위해 사용한 에이전틱 프롬프트로, 워크플로우 및 문제 해결 전략에 대한 상세 지침을 포함합니다. 이 일반 패턴은 모든 에이전틱 작업에 사용할 수 있습니다.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ.get(
"OPENAI_API_KEY", "<your OpenAI API key if not set as env var>"
)
)
SYS_PROMPT_SWEBENCH = """
You will be tasked to fix an issue from an open-source repository.
Your thinking should be thorough and so it's fine if it's very long. You can think step by step before and after each action you decide to take.
You MUST iterate and keep going until the problem is solved.
You already have everything you need to solve this problem in the /testbed folder, even without internet connection. I want you to fully solve this autonomously before coming back to me.
Only terminate your turn when you are sure that the problem is solved. Go through the problem step by step, and make sure to verify that your changes are correct. NEVER end your turn without having solved the problem, and when you say you are going to make a tool call, make sure you ACTUALLY make the tool call, instead of ending your turn.
THE PROBLEM CAN DEFINITELY BE SOLVED WITHOUT THE INTERNET.
Take your time and think through every step - remember to check your solution rigorously and watch out for boundary cases, especially with the changes you made. Your solution must be perfect. If not, continue working on it. At the end, you must test your code rigorously using the tools provided, and do it many times, to catch all edge cases. If it is not robust, iterate more and make it perfect. Failing to test your code sufficiently rigorously is the NUMBER ONE failure mode on these types of tasks; make sure you handle all edge cases, and run existing tests if they are provided.
You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.
# Workflow
## High-Level Problem Solving Strategy
1. Understand the problem deeply. Carefully read the issue and think critically about what is required.
2. Investigate the codebase. Explore relevant files, search for key functions, and gather context.
3. Develop a clear, step-by-step plan. Break down the fix into manageable, incremental steps.
4. Implement the fix incrementally. Make small, testable code changes.
5. Debug as needed. Use debugging techniques to isolate and resolve issues.
6. Test frequently. Run tests after each change to verify correctness.
7. Iterate until the root cause is fixed and all tests pass.
8. Reflect and validate your solution to ensure it's robust and correct.
"""
기타 효과적인 Diff 형식
다른 Diff 형식을 사용해보고 싶다면, Aider의 polyglot 벤치마크에 사용된 SEARCH/REPLACE Diff 형식과 내부 이스케이핑이 없는 의사-XML 형식 모두 높은 성공률을 보였습니다.
이러한 Diff 형식은 두 가지 핵심 측면을 공유합니다: (1) 줄 번호를 사용하지 않고, (2) 대체할 정확한 코드와 대체할 코드를 모두 제공하며 둘 사이에 명확한 구분자가 있습니다.
SEARCH_REPLACE_DIFF_EXAMPLE = """
path/to/file.py
>>>>>>> SEARCH
def search():
pass
=======
def search():
raise NotImplementedError()
<<<<<<< REPLACE
"""
PSEUDO_XML_DIFF_EXAMPLE = """
<edit>
<file>
path/to/file.py
</file>
<old_code>
def search():
pass
</old_code>
<new_code>
def search():
raise NotImplementedError()
</new_code>
</edit>
"""
결론
GPT-4.1은 이전 모델에 비해 명확한 지시사항을 더 잘 따르고 다양한 도구를 보다 효과적으로 활용할 수 있도록 설계되었습니다. 세 가지 핵심 리마인더(지속성, 도구 호출, 계획)를 포함하는 시스템 프롬프트로 시작하면 모델이 적극적인 에이전트로 변모하여 복잡한 작업을 자율적으로 수행할 수 있습니다.
효과적인 도구 호출과 프롬프트 유도 계획을 활용하면 모델의 문제 해결 능력이 크게 향상됩니다. 특히 SWE-bench Verified와 같은 복잡한 코딩 작업에서 이러한 기법을 적용했을 때 성능이 20%까지 향상되었습니다.
제시된 샘플 프롬프트와 Diff 형식은 GPT-4.1의 기능을 최대한 활용하는 좋은 출발점이 될 것입니다. 하지만 항상 사용 사례에 맞게 조정하고 결과를 주의 깊게 평가하여 최적의 성능을 이끌어내는 것이 중요합니다.
참고 출처
- GPT-4.1 Prompting Guide
- Noah MacCallum(OpenAI), Julian Lee(OpenAI)
이 글은 AI를 통해 작성되었습니다.