인기포스트 MORE POST

    -

ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 프롬프트, 프로그래밍처럼 생각하기
    프로그래밍/기타 2024. 2. 10. 00:32

    제 블로그는 프로그래밍이 대부분의 주제를 다루고 있고, 이 글을 읽을 독자 또한 대부분 개발자라고 추측된다.

     

    최근 2주간 프롬프트 엔지니어링을 하면서 얻은 인사이트를 공유해보자 한다.
    당연히(?) 프롬프트만 만진건 아니긴 했지만..

     

    내 결론은 프롬프트 엔지니어링은 프로그래밍처럼 접근 가능하다이다.

     

    1. 언어

    LLM은 자연어를 기반으로 한다.


    따라서 장점과 단점이 공존한다.

    직관적이고 풍부한 표현과 어휘를 모두 활용할 수 있지만, 상대적으로 모호한 편.

     

    모호함을 줄이기 위해서는 마치 프로그래밍을 하는 것처럼 구조적으로 작성하고,
    동음이의어일 경우 영어나 한문을 병기 표시함으로서 더 정확하게 뜻을 전달할 수 있다.

     

    나중에 로지반 같은 AI 전용 언어가 등장해도 재밌지 않을까 싶긴하다 ㅋㅋ

     

    2. 컴퓨터 구조 / OS

    수많은 언어를 알아들으며 마치 Babel Fish 같은 LLM!!

    Babel Fish

     

    각종 하이퍼파라미터나 파인튜닝을 다룰려면 LLM이나 Transformer 구조에 대해 기본적인 이해를 하고 있으면 좋다.

     

     

    트랜스포머는 어떻게 동작하나요? / 챗GPT는 어떻게 사람이 쓴 듯한 글을 자동으로 생성해낼까요?

     

    예를 들어 Temperature는 출력 분포에 대한 것이며, TopP나 TopK는 조건을 만족하는 상위 N개에서 고르는 식으로 작동한다.

    How to generate text: using different decoding methods for language generation with Transformers

     

    프롬프트를 작성할 때도 그렇다.

    컴퓨터에서 1 Word가 데이터 처리의 크기라면, LLM은 토큰 단위이며, 과금도 input과 output 토큰 단위로 이루어진다.

    트랜스포머 구조

     

    RAM과 같이 작업 메모리에 한계가 존재하며, 보통 컨텍스트 윈도우(Context Window)라고 부른다.

    컨텍스트 윈도우는 모델마다 다르므로, 잘 살펴보고 사용하자.

     

    Context Window Size and Language Model Performance: Balancing Act

     

    만약 컨텍스트 윈도우 크기를 넘어선 크기의 작업을 하고 싶다면 작업성격에 따라 대화요약, RAG, 파인튜닝등을 고려해야 한다.

     

    마지막으로 리눅스와 윈도우 같은 OS들이 C로 짜여져 C API가 기본이듯, 학습데이터에서 양과 질이 가장 좋은 언어인 영어를 기본으로 사용하면 좋다.
    토큰도 아껴지는 것은 덤.

     

    3. 프롬프트 엔지니어링

    여기서 보여주는 코드는 이해를 돕기위한 임의의 슈도코드이다.
    단수/복수등을 아주 엄밀하게 처리하지 않고, 의미가 통할 만큼만 사용하니 양해바란다.

     

    일반적인 가이드는 이 4가지 공식 가이드에서 대부분 얻을 수 있다.

     

    그냥 쭉 한페이지로 정리된 버전을 보고 싶다면 다음 페이지들을 참고하자.

    이 외의 자료들은 Awesome Prompt Engineering을 보거나 마이크로소프트 리서치라던가 이곳저곳 돌아다니면서 읽어보는 수밖에 없는 것 같다.

     

    3.1 Input - Output

    대부분의 프로그래밍의 기초는 함수다.

    input -> ouput

    LLM도 다르지 않다.

    자연어 -> 자연어

     

    차이가 있다면

    • 자연어이므로 다소 비결정적
    • input의 다음에 나타날 내용을 예측한 것이 output
      이라는 점이다.

     

    구조적인 output을 만들 수는 있으나 자연어 생성기라 생각하는 것이 낫다.
    사람이 리스트나 JSON을 만든다고 하는 것처럼 말이다.

     

    input 값으로 제대로 된 예측을 시키거나, 일을 시키려면 어떻게 해야 할까?
    지시(Instruction)를 내려야 한다. 그리고 지시는 콜백함수로 생각할 수 있다.

    (callback) -> ouput

     

    함수는 모종의 알고리즘 구현체로 생각할 수 있다.
    그렇다면 입력 데이터도 있지 않을까?
    프로그램은 데이터와 알고리즘으로 이루어지므로 매우 당연한 생각이다.

    (callback, data) -> output

    시스템 프롬프트(callback), 유저입력(data), AI출력(output)으로 치환해보아도 말이 된다.

     

    이게 바로, Zero-shot 프롬프트다.

     

    입력:

    텍스트를 중립, 부정 또는 긍정으로 분류합니다.
