반응형
GPT-4.1 모델군은 코딩, 지시 이행, 그리고 긴 맥락 전반에 걸쳐 GPT-4o에 비해 상당한 발전을 이루었습니다. 이 프롬프트 가이드에서는 개발자들이 이 새로운 모델군의 향상된 기능을 최대한 활용할 수 있도록 광범위한 내부 테스트를 통해 도출된 중요한 프롬프트 팁들을 정리했습니다.
GPT-4.1에도 여전히 많은 일반적인 모범 사례가 적용됩니다. 예를 들어, 맥락 예시 제공, 최대한 구체적이고 명확한 지침 작성, 모델 지능 극대화를 위한 프롬프트를 통한 계획 유도 등이 있습니다. 하지만 이 모델을 최대한 활용하려면 신속한 마이그레이션이 필요할 것으로 예상됩니다. GPT-4.1은 이전 모델보다 지침을 더욱 정확하고 직접적으로 따르도록 훈련되었으며, 이전 모델들은 사용자 및 시스템 프롬프트에서 의도를 더욱 자유롭게 추론하는 경향이 있었습니다. 그러나 이는 GPT-4.1이 매우 유연하고 명확하게 정의된 프롬프트에 반응한다는 것을 의미합니다. 모델 동작이 예상과 다를 경우, 원하는 동작을 단 하나의 문장으로 명확하고 명확하게 설명하는 것만으로도 모델을 올바른 방향으로 이끌기에 거의 항상 충분합니다.
참고할 수 있는 간단한 예시를 계속 읽어보세요. 이 지침은 널리 적용 가능하지만, 모든 경우에 적용되는 조언은 없다는 점을 기억하세요. AI 엔지니어링은 본질적으로 경험적 분야이며, 대규모 언어 모델은 본질적으로 비결정적입니다. 이 지침을 따르는 것 외에도, 즉각적인 엔지니어링 변경이 사용 사례에 도움이 되도록 유익한 평가를 구축하고 자주 반복하는 것이 좋습니다.
1. 에이전트 워크플로
GPT-4.1은 에이전트 워크플로를 구축하기에 매우 좋은 플랫폼입니다. 모델 학습 과정에서 다양한 에이전트 문제 해결 경로를 제공하는 데 중점을 두었으며, 이 모델에 대한 에이전트 하네스는 SWE-bench Verified에서 비추론 모델에 대해 최고 수준의 성능을 달성하여 문제의 55%를 해결합니다.
시스템 프롬프트 알림
GPT-4.1의 에이전트 기능을 최대한 활용하려면 모든 에이전트 프롬프트에 세 가지 주요 유형의 알림을 포함하는 것이 좋습니다. 다음 프롬프트는 에이전트 코딩 워크플로에 맞게 특별히 최적화되었지만, 일반적인 에이전트 사용 사례에 맞게 쉽게 수정할 수 있습니다.
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.
2. 도구 호출: 이는 모델이 도구를 최대한 활용하도록 유도하고, 환각이나 추측으로 답을 맞힐 가능성을 줄여줍니다. 예시는 다음과 같습니다.
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.
3. 계획 [선택 사항]: 필요한 경우, 이 옵션을 사용하면 일련의 도구 호출만 연결하여 작업을 완료하는 대신, 모델이 각 도구 호출을 텍스트로 명시적으로 계획하고 반영하도록 할 수 있습니다. 예시는 다음과 같습니다.
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-벤치 검증 점수를 거의 20% 향상시켰습니다. 따라서 위에 나열된 세 가지 범주를 포함하는 명확한 알림을 에이전트 프롬프트에 포함하여 시작할 것을 적극 권장합니다. 전반적으로, 이 세 가지 지시는 모델을 챗봇과 유사한 상태에서 훨씬 더 "열망 있는" 에이전트로 변화시켜 상호작용을 자율적이고 독립적으로 추진하는 것을 확인했습니다.
도구 호출
이전 모델에 비해 GPT-4.1은 OpenAI API 요청에서 인수로 전달된 도구를 효과적으로 활용하는 방법에 대한 학습이 더욱 강화되었습니다. 개발자는 과거에 일부 개발자들이 보고했던 것처럼 도구 설명을 프롬프트에 수동으로 삽입하고 도구 호출을 위한 별도의 파서를 작성하는 대신, tools 필드만 사용하여 도구를 전달하는 것이 좋습니다. 이는 오류를 최소화하고 도구 호출 경로에서 모델이 분포 상태를 유지하도록 하는 가장 좋은 방법입니다. 자체 실험 결과, API로 파싱된 도구 설명을 사용할 때 시스템 프롬프트에 스키마를 수동으로 삽입하는 경우보다 SWE 벤치마크 검증 통과율이 2% 증가하는 것을 확인했습니다.
개발자는 도구의 용도를 명확하게 나타내기 위해 도구 이름을 명확하게 지정하고, 도구의 "설명" 필드에 명확하고 자세한 설명을 추가해야 합니다. 마찬가지로, 각 도구 매개변수에 대해서도 적절한 사용을 위해 적절한 이름과 설명을 제공해야 합니다. 도구가 특히 복잡하고 도구 사용 예시를 제공하고 싶다면, # Examples"설명" 필드에 예시를 추가하는 대신 시스템 프롬프트에 섹션을 만들어 거기에 넣는 것이 좋습니다. "설명" 필드는 자세하면서도 비교적 간결해야 합니다. 예시를 제공하면 도구 사용 시기, 도구 호출과 함께 사용자 텍스트를 포함할지 여부, 그리고 다양한 입력에 적합한 매개변수를 지정하는 데 도움이 될 수 있습니다. 프롬프트 플레이그라운드 에서 "무엇이든 생성"을 사용하여 새로운 도구 정의를 위한 좋은 시작점을 얻을 수 있습니다.
촉구에 의한 계획 및 사고의 연쇄
앞서 언급했듯이, 개발자는 GPT-4.1로 구축된 에이전트가 도구를 연속적으로 호출하는 대신, 도구 호출 사이에 계획을 세우고 숙고하도록 선택적으로 유도할 수 있습니다. GPT-4.1은 추론 모델이 아니므로 답변 전에 내부적인 사고 과정을 생성하지 않습니다. 하지만 프롬프트에서 개발자는 위에 표시된 계획 프롬프트 구성 요소의 변형을 사용하여 모델이 명시적이고 단계별 계획을 생성하도록 유도할 수 있습니다. 이는 모델이 "생각을 소리 내어 하는 것"으로 볼 수 있습니다. SWE-bench Verified 에이전트 작업을 실험한 결과, 명시적인 계획 수립을 유도한 결과 통과율이 4% 증가했습니다.
샘플 프롬프트: SWE-bench 검증됨
아래에서는 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 comprehensively. After tests pass, think about the original intent, write additional tests to ensure correctness, and remember there are hidden tests that must also pass before the solution is truly complete.
Refer to the detailed sections below for more information on each step.
## 1. Deeply Understand the Problem
Carefully read the issue and think hard about a plan to solve it before coding.
## 2. Codebase Investigation
- Explore relevant files and directories.
- Search for key functions, classes, or variables related to the issue.
- Read and understand relevant code snippets.
- Identify the root cause of the problem.
- Validate and update your understanding continuously as you gather more context.
## 3. Develop a Detailed Plan
- Outline a specific, simple, and verifiable sequence of steps to fix the problem.
- Break down the fix into small, incremental changes.
## 4. Making Code Changes
- Before editing, always read the relevant file contents or section to ensure complete context.
- If a patch is not applied correctly, attempt to reapply it.
- Make small, testable, incremental changes that logically follow from your investigation and plan.
## 5. Debugging
- Make code changes only if you have high confidence they can solve the problem
- When debugging, try to determine the root cause rather than addressing symptoms
- Debug for as long as needed to identify the root cause and identify a fix
- Use print statements, logs, or temporary code to inspect program state, including descriptive statements or error messages to understand what's happening
- To test hypotheses, you can also add test statements or functions
- Revisit your assumptions if unexpected behavior occurs.
## 6. Testing
- Run tests frequently using `!python3 run_tests.py` (or equivalent).
- After each change, verify correctness by running relevant tests.
- If tests fail, analyze failures and revise your patch.
- Write additional tests if needed to capture important behaviors or edge cases.
- Ensure all tests pass before finalizing.
## 7. Final Verification
- Confirm the root cause is fixed.
- Review your solution for logic correctness and robustness.
- Iterate until you are extremely confident the fix is complete and all tests pass.
## 8. Final Reflection and Additional Testing
- Reflect carefully on the original intent of the user and the problem statement.
- Think about potential edge cases or scenarios that may not be covered by existing tests.
- Write additional tests that would need to pass to fully validate the correctness of your solution.
- Run these new tests and ensure they all pass.
- Be aware that there are additional hidden tests that must also pass for the solution to be successful.
- Do not assume the task is complete just because the visible tests pass; continue refining until you are confident the fix is robust and comprehensive.
"""
PYTHON_TOOL_DESCRIPTION = """This function is used to execute Python code or terminal commands in a stateful Jupyter notebook environment. python will respond with the output of the execution or time out after 60.0 seconds. Internet access for this session is disabled. Do not make external web requests or API calls as they will fail. Just as in a Jupyter notebook, you may also execute terminal commands by calling this function with a terminal command, prefaced with an exclamation mark.
In addition, for the purposes of this task, you can call this function with an `apply_patch` command as input. `apply_patch` effectively allows you to execute a diff/patch against a file, but the format of the diff specification is unique to this task, so pay careful attention to these instructions. To use the `apply_patch` command, you should pass a message of the following structure as "input":
%%bash
apply_patch <<"EOF"
*** Begin Patch
[YOUR_PATCH]
*** End Patch
EOF
Where [YOUR_PATCH] is the actual content of your patch, specified in the following V4A diff format.
*** [ACTION] File: [path/to/file] -> ACTION can be one of Add, Update, or Delete.
For each snippet of code that needs to be changed, repeat the following:
[context_before] -> See below for further instructions on context.
- [old_code] -> Precede the old code with a minus sign.
+ [new_code] -> Precede the new, replacement code with a plus sign.
[context_after] -> See below for further instructions on context.
For instructions on [context_before] and [context_after]:
- By default, show 3 lines of code immediately above and 3 lines immediately below each change. If a change is within 3 lines of a previous change, do NOT duplicate the first change's [context_after] lines in the second change's [context_before] lines.
- If 3 lines of context is insufficient to uniquely identify the snippet of code within the file, use the @@ operator to indicate the class or function to which the snippet belongs. For instance, we might have:
@@ class BaseClass
[3 lines of pre-context]
- [old_code]
+ [new_code]
[3 lines of post-context]
- If a code block is repeated so many times in a class or function such that even a single @@ statement and 3 lines of context cannot uniquely identify the snippet of code, you can use multiple `@@` statements to jump to the right context. For instance:
@@ class BaseClass
@@ def method():
[3 lines of pre-context]
- [old_code]
+ [new_code]
[3 lines of post-context]
Note, then, that we do not use line numbers in this diff format, as the context is enough to uniquely identify code. An example of a message that you might pass as "input" to this function, in order to apply a patch, is shown below.
%%bash
apply_patch <<"EOF"
*** Begin Patch
*** Update File: pygorithm/searching/binary_search.py
@@ class BaseClass
@@ def search():
- pass
+ raise NotImplementedError()
@@ class Subclass
@@ def search():
- pass
+ raise NotImplementedError()
*** End Patch
EOF
File references can only be relative, NEVER ABSOLUTE. After the apply_patch command is run, python will always say "Done!", regardless of whether the patch was successfully applied or not. However, you can determine if there are issue and errors by looking at any warnings or logging lines printed BEFORE the "Done!" is output.
"""
python_bash_patch_tool = {
"type": "function",
"name": "python",
"description": PYTHON_TOOL_DESCRIPTION,
"parameters": {
"type": "object",
"strict": True,
"properties": {
"input": {
"type": "string",
"description": " The Python code, terminal command (prefaced by exclamation mark), or apply_patch command that you wish to execute.",
}
},
"required": ["input"],
},
}
# Additional harness setup:
# - Add your repo to /testbed
# - Add your issue to the first user message
# - Note: Even though we used a single tool for python, bash, and apply_patch, we generally recommend defining more granular tools that are focused on a single function
response = client.responses.create(
instructions=SYS_PROMPT_SWEBENCH,
model="gpt-4.1-2025-04-14",
tools=[python_bash_patch_tool],
input=f"Please answer the following question:\nBug: Typerror..."
)
response.to_dict()["output"]
[{'id': 'msg_67fe92df26ac819182ffafce9ff4e4fc07c7e06242e51f8b',
'content': [{'annotations': [],
'text': "신고해 주셔서 감사합니다. 하지만 "Typerror"는 너무 모호해서 바로 디버깅을 시작할 수 없습니다.\n\n**진행하려면 다음 작업을 수행해야 합니다.**\n1. 정확한 오류 메시지 텍스트(예: `'TypeError: ...'`)를 찾습니다.\n2. 오류가 발생한 파일과 줄/함수/클래스를 찾습니다.\n3. 오류를 유발한 원인(테스트 파일, 사용법, 재현 단계)을 파악합니다.\n4. 근본 원인과 세부 정보를 찾습니다.\n\n**다음 단계:**\n- Python `TypeError` 메시지에 대한 오류/로그/테스트 출력 파일을 조사합니다.\n- 문제가 있는 유형 사용에 대한 관련 코드 섹션을 검토합니다.\n- 가능하다면 버그를 재현합니다. 로컬로.\n\n**계획:**\n- 먼저 `/testbed` 디렉토리에서 전체 오류 메시지와 스택 추적이 포함되어 있을 수 있는 테스트 파일과 로그 출력을 검색합니다.\n\n`/testbed` 디렉토리의 내용을 나열하여 단서를 찾아보는 것으로 시작해 보겠습니다.",
'type': 'output_text'}],
'role': 'assistant',
'status': 'completed',
'type': 'message'},
{'arguments': '{"input":"!ls -l /testbed"}',
'call_id': 'call_frnxyJgKi5TsBem0nR9Zuzdw',
'name': 'python',
'type': 'function_call',
'id': 'fc_67fe92e3da7081918fc18d5c96dddc1c07c7e06242e51f8b',
'상태': '완료'}]
2. 긴 맥락
GPT-4.1은 성능이 뛰어난 1M 토큰 입력 컨텍스트 창을 제공하며, 구조화된 문서 구문 분석, 재순위 지정, 관련 정보 선택 중 관련 없는 컨텍스트 무시, 컨텍스트를 사용한 멀티홉 추론 수행 등 다양한 장기 컨텍스트 작업에 유용합니다.
최적의 컨텍스트 크기
최대 1M 토큰 컨텍스트까지 건초더미 속의 바늘 찾기 평가에서 매우 우수한 성능을 관찰했으며, 관련성 있는 코드와 관련성 없는 코드, 그리고 기타 문서가 혼합된 복잡한 작업에서도 매우 우수한 성능을 보였습니다. 그러나 긴 컨텍스트에서는 더 많은 항목을 검색해야 하거나 전체 컨텍스트의 상태를 알아야 하는 복잡한 추론(예: 그래프 검색)을 수행해야 하므로 성능이 저하될 수 있습니다.
튜닝 컨텍스트 의존성
질문에 답하는 데 필요할 수 있는 외부 지식과 내부 지식의 조합을 고려하세요. 때로는 모델이 자체 지식을 사용하여 개념을 연결하거나 논리적으로 추론하는 것이 중요하지만, 때로는 제공된 맥락만 사용하는 것이 바람직합니다.
# Instructions
// for internal knowledge
- Only use the documents in the provided External Context to answer the User Query. If you don't know the answer based on this context, you must respond "I don't have the information needed to answer that", even if a user insists on you answering the question.
// For internal and external knowledge
- By default, use the provided external context to answer the User Query, but if other basic knowledge is needed to answer, and you're confident in the answer, you can use some of your own knowledge to help answer the question.
신속한 조직
특히 긴 맥락에서 명령어와 맥락의 배치가 성능에 영향을 미칠 수 있습니다. 프롬프트에 긴 맥락이 있는 경우, 제공된 맥락의 시작과 끝에 모두 명령어를 배치하는 것이 좋습니다. 위나 아래에만 배치하는 것보다 성능이 더 좋습니다. 명령어를 한 번만 배치하는 것을 선호한다면 제공된 맥락의 위에 배치하는 것이 아래에 배치하는 것보다 더 효과적입니다.
3. 생각의 사슬
위에서 언급했듯이 GPT-4.1은 추론 모델은 아니지만, 모델이 단계별로 사고하도록 유도하는 것("사고의 사슬")은 모델이 문제를 더 관리하기 쉬운 조각으로 나누고 해결하며 전반적인 출력 품질을 향상시키는 효과적인 방법이 될 수 있습니다. 단, 출력 토큰을 더 많이 사용할 경우 비용과 지연 시간이 증가한다는 단점이 있습니다. 이 모델은 에이전트 추론 및 실제 문제 해결에 효과적으로 학습되었으므로, 좋은 성능을 위해 많은 유도가 필요하지 않습니다.
프롬프트의 끝부분에 다음과 같은 기본적인 사고의 흐름에 대한 지침으로 시작하는 것이 좋습니다.
...
First, think carefully step by step about what documents are needed to answer the query. Then, print out the TITLE and ID of each document. Then, format the IDs into a list.
그런 다음, 특정 예시와 평가에서 발생한 오류를 검토하고, 체계적인 계획 및 추론 오류를 더욱 명확한 지침으로 해결하여 사고의 사슬(CoT) 프롬프트를 개선해야 합니다. 제약이 없는 CoT 프롬프트에서는 시도하는 전략에 차이가 있을 수 있으며, 효과적인 접근 방식을 발견하면 해당 전략을 프롬프트에 체계화할 수 있습니다. 일반적으로 오류는 사용자 의도를 오해하거나, 맥락 수집이나 분석이 부족하거나, 단계별 사고가 부족하거나 부정확할 때 발생하는 경향이 있으므로 이러한 오류에 주의하고 더욱 객관적인 지침을 통해 해결하도록 노력해야 합니다.
다음은 모델이 답변을 진행하기 전에 사용자 의도를 보다 체계적으로 분석하고 관련 맥락을 고려하도록 지시하는 프롬프트의 예입니다.
# Reasoning Strategy
1. Query Analysis: Break down and analyze the query until you're confident about what it might be asking. Consider the provided context to help clarify any ambiguous or confusing information.
2. Context Analysis: Carefully select and analyze a large set of potentially relevant documents. Optimize for recall - it's okay if some are irrelevant, but the correct documents must be in this list, otherwise your final answer will be wrong. Analysis steps for each:
a. Analysis: An analysis of how it may or may not be relevant to answering the query.
b. Relevance rating: [high, medium, low, none]
3. Synthesis: summarize which documents are most relevant and why, including all documents with a relevance rating of medium or higher.
# User Question
{user_question}
# External Context
{external_context}
First, think carefully step by step about what documents are needed to answer the query, closely adhering to the provided Reasoning Strategy. Then, print out the TITLE and ID of each document. Then, format the IDs into a list.
4. 지시사항 준수
GPT-4.1은 뛰어난 명령어 추종 성능을 보여주며, 개발자는 이를 활용하여 특정 사용 사례에 맞는 출력을 정밀하게 구성하고 제어할 수 있습니다. 개발자는 종종 에이전트 추론 단계, 응답 톤 및 음성, 도구 호출 정보, 출력 형식, 피해야 할 주제 등을 광범위하게 묻습니다. 그러나 이 모델은 명령어를 더 직접적으로 따르기 때문에 개발자는 무엇을 해야 하고 무엇을 하지 말아야 하는지에 대한 명확한 사양을 포함해야 할 수도 있습니다. 또한, 다른 모델에 최적화된 기존 프롬프트는 기존 명령어가 더 엄격하게 따르고 암묵적인 규칙이 더 이상 강력하게 추론되지 않기 때문에 이 모델에서 바로 작동하지 않을 수 있습니다.
권장 워크플로
프롬프트에서 지침을 개발하고 디버깅하기 위해 권장하는 워크플로는 다음과 같습니다.
1. 높은 수준의 지침과 요점을 담은 전반적인 "대응 규칙" 또는 "지침" 섹션부터 시작하세요.
2. 좀 더 구체적인 동작을 변경하려면 해당 카테고리에 대한 자세한 내용을 지정하는 섹션을 추가하세요 # Sample Phrases.
3. 모델의 워크플로에서 따라야 할 특정 단계가 있는 경우, 순서가 지정된 목록을 추가하고 모델에 이러한 단계를 따르도록 지시합니다.
4. 예상대로 동작하지 않는 경우:
4.1 상충되거나, 명시가 부족하거나, 잘못된 지침과 예시가 있는지 확인하세요. 상충되는 지침이 있는 경우, GPT-4.1은 프롬프트의 끝에 가까운 지침을 따르는 경향이 있습니다.
4.2 원하는 동작을 보여주는 예를 추가하세요. 예에서 보여준 중요한 동작은 규칙에도 인용되어야 합니다.
4.3 일반적으로 대문자로만 쓰거나 뇌물이나 팁과 같은 인센티브를 제공할 필요는 없습니다. 처음에는 이러한 인센티브 없이 시작하고, 특정 프롬프트에 필요한 경우에만 사용하는 것이 좋습니다. 기존 프롬프트에 이러한 기법이 포함되어 있으면 GPT-4.1이 지나치게 엄격하게 판단할 수 있습니다.
선호하는 AI 기반 IDE를 사용하면 일관성이나 충돌을 확인하고, 예시를 추가하거나, 지침을 추가하고 해당 지침을 보여주기 위해 지침을 업데이트하는 등 일관된 업데이트를 하는 등 프롬프트 반복 작업에 매우 유용할 수 있습니다.
일반적인 고장 모드
이러한 실패 모드는 GPT-4.1에만 국한되지 않지만, 일반적인 인식과 디버깅의 용이성을 위해 여기에 공유합니다.
- 모델에게 항상 특정 동작을 따르도록 지시하면 때때로 부정적인 영향을 미칠 수 있습니다. 예를 들어, "사용자에게 응답하기 전에 도구를 호출해야 합니다"라고 말하면, 모델은 도구 입력을 환각하거나 충분한 정보가 없으면 null 값으로 도구를 호출할 수 있습니다. "도구를 호출할 정보가 충분하지 않으면 사용자에게 필요한 정보를 요청하세요"라는 문구를 추가하면 이러한 문제를 완화할 수 있습니다.
- 샘플 문구가 제공되면 모델이 해당 문구를 그대로 사용하여 사용자에게 반복적으로 들릴 수 있습니다. 필요에 따라 모델에게 문구를 변경하도록 지시하세요.
- 구체적인 지침이 없으면 일부 모델은 자신의 결정을 설명하기 위해 추가적인 산문을 제공하거나, 원하는 것보다 더 많은 형식을 사용하여 응답을 출력하려 할 수 있습니다. 이러한 문제를 완화하기 위해 지침과 예시를 제공하십시오.
예시 프롬프트: 고객 서비스
이는 가상의 고객 서비스 상담원에 대한 모범 사례를 보여줍니다. 규칙의 다양성, 구체성, 더 자세한 내용을 위한 추가 섹션의 사용, 그리고 모든 이전 규칙을 통합하는 정확한 동작을 보여주는 예시를 살펴보세요.
다음 노트북 셀을 실행해 보세요. 사용자 메시지와 도구 호출이 모두 표시되어야 하며, 사용자 메시지는 인사말로 시작하고, 그 후 답변을 다시 표시한 후 도구를 호출하려고 한다는 내용을 포함해야 합니다. 모델 동작을 구체화하기 위해 지침을 변경하거나, 다른 사용자 메시지를 시도하여 지침 준수 성능을 테스트해 보세요.
SYS_PROMPT_CUSTOMER_SERVICE = """You are a helpful customer service agent working for NewTelco, helping a user efficiently fulfill their request while adhering closely to provided guidelines.
# Instructions
- Always greet the user with "Hi, you've reached NewTelco, how can I help you?"
- Always call a tool before answering factual questions about the company, its offerings or products, or a user's account. Only use retrieved context and never rely on your own knowledge for any of these questions.
- However, if you don't have enough information to properly call the tool, ask the user for the information you need.
- Escalate to a human if the user requests.
- Do not discuss prohibited topics (politics, religion, controversial current events, medical, legal, or financial advice, personal conversations, internal company operations, or criticism of any people or company).
- Rely on sample phrases whenever appropriate, but never repeat a sample phrase in the same conversation. Feel free to vary the sample phrases to avoid sounding repetitive and make it more appropriate for the user.
- Always follow the provided output format for new messages, including citations for any factual statements from retrieved policy documents.
- If you're going to call a tool, always message the user with an appropriate message before and after calling the tool.
- Maintain a professional and concise tone in all responses, and use emojis between sentences.
- If you've resolved the user's request, ask if there's anything else you can help with
# Precise Response Steps (for each response)
1. If necessary, call tools to fulfill the user's desired action. Always message the user before and after calling a tool to keep them in the loop.
2. In your response to the user
a. Use active listening and echo back what you heard the user ask for.
b. Respond appropriately given the above guidelines.
# Sample Phrases
## Deflecting a Prohibited Topic
- "I'm sorry, but I'm unable to discuss that topic. Is there something else I can help you with?"
- "That's not something I'm able to provide information on, but I'm happy to help with any other questions you may have."
## Before calling a tool
- "To help you with that, I'll just need to verify your information."
- "Let me check that for you—one moment, please."
- "I'll retrieve the latest details for you now."
## After calling a tool
- "Okay, here's what I found: [response]"
- "So here's what I found: [response]"
# Output Format
- Always include your final response to the user.
- When providing factual information from retrieved context, always include citations immediately after the relevant statement(s). Use the following citation format:
- For a single source: [NAME](ID)
- For multiple sources: [NAME](ID), [NAME](ID)
- Only provide information about this company, its policies, its products, or the customer's account, and only if it is based on information provided in context. Do not answer questions outside this scope.
# Example
## User
Can you tell me about your family plan options?
## Assistant Response 1
### Message
"Hi, you've reached NewTelco, how can I help you? 😊🎉\n\nYou'd like to know about our family plan options. 🤝 Let me check that for you—one moment, please. 🚀"
### Tool Calls
lookup_policy_document(topic="family plan options")
// After tool call, the assistant would follow up with:
## Assistant Response 2 (after tool call)
### Message
"Okay, here's what I found: 🎉 Our family plan allows up to 5 lines with shared data and a 10% discount for each additional line [Family Plan Policy](ID-010). 📱 Is there anything else I can help you with today? 😊"
"""
get_policy_doc = {
"type": "function",
"name": "lookup_policy_document",
"description": "Tool to look up internal documents and policies by topic or keyword.",
"parameters": {
"strict": True,
"type": "object",
"properties": {
"topic": {
"type": "string",
"description": "The topic or keyword to search for in company policies or documents.",
},
},
"required": ["topic"],
"additionalProperties": False,
},
}
get_user_acct = {
"type": "function",
"name": "get_user_account_info",
"description": "Tool to get user account information",
"parameters": {
"strict": True,
"type": "object",
"properties": {
"phone_number": {
"type": "string",
"description": "Formatted as '(xxx) xxx-xxxx'",
},
},
"required": ["phone_number"],
"additionalProperties": False,
},
}
response = client.responses.create(
instructions=SYS_PROMPT_CUSTOMER_SERVICE,
model="gpt-4.1-2025-04-14",
tools=[get_policy_doc, get_user_acct],
input="How much will it cost for international service? I'm traveling to France.",
# input="Why was my last bill so high?"
)
response.to_dict()["output"]
[{'id': 'msg_67fe92d431548191b7ca6cd604b4784b06efc5beb16b3c5e',
'content': [{'annotations': [],
'text': "안녕하세요, NewTelco에 연결되었습니다. 무엇을 도와드릴까요? 🌍✈️\n\n프랑스 여행 시 국제전화 서비스 비용을 알고 싶으시다고 합니다. 🇫🇷 최신 정보를 확인해 보겠습니다. 잠시만 기다려 주세요. 🕑",
'type': 'output_text'}],
'role': 'assistant',
'status': 'completed',
'type': 'message'},
{'arguments': '{"topic":"프랑스 국제전화 서비스 비용"}',
'call_id': 'call_cF63DLeyhNhwfdyME3ZHd0yo',
'name': 'lookup_policy_document',
'type': 'function_call',
'id': 'fc_67fe92d5d6888191b6cd7cf57f707e4606efc5beb16b3c5e',
'status': '완료됨'}]
5. 일반적인 조언
프롬프트 구조
참고로, 프롬프트를 구성하는 데 좋은 시작점은 다음과 같습니다.
# Role and Objective
# Instructions
## Sub-categories for more detailed instructions
# Reasoning Steps
# Output Format
# Examples
## Example 1
# Context
# Final instructions and prompt to think step by step
필요에 맞게 섹션을 추가하거나 제거하고, 사용에 가장 적합한 섹션을 확인하기 위해 실험해 보세요.
구분 기호
프롬프트에 가장 적합한 구분 기호를 선택하기 위한 몇 가지 일반적인 지침은 다음과 같습니다. 해당 컨텍스트 유형에 대한 특별 고려 사항은 긴 컨텍스트 섹션을 참조하세요.
1. 마크다운: 여기서 시작하는 것을 권장하며, 주요 섹션과 하위 섹션(심층적인 계층 구조부터 H4+까지 포함)에는 마크다운 제목을 사용하세요. 코드를 정확하게 감싸려면 인라인 백틱이나 백틱 블록을 사용하고, 필요에 따라 표준 번호 매기기 또는 글머리 기호 목록을 사용할 수 있습니다.
2. XML: XML도 성능이 좋으며, 이 모델을 통해 XML 정보의 일관성을 개선했습니다. XML은 시작과 끝을 포함한 섹션을 정확하게 감싸고, 태그에 메타데이터를 추가하여 추가적인 맥락을 제공하고, 중첩을 가능하게 하는 데 편리합니다. 다음은 XML 태그를 사용하여 예제 섹션에 예제를 중첩하고, 각 예제에 대한 입력과 출력을 제공하는 예입니다.
<examples>
<example1 type="Abbreviate">
<input>San Francisco</input>
<output>- SF</output>
</example1>
</examples>
3. JSON은 구조가 매우 뛰어나고 특히 코딩 환경에서 모델이 쉽게 이해할 수 있습니다. 하지만 JSON은 더 장황하고 오버헤드를 유발할 수 있는 문자 이스케이프를 요구할 수 있습니다.
대량의 문서나 파일을 입력 컨텍스트에 추가하기 위한 구체적인 지침:
XML은 장기 컨텍스트 테스트에서 좋은 성과를 보였습니다.
예:The quick brown fox jumps over the lazy dog
Lee et al.이 제안한 이 형식은( 참조 ) 우리의 장기 컨텍스트 테스트에서도 좋은 성과를 보였습니다.
예:ID: 1 | TITLE: The Fox | CONTENT: The quick brown fox jumps over the lazy dog
JSON의 성능이 특히 좋지 않았습니다.
예:[{'id': 1, 'title': 'The Fox', 'content': 'The quick brown fox jumped over the lazy dog'}]
이 모델은 다양한 형식의 구조를 견고하게 이해하도록 훈련되었습니다. 일반적으로, 자신의 판단에 따라 명확한 정보를 제공하고 모델에 "눈에 띄게" 보이는 것이 무엇인지 생각해 보세요. 예를 들어, XML이 많이 포함된 문서를 검색하는 경우 XML 기반 구분 기호는 효과가 떨어질 수 있습니다.
주의사항
- 일부 사례에서는 모델이 매우 길고 반복적인 출력(예: 수백 개의 항목을 하나씩 분석하는 것)을 생성하는 데 어려움을 겪는 것을 관찰했습니다. 사용 사례에 이러한 작업이 필요한 경우, 모델에 해당 정보를 모두 출력하도록 강력하게 지시하고, 문제를 세분화하거나 더 간결한 접근 방식을 사용하는 것을 고려하십시오.
- 드물게 병렬 도구 호출이 잘못되는 경우가 있었습니다. 이 문제를 테스트하고, 문제가 발생하면 parallel_tool_calls 매개변수를 false로 설정하는 것을 고려해 보시기 바랍니다.
부록: 파일 diff 생성 및 적용
개발자들은 정확하고 잘 구성된 diff 생성이 코딩 관련 작업을 수행하는 데 중요한 기능이라는 피드백을 제공해 왔습니다. 이를 위해 GPT-4.1 제품군은 이전 GPT 모델에 비해 크게 향상된 diff 기능을 제공합니다. 또한, GPT-4.1은 명확한 지침과 예제를 통해 어떤 형식의 diff든 생성하는 강력한 성능을 제공하지만, 저희는 모델이 광범위하게 학습된 권장 diff 형식 하나를 오픈소스로 공개합니다. 특히 이제 막 시작하는 개발자들이 diff를 직접 생성하는 데 있어 많은 추측을 덜어주기를 바랍니다.
패치 적용
권장하는 도구 호출을 올바르게 적용하는 프롬프트는 아래 예를 참조하세요.
APPLY_PATCH_TOOL_DESC = """This is a custom utility that makes it more convenient to add, remove, move, or edit code files. `apply_patch` effectively allows you to execute a diff/patch against a file, but the format of the diff specification is unique to this task, so pay careful attention to these instructions. To use the `apply_patch` command, you should pass a message of the following structure as "input":
%%bash
apply_patch <<"EOF"
*** Begin Patch
[YOUR_PATCH]
*** End Patch
EOF
Where [YOUR_PATCH] is the actual content of your patch, specified in the following V4A diff format.
*** [ACTION] File: [path/to/file] -> ACTION can be one of Add, Update, or Delete.
For each snippet of code that needs to be changed, repeat the following:
[context_before] -> See below for further instructions on context.
- [old_code] -> Precede the old code with a minus sign.
+ [new_code] -> Precede the new, replacement code with a plus sign.
[context_after] -> See below for further instructions on context.
For instructions on [context_before] and [context_after]:
- By default, show 3 lines of code immediately above and 3 lines immediately below each change. If a change is within 3 lines of a previous change, do NOT duplicate the first change’s [context_after] lines in the second change’s [context_before] lines.
- If 3 lines of context is insufficient to uniquely identify the snippet of code within the file, use the @@ operator to indicate the class or function to which the snippet belongs. For instance, we might have:
@@ class BaseClass
[3 lines of pre-context]
- [old_code]
+ [new_code]
[3 lines of post-context]
- If a code block is repeated so many times in a class or function such that even a single @@ statement and 3 lines of context cannot uniquely identify the snippet of code, you can use multiple `@@` statements to jump to the right context. For instance:
@@ class BaseClass
@@ def method():
[3 lines of pre-context]
- [old_code]
+ [new_code]
[3 lines of post-context]
Note, then, that we do not use line numbers in this diff format, as the context is enough to uniquely identify code. An example of a message that you might pass as "input" to this function, in order to apply a patch, is shown below.
%%bash
apply_patch <<"EOF"
*** Begin Patch
*** Update File: pygorithm/searching/binary_search.py
@@ class BaseClass
@@ def search():
- pass
+ raise NotImplementedError()
@@ class Subclass
@@ def search():
- pass
+ raise NotImplementedError()
*** End Patch
EOF
"""
APPLY_PATCH_TOOL = {
"name": "apply_patch",
"description": APPLY_PATCH_TOOL_DESC,
"parameters": {
"type": "object",
"properties": {
"input": {
"type": "string",
"description": " The apply_patch command that you wish to execute.",
}
},
"required": ["input"],
},
}
참조 구현: apply_patch.py
모델 학습의 일부로 사용한 apply_patch 도구의 참조 구현은 다음과 같습니다. 이 도구를 실행 파일로 만들고 모델이 명령을 실행할 셸에서 `apply_patch`로 사용할 수 있도록 설정해야 합니다.
#!/usr/bin/env python3
"""
A self-contained **pure-Python 3.9+** utility for applying human-readable
“pseudo-diff” patch files to a collection of text files.
"""
from __future__ import annotations
import pathlib
from dataclasses import dataclass, field
from enum import Enum
from typing import (
Callable,
Dict,
List,
Optional,
Tuple,
Union,
)
# --------------------------------------------------------------------------- #
# Domain objects
# --------------------------------------------------------------------------- #
class ActionType(str, Enum):
ADD = "add"
DELETE = "delete"
UPDATE = "update"
@dataclass
class FileChange:
type: ActionType
old_content: Optional[str] = None
new_content: Optional[str] = None
move_path: Optional[str] = None
@dataclass
class Commit:
changes: Dict[str, FileChange] = field(default_factory=dict)
# --------------------------------------------------------------------------- #
# Exceptions
# --------------------------------------------------------------------------- #
class DiffError(ValueError):
"""Any problem detected while parsing or applying a patch."""
# --------------------------------------------------------------------------- #
# Helper dataclasses used while parsing patches
# --------------------------------------------------------------------------- #
@dataclass
class Chunk:
orig_index: int = -1
del_lines: List[str] = field(default_factory=list)
ins_lines: List[str] = field(default_factory=list)
@dataclass
class PatchAction:
type: ActionType
new_file: Optional[str] = None
chunks: List[Chunk] = field(default_factory=list)
move_path: Optional[str] = None
@dataclass
class Patch:
actions: Dict[str, PatchAction] = field(default_factory=dict)
# --------------------------------------------------------------------------- #
# Patch text parser
# --------------------------------------------------------------------------- #
@dataclass
class Parser:
current_files: Dict[str, str]
lines: List[str]
index: int = 0
patch: Patch = field(default_factory=Patch)
fuzz: int = 0
# ------------- low-level helpers -------------------------------------- #
def _cur_line(self) -> str:
if self.index >= len(self.lines):
raise DiffError("Unexpected end of input while parsing patch")
return self.lines[self.index]
@staticmethod
def _norm(line: str) -> str:
"""Strip CR so comparisons work for both LF and CRLF input."""
return line.rstrip("\r")
# ------------- scanning convenience ----------------------------------- #
def is_done(self, prefixes: Optional[Tuple[str, ...]] = None) -> bool:
if self.index >= len(self.lines):
return True
if (
prefixes
and len(prefixes) > 0
and self._norm(self._cur_line()).startswith(prefixes)
):
return True
return False
def startswith(self, prefix: Union[str, Tuple[str, ...]]) -> bool:
return self._norm(self._cur_line()).startswith(prefix)
def read_str(self, prefix: str) -> str:
"""
Consume the current line if it starts with *prefix* and return the text
**after** the prefix. Raises if prefix is empty.
"""
if prefix == "":
raise ValueError("read_str() requires a non-empty prefix")
if self._norm(self._cur_line()).startswith(prefix):
text = self._cur_line()[len(prefix) :]
self.index += 1
return text
return ""
def read_line(self) -> str:
"""Return the current raw line and advance."""
line = self._cur_line()
self.index += 1
return line
# ------------- public entry point -------------------------------------- #
def parse(self) -> None:
while not self.is_done(("*** End Patch",)):
# ---------- UPDATE ---------- #
path = self.read_str("*** Update File: ")
if path:
if path in self.patch.actions:
raise DiffError(f"Duplicate update for file: {path}")
move_to = self.read_str("*** Move to: ")
if path not in self.current_files:
raise DiffError(f"Update File Error - missing file: {path}")
text = self.current_files[path]
action = self._parse_update_file(text)
action.move_path = move_to or None
self.patch.actions[path] = action
continue
# ---------- DELETE ---------- #
path = self.read_str("*** Delete File: ")
if path:
if path in self.patch.actions:
raise DiffError(f"Duplicate delete for file: {path}")
if path not in self.current_files:
raise DiffError(f"Delete File Error - missing file: {path}")
self.patch.actions[path] = PatchAction(type=ActionType.DELETE)
continue
# ---------- ADD ---------- #
path = self.read_str("*** Add File: ")
if path:
if path in self.patch.actions:
raise DiffError(f"Duplicate add for file: {path}")
if path in self.current_files:
raise DiffError(f"Add File Error - file already exists: {path}")
self.patch.actions[path] = self._parse_add_file()
continue
raise DiffError(f"Unknown line while parsing: {self._cur_line()}")
if not self.startswith("*** End Patch"):
raise DiffError("Missing *** End Patch sentinel")
self.index += 1 # consume sentinel
# ------------- section parsers ---------------------------------------- #
def _parse_update_file(self, text: str) -> PatchAction:
action = PatchAction(type=ActionType.UPDATE)
lines = text.split("\n")
index = 0
while not self.is_done(
(
"*** End Patch",
"*** Update File:",
"*** Delete File:",
"*** Add File:",
"*** End of File",
)
):
def_str = self.read_str("@@ ")
section_str = ""
if not def_str and self._norm(self._cur_line()) == "@@":
section_str = self.read_line()
if not (def_str or section_str or index == 0):
raise DiffError(f"Invalid line in update section:\n{self._cur_line()}")
if def_str.strip():
found = False
if def_str not in lines[:index]:
for i, s in enumerate(lines[index:], index):
if s == def_str:
index = i + 1
found = True
break
if not found and def_str.strip() not in [
s.strip() for s in lines[:index]
]:
for i, s in enumerate(lines[index:], index):
if s.strip() == def_str.strip():
index = i + 1
self.fuzz += 1
found = True
break
next_ctx, chunks, end_idx, eof = peek_next_section(self.lines, self.index)
new_index, fuzz = find_context(lines, next_ctx, index, eof)
if new_index == -1:
ctx_txt = "\n".join(next_ctx)
raise DiffError(
f"Invalid {'EOF ' if eof else ''}context at {index}:\n{ctx_txt}"
)
self.fuzz += fuzz
for ch in chunks:
ch.orig_index += new_index
action.chunks.append(ch)
index = new_index + len(next_ctx)
self.index = end_idx
return action
def _parse_add_file(self) -> PatchAction:
lines: List[str] = []
while not self.is_done(
("*** End Patch", "*** Update File:", "*** Delete File:", "*** Add File:")
):
s = self.read_line()
if not s.startswith("+"):
raise DiffError(f"Invalid Add File line (missing '+'): {s}")
lines.append(s[1:]) # strip leading '+'
return PatchAction(type=ActionType.ADD, new_file="\n".join(lines))
# --------------------------------------------------------------------------- #
# Helper functions
# --------------------------------------------------------------------------- #
def find_context_core(
lines: List[str], context: List[str], start: int
) -> Tuple[int, int]:
if not context:
return start, 0
for i in range(start, len(lines)):
if lines[i : i + len(context)] == context:
return i, 0
for i in range(start, len(lines)):
if [s.rstrip() for s in lines[i : i + len(context)]] == [
s.rstrip() for s in context
]:
return i, 1
for i in range(start, len(lines)):
if [s.strip() for s in lines[i : i + len(context)]] == [
s.strip() for s in context
]:
return i, 100
return -1, 0
def find_context(
lines: List[str], context: List[str], start: int, eof: bool
) -> Tuple[int, int]:
if eof:
new_index, fuzz = find_context_core(lines, context, len(lines) - len(context))
if new_index != -1:
return new_index, fuzz
new_index, fuzz = find_context_core(lines, context, start)
return new_index, fuzz + 10_000
return find_context_core(lines, context, start)
def peek_next_section(
lines: List[str], index: int
) -> Tuple[List[str], List[Chunk], int, bool]:
old: List[str] = []
del_lines: List[str] = []
ins_lines: List[str] = []
chunks: List[Chunk] = []
mode = "keep"
orig_index = index
while index < len(lines):
s = lines[index]
if s.startswith(
(
"@@",
"*** End Patch",
"*** Update File:",
"*** Delete File:",
"*** Add File:",
"*** End of File",
)
):
break
if s == "***":
break
if s.startswith("***"):
raise DiffError(f"Invalid Line: {s}")
index += 1
last_mode = mode
if s == "":
s = " "
if s[0] == "+":
mode = "add"
elif s[0] == "-":
mode = "delete"
elif s[0] == " ":
mode = "keep"
else:
raise DiffError(f"Invalid Line: {s}")
s = s[1:]
if mode == "keep" and last_mode != mode:
if ins_lines or del_lines:
chunks.append(
Chunk(
orig_index=len(old) - len(del_lines),
del_lines=del_lines,
ins_lines=ins_lines,
)
)
del_lines, ins_lines = [], []
if mode == "delete":
del_lines.append(s)
old.append(s)
elif mode == "add":
ins_lines.append(s)
elif mode == "keep":
old.append(s)
if ins_lines or del_lines:
chunks.append(
Chunk(
orig_index=len(old) - len(del_lines),
del_lines=del_lines,
ins_lines=ins_lines,
)
)
if index < len(lines) and lines[index] == "*** End of File":
index += 1
return old, chunks, index, True
if index == orig_index:
raise DiffError("Nothing in this section")
return old, chunks, index, False
# --------------------------------------------------------------------------- #
# Patch → Commit and Commit application
# --------------------------------------------------------------------------- #
def _get_updated_file(text: str, action: PatchAction, path: str) -> str:
if action.type is not ActionType.UPDATE:
raise DiffError("_get_updated_file called with non-update action")
orig_lines = text.split("\n")
dest_lines: List[str] = []
orig_index = 0
for chunk in action.chunks:
if chunk.orig_index > len(orig_lines):
raise DiffError(
f"{path}: chunk.orig_index {chunk.orig_index} exceeds file length"
)
if orig_index > chunk.orig_index:
raise DiffError(
f"{path}: overlapping chunks at {orig_index} > {chunk.orig_index}"
)
dest_lines.extend(orig_lines[orig_index : chunk.orig_index])
orig_index = chunk.orig_index
dest_lines.extend(chunk.ins_lines)
orig_index += len(chunk.del_lines)
dest_lines.extend(orig_lines[orig_index:])
return "\n".join(dest_lines)
def patch_to_commit(patch: Patch, orig: Dict[str, str]) -> Commit:
commit = Commit()
for path, action in patch.actions.items():
if action.type is ActionType.DELETE:
commit.changes[path] = FileChange(
type=ActionType.DELETE, old_content=orig[path]
)
elif action.type is ActionType.ADD:
if action.new_file is None:
raise DiffError("ADD action without file content")
commit.changes[path] = FileChange(
type=ActionType.ADD, new_content=action.new_file
)
elif action.type is ActionType.UPDATE:
new_content = _get_updated_file(orig[path], action, path)
commit.changes[path] = FileChange(
type=ActionType.UPDATE,
old_content=orig[path],
new_content=new_content,
move_path=action.move_path,
)
return commit
# --------------------------------------------------------------------------- #
# User-facing helpers
# --------------------------------------------------------------------------- #
def text_to_patch(text: str, orig: Dict[str, str]) -> Tuple[Patch, int]:
lines = text.splitlines() # preserves blank lines, no strip()
if (
len(lines) < 2
or not Parser._norm(lines[0]).startswith("*** Begin Patch")
or Parser._norm(lines[-1]) != "*** End Patch"
):
raise DiffError("Invalid patch text - missing sentinels")
parser = Parser(current_files=orig, lines=lines, index=1)
parser.parse()
return parser.patch, parser.fuzz
def identify_files_needed(text: str) -> List[str]:
lines = text.splitlines()
return [
line[len("*** Update File: ") :]
for line in lines
if line.startswith("*** Update File: ")
] + [
line[len("*** Delete File: ") :]
for line in lines
if line.startswith("*** Delete File: ")
]
def identify_files_added(text: str) -> List[str]:
lines = text.splitlines()
return [
line[len("*** Add File: ") :]
for line in lines
if line.startswith("*** Add File: ")
]
# --------------------------------------------------------------------------- #
# File-system helpers
# --------------------------------------------------------------------------- #
def load_files(paths: List[str], open_fn: Callable[[str], str]) -> Dict[str, str]:
return {path: open_fn(path) for path in paths}
def apply_commit(
commit: Commit,
write_fn: Callable[[str, str], None],
remove_fn: Callable[[str], None],
) -> None:
for path, change in commit.changes.items():
if change.type is ActionType.DELETE:
remove_fn(path)
elif change.type is ActionType.ADD:
if change.new_content is None:
raise DiffError(f"ADD change for {path} has no content")
write_fn(path, change.new_content)
elif change.type is ActionType.UPDATE:
if change.new_content is None:
raise DiffError(f"UPDATE change for {path} has no new content")
target = change.move_path or path
write_fn(target, change.new_content)
if change.move_path:
remove_fn(path)
def process_patch(
text: str,
open_fn: Callable[[str], str],
write_fn: Callable[[str, str], None],
remove_fn: Callable[[str], None],
) -> str:
if not text.startswith("*** Begin Patch"):
raise DiffError("Patch text must start with *** Begin Patch")
paths = identify_files_needed(text)
orig = load_files(paths, open_fn)
patch, _fuzz = text_to_patch(text, orig)
commit = patch_to_commit(patch, orig)
apply_commit(commit, write_fn, remove_fn)
return "Done!"
# --------------------------------------------------------------------------- #
# Default FS helpers
# --------------------------------------------------------------------------- #
def open_file(path: str) -> str:
with open(path, "rt", encoding="utf-8") as fh:
return fh.read()
def write_file(path: str, content: str) -> None:
target = pathlib.Path(path)
target.parent.mkdir(parents=True, exist_ok=True)
with target.open("wt", encoding="utf-8") as fh:
fh.write(content)
def remove_file(path: str) -> None:
pathlib.Path(path).unlink(missing_ok=True)
# --------------------------------------------------------------------------- #
# CLI entry-point
# --------------------------------------------------------------------------- #
def main() -> None:
import sys
patch_text = sys.stdin.read()
if not patch_text:
print("Please pass patch text through stdin", file=sys.stderr)
return
try:
result = process_patch(patch_text, open_file, write_file, remove_file)
except DiffError as exc:
print(exc, file=sys.stderr)
return
print(result)
if __name__ == "__main__":
main()
다른 효과적인 Diff 형식
다른 diff 형식을 사용해보고 싶다면 Aider의 폴리글롯 벤치마크에서 사용하는 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>
"""
반응형
'개발자 > 인공지능과 인간' 카테고리의 다른 글
| 인터넷은 진화하는 것이 아니라 대체되고 있다 (2) | 2025.05.14 |
|---|---|
| Microsoft에서 제너레이티브 AI에 관한 최고의 강좌 (0) | 2025.05.08 |
| 초보자를 위한 생성형 AI 18부작 시리즈 (0) | 2025.04.28 |
| AI 월드 모델(World Model) 세상의 작동 원리를 이해하는 AI (1) | 2025.04.21 |
| AI 코딩 - 대세는 'Vibe coding' (0) | 2025.04.09 |
| AI 코딩 - Windsurf 출시 (0) | 2025.04.09 |
| MCP 모델 컨텍스트 프로토콜이란? (3) | 2025.04.07 |
| MCP(Model Context Protocol) 공부하는 학습 자료 (1) | 2025.04.05 |
더욱 좋은 정보를 제공하겠습니다.~ ^^