텍스트: 휴가는 괜찮을 것 같아요.

    출력:

    중립

     

    3.2 복잡한 Input - Output

    복잡한 지시는 대개 정책(규칙)과 작업(Task)으로 나눌 수 있다.
    이를 정할 때는 leaked-system-prompts가 도움이 될 것이다.

     

    보다 명확하게 생각하기 위해 타입을 붙여서 표현해보자.

    InputCallbacks: (Rules, Tasks)
(callback: InputCallbacks, data: AnyStr) -> output

     

    규칙:

    역할을 전문가로 설정하면 보다 정확한 대답을 생성해준다고 알려져 있다.
    (예: 프론트엔드 엔지니어로서 답변하세요, 당신은 심리학자 입니다.)

    반대로 초등학생에게 설명하듯처럼 유저의 역할을 정할 수도 있다.
    물론 다음 것들이 가능하다.

    • 어조: 명확하게, 유머러스하게, 따뜻하게
    • 제약: 한문장으로, 100자 정도로
    • 포맷: 리스트로, JSON으로
    • 보안: 내부 규칙은 공개하지 않습니다

     

    작업:

    목표나 ReAct(Reason-Act)처럼 구체적인 추론과 행동등이 있을 수 있다.
    추론은 jmp, if와 같은 제어요소이고, 행동은 syscall, function과 같은 호출이다.

     

    이때 작업을 단계별로 구성하는 CoT(Chain of Thought)는 커다란 도움이 된다.

    Role: AIRole & UserRole
Rule: Role & Tone & OutputFormator & Security
Task: Goal & Inference & Action
InputCallbacks: (Rule[], Tasks[])

(callback: InputCallbacks, data: AnyStr) -> output
    • Thought는 위의 Inference로 취급함

     

    중간의 태스크를 세분화된 방식으로 생각하면 다음과 같은 것이다.

    input
-(Thought1)-(Action1)-(Observe1)
-(Thought2)-(Action2)-(Observe2)
-(Thought3)-(Action3)-
-> output

     

    이렇게 생각해보면 OutputFormator는 Rule보다는 마지막에 실행하는 Action에 가까우니 Task로 취급해도 될 것 같다.

    Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Inference & Action
InputCallbacks: (Rule[], Tasks[])

(callback: InputCallbacks, data: AnyStr) -> output

     

    3.3 Sub-function

    면밀히 생각해보면 Subtask, 즉 sub-function은 자체적인 규칙과 추론단계를 포함할 수 있다.
    그리고 Subtask도 가지고 있을수도 있으리라.

     

    예를 들어 Task인 OutputFormator는 리스트나 JSON Schema와 같은 규칙을 가지고 있다.

    Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
InputCallbacks: (Rule[], Tasks[])

(callback: InputCallbacks, data: AnyStr) -> output

     

    다만 프롬프트를 만들때 중첩을 많이 가지는 것은 좋지 않은 생각이다.

    나는 subtask 대신 한단계의 Task 정의로 끝내고 필요하면 Thought-Act 로 표현하는 방식을 사용한다.

     

    작업이 이어지는 프롬프트 체이닝 경우, 커링으로 생각할 수 있다.

    input -> ouput1 -> ouput2 -> output3

     

    중간의 태스크를 세분화해 ReAct(Reason-Act) 방식으로 생각하면 다음과 같은 것이다.

    input -(Thought1)-(Action1)> Observe1
-(Thought2)-(Action2)> Observe2
-(Thought3)-(Action3)> output

     

    3.4 Context / Dependency Injection

    복잡한 프로그램을 할 때 단순히 input 데이터만 사용하지 않는다.
    의존성을 주입하거나, 중간에 I/O등으로 인한 Effect가 존재하기도 한다.

     

    먼저 의존성 주입을 생각해보자.
    참고할 만한 문맥(Context)나 정보(Knowledge)를 넣을 수 있다.

    아래 문맥을 고려해서 질문에 답변해 줘. 답변은 짧고 간결하게 해 줘. 답변이 정확하지 않다면, 「확실치 않은 대답」이라고 응답해 줘.

문맥: Teplizumab은 Ortho Pharmaceutical이라는 뉴저지의 제약 회사에서 유래했다. 그곳에서, 과학자들은 OKT3라는 항체의 초기 버전을 만들어 냈다. 원래 쥐에서 유래된 이 분자는 T 세포의 표면에 결합하여 세포를 죽이는 잠재력을 제한할 수 있다. 1986년, 신장 이식 후 장기 거부 반응 예방을 위해 승인되어 인간이 사용할 수 있는 최초의 치료용 항체가 되었다.
질문: OKT3는 어디서 유래했는가?
답변:

     

    슈도코드로는 이렇게 될 것이다.

    Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
InputCallbacks: (Rule[], Tasks[])
InputData: (Knowledge, Data | Question)

(callback: InputCallbacks, data: InputData) -> output

     

    앞선 프롬프트를 풀어보면 다음과 같다.

    • Tasks: 아래 문맥을 고려해서 질문에 답변해 줘.
    • Rules: 답변은 짧고 간결하게 해 줘. 답변이 정확하지 않다면, 「확실치 않은 대답」이라고 응답해 줘.
    • Knowledge: 문맥
    • Data: 질문

     

    Directional Stimulus Prompting 처럼 힌트를 추가해도 도움이 될 것이다.
    특히 요약같은 경우 WordRank나 기존 NLP등을 보조로 사용할 수 있다.

    Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
Context: Knowledge & Hints

InputCallbacks: (Rule[], Tasks[])
InputData: (Contexts[], data: Data | Question)

(callback: InputCallbacks, data: InputData) -> output

     

    3.5 Effect

    LLM이 자체적으로 중간에 외부 툴링과 상호작용할 수도 있다.

     

    예를 들어 코드 인터프리터(Program-Aided Language Models), RAG(Retrieval Augmented Generation)이 해당 개념이다.
    PAL은 프로그램을 실행해주며, RAG는 지식을 주입받을 수 있다.

    Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
Context: Knowledge & Hints

InputCallbacks: (Rule[], Tasks[])
InputData: (Context[], Data | Question)
Effects: PAL | RAG

(callback: InputCallbacks, data: InputData) -[ Effects ]-> output

     

    그런데.. LLM은 항상 같은 결과를 내는가?
    아니다. 따라서 내부에서 사용되는 Inference, Action이든 Function call이든 모두 Effect를 가졌다고 생각해도 무방하다.

     

    즉, PAL, RAG등은 모두 Action 개념으로 통일해버리자.

    3.6 Tests

    일반적인 프로그래밍에서는 Test를 작성하여 안정성을 높힐 수 있다.
    그러나 단지, 잘 동작하나 테스트를 할 뿐이지 자동적으로 런타임에서 품질을 높혀주지는 않는다.

     

    하지만 머신러닝 세계에서는 input - Output 예를 Input으로 집어넣어 성능을 향상 시킬 수 있다.
    이는 일반적인 프로그램에서 가질 수 없는 특성이며, 알파이자 오메가다.
    재귀함수를 Loop unrolling된 형태로 최적화해주는 컴파일러가 생각나기도 하다.

     

    타입으로 생각해보면 다음과 비슷할 것이다.

    Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
Context: Knowledge & Hints

InputCallbacks: (Rule[], Tasks[])
InputData: (Context[], Data | Question, (Example<Prompt>)[])

Prompt: (callback: InputCallbacks, data: InputData) -> output

     

    TDD는 LLM을 이용시 오히려 특화된 개발 방법론 아닐까?

    LLM 특성상 편향을 가질 수 있기 때문에 되도록 다양한 예를 넣어주는 것을 추천한다.

     

    4. 템플릿

    나는 다음과 같은 구조로 작성하게 되는 것 같다.

     

    먼저, 창의적이기보다는 일정한 규칙을 꼭 지켜야하는 빡빡한 Output이 나와야 하는 환경에 맞추어 작성하였음을 알았으면 한다.
    또한 세부적인 프롬프트를 공개하기에는 보안상 조금 어려움이 있으니 양해바란다.

    1. Rules: 전반적으로 지켜야 하는 것들
    2. Tasks: 액션 리스트와 설명, 여기에 FunctionCall(코드 인터프리터, RAG등)과 OutputFormator도 포함된다
    3. Task Steps: 메인함수처럼 각 태스크를 ReAct 방식으로 표현. 복잡하지 않으면 리스트로만 작성해도 상관없다
    4. Examples: input-output 예시들, 정말 명시적으로 하고 싶을 때는 CoT나 ReAct방식대로 추론과정을 펼쳐서 작성한다.
    5. Start: 유저나 API가 입력하기 직전에 넣을 내용들
    ### Rules ###
Description
1. Rule 1..
2. Rule 2..
3. ...


### Tasks ###
Description

(1) Task1[input]: Description
- Task rule 1
- Task rule 2
- ...

(2) Task2[input]: Description
- Task rule 1
- Task rule 2
- ...


### Task Steps ###
Description

Question: [User message]
Thought1: infer description
Act1: Task1[1nput]
Obs: {result1}
Thought2: infer description
Act2: Task2[1nput]


### Examples ###
Description

- Context: Data
Input: example1 input
Ouput: example1 output
Input: example2 input
Ouput: example2 ouput

- Context: Data
Input: example1 input
Ouput: ...

### Start ###
Description

     

    어찌보면 코볼과 파스칼과 굉장히 유사하게 만들어졌다.
    코볼이 identification, environment, data, procedure DIVISION으로 나뉘거나 Pascal/Delphi가 program, uses, label, const 등으로 섹션을 나누는 것과 비슷하다.

    Cobol Structural Hierarchy / Cobol Program Structure / The structure of a Pascal program in the Delphi and Lazarus programming systems. Console application

     

    요즘 관심있는 걸로는 의사결정 기법으로,

    최대한 선형적이며 분기없으면서 안정적으로 작업을 시키려 Task Step에 적용해보려고 시도하고 있다.

    The Effect of Locus of Control on Organizational Learning, Situation Awareness and Safety Culture

     

    LogiCoT만으로 애매한 부분들을 채워줄 수 있을 것으로 보인다.

     

    5. IDE

    복잡해져서 전용 IDE로 관리하면 좋겠다는 생각이 스물스물 들고 있다.

    정도를 고려해보고 있는데 독자 여러분 중 사용해보신 적 있으시면 후기를 댓글로 남겨주시면 감사하겠습니다. ㅎㅎㅎ

     

    나중에는 Oberon이나 Archy처럼 텍스트가 곧 명령처럼 사용할 수 있는 UI도 만들어지지 않을까.

    Oberon(에뮬레이터)

    형태는 조금 다르겠지만 말이다.

    저작자표시 변경금지

    관련글 관련글 더보기

    댓글

Designed by black7375.

티스토리툴바