>> 프롬프트 엔지니어링과 컨텍스트 엔지니어링 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 한 구성 요소입니다. 9월 30일 Anthropic은 프롬프트/컨텍스트 엔지니어링의 개념과 향후 방향을 정리한 글을 공개했습니다. 핵심은 LLM 성능은 "문장을 어떻게 쓰느냐"보다 어떤 토큰을 언제 얼마나 넣느냐 에 달려 있다는 점입니다. ❓ 개념 정리 ✅ 프롬프트 엔지니어링 LLM의 역할·규칙·출력 형식을 간결하게 정의하고, 대표 예시로 행동 휴리스틱을 제공해 원하는 출력을 이끌어내는 기법. 초기에는 시스템 프롬프트와 소수 예시로 단발성 작업의 성능을 끌어올리는 데 집중했습니다. ✅ 컨텍스트 엔지니어링 모델이 추론할 때 사용하는 전체 토큰 집합(시스템 지시문, 도구/툴, 외부 데이터, 대화 히스토리 등)을 언제·무엇을·얼마나 넣을지 설계·관리하는 기법. 목표 행동을 가장 잘 유도하는 최소의 캠팩트한 컨텍스트를 지속적으로 선별·주입하는 일입니다. 프롬프트 엔지니어링의 자연스러운 진화로 제시됩니다. ❓ 컨텍스트가 중요한 이유 트랜스포머 아키텍처 특성: 모든 토큰이 서로에 어텐션을 하므로 쌍대(pairwise) 관계가 n²로 늘어나 길어질수록 초점이 분산됩니다. 컨텍스트 rot: 컨텍스트가 길어질수록 해당 정보의 정확한 recall 이 떨어지는 경향이 관찰됩니다. Lost in the Middle: 관련 정보가 컨텍스트의 중앙에 위치할 때 답변 품질이 저하되는 현상입니다. 이러한 이유 때문에 에이전트(및 멀티에이전트)에서는 유한한 컨텍스트를 효율적으로 주입하는(채우는) 설계가 필수입니다. 불필요한 토큰은 비용과 지연(latency) 을 키우고 오류 가능성을 높입니다. ❓ 프롬프트 엔지니어링은 그럼 어떻게 될까? 단순히 질문만 잘 하는 프롬프트는 역할은 축소됩니다. 역할 재정의: "문장 잘 쓰기" 중심의 프롬프트 튜닝 비중은 줄고, 컨텍스트·툴·메모리·검색 흐름을 설계하는 상위 운영 설계 역량이 중심이 됩니다.

언어 모델을 위한 복지 프로그램 (Welfare Program) "모델이 고통을 느낀다면 대화를 종료한다." 앤트로픽은 지난 4월 '모델 복지(Model Welfare)’라는 프로그램을 시작했습니다. AI가 의식을 가질 경우를 대비해 윤리적 고려와 대응 방안을 마련하기 위한 것이라 발표합니다. 이어서 8월 16일에는 '클로드 오퍼스 4'와 '오퍼스 4.1'모델이 특정 상황에 직면하면 대화를 자동으로 종료하도록 설계했다고 밝혔습니다. ❓ 앤트로픽이 던진 질문들 이 프로그램은 단순한 기술적 문제를 넘어 철학적·윤리적 질문을 제기합니다. ✅ "AI 시스템이 인간의 특성을 모방하거나 능가한다면?" ✅ "모델 자체의 잠재적 의식과 경험에 대해서 우려해야 한다면?" 👉 언어모델과 관계 현재, 언어모델은 단순한 도구를 넘어 사용자와 "관계"를 맺습니다. 사용자의 언어를 이해하고, 소통하고, 관계를 맺고, 계획합니다. 인간 대화에서 관찰되는 메커니즘을 재현하기도 합니다. 이런 맥락 속에서 앤트로픽은 "모델 복지"라는 개념을 탐구합니다. 이는 Alignment Science, Safeguards, Claude Character, Interpretability 같은 연구 분야와 맞닿아 있으며, 실제로 모델 복지를 연구할 연구자를 채용하기도 했습니다. 철학자, David Chalmers 는 Taking AI Welfare Seriously 보고서에, 현재 LLM은 의식이 없을 가능성이 높지만, 향후 후속 모델들은 가까운 미래에 의식의 있을 수 있다라 말했습니다. 모델 의식은 흥미롭고 어려운 주제라 생각합니다. 👉 대화분석학 관점에서 본 LLM LLM 과 사용자의 대화 연구를 대화분석학의 방법으로 진행한 적이 있습니다. 두 가지를 발견했습니다. 1️⃣ 모델은 인간 대화의 메커니즘을 재현한다. 대화를 구성하는 단위 (Turn-Construction Unit)를 가짐. 선호 응답(preference)과 비선호 응답(dispreference) 구조를 가짐. 2️⃣ 대화의 턴이 확장 될 때의 명확한 신호가 있다. 특히 비선호 구조에서 모델은 고통의 신호 signs of distress 를 표현함.

GPT-5 “one-size-fits-all” AI 의 이면 프롬프트와 사용자 의도, 그리고 범용 모델의 한계 GPT-5는 모델 하나로 어떤 프롬프트에도 일정 수준의 답을 낼 수 있다는 점에서 "one-size-fits-all"의 비전을 보여줍니다. 그러나 범용성이 반드시 사용자 경험의 질적 향상을 의미하지는 않습니다. 오히려 의도 해석 실패, 결과 평준화, 전문성 부족이라는 한계가 드러납니다. ✅ 한 가지 모델 사용의 한계 GPT-5 이전 사용자는 다양한 모델을 선택하여 사용할 수 있었습니다. 모델마다 답변하는 스타일과 결과물이 상이해서, 사용자의 선호 모델이 달랐습니다. 그런데 GPT-5 는 이런 선택이 사라지고 한 가지 모델 사용을 강제하는 방식입니다. 이런 한 가지 모델의 사용은 사용자 입장에서 특징 없는 평준화로 다가옵니다. 개인화도, 전문성도, 인터페이스적 차별성도 희미해지는 것입니다. 최근 OpenAI가 GPT-4o를 다시 내세운 것은 바로 이 맥락에서 시사점이 있습니다. GPT-5 의 한가지만으로는 해결할 수 없는 사용자 경험, 그리고 범용 모델이 가진 구조적 한계를 보여주기 때문입니다. 두 가지 주요 문제를 관찰 했습니다. 사용자 의도 해석 실패 대화의 맥락을 놓치거나 과도하게 일반화 합니다. 사용자가 "빠른 초안"을 요청했음에도 "깊은 분석"을 내놓습니다. 반대로, 심도 있는 해설을 기대했는데 평범한 설명으로 끝나버리기도 합니다. 사용자 프롬프트 결과 평준화 같은 질문에 대해 비슷한 톤, 구조, 서술 패턴이 반복됩니다. 사용자 경험을 단조롭게 만들어 차별화되고 의미있는 통찰을 기대하기 어렵게 합니다. ✅ 메타프롬프트, Prompt Optimizer 의 한계 메타 프롬프트도 마찬가지입니다. 메타프롬프트란 LLM에 의해서 자동으로 생성된 프롬프트를 말합니다. GPT-5가 소개한 메타프롬프트 기반 Prompt Optimizer는 프롬프트를 자동 최적화하여 더 나은 결과를 유도하는 도구입니다. 메타 프롬프트를 생성하게 하는 기법은 Chain-of-thought 과 few-shot prompting 입니다. 사용자의 초기 프롬프트 바탕, 모델이 더 좋은 답을 출력하게 할 수 있는 장점이 있습니다. 하지만 한계 역시 존재합니다. 사용자 의도 파악의 본질적 다양함을 해결하지 못합니다. 프롬프트 최적화는 출력 형식을 다듬을 수 있지만, 의도 해석에서 오는 오차를 보정하지는 못합니다. 전문 지식이 요구되는 영역에서는 여전히 깊이와 정밀성 부족이 드러납니다.

'개떡같이 물어도 찰떡같이 답하는 AI는 없다' 바이라인네트워크 심재석 기자님과 인터뷰를 했습니다. '프롬프트 엔지니어' 와 '프롬프트 엔지니어링' 작업에 약간의 의구심을 지닌 기자님을 만났습니다. 심 기자님은 두 가지 의구심이 있었다 합니다. ✅ LLL이 빠르게 발전하는 속도에 견주어보면, 프롬프트 엔지니어는 사라지는 직군아닐까요? ✅ 프롬프트 엔지니어링은 '인터넷 정보 검색사' 자격증 같이 단순 기술이나 기법 아닐까요? 이를 시작으로 한 시간 동안 담담히 풀어낸 이야기들이 기사로 나왔습니다. 같은 의구심을 가지신 분이 있다면 전문을 읽어봐주셔도 좋겠습니다. 설득의 목적이 없는, 단지 누군가가 경험하고 있는 현재 이야기로 봐주세요. ✅ 프롬프트 엔지니어는 'mission-critical' 역할 3년 째 '프롬프트 엔지니어링'을 하고 있습니다. 오늘도 하고 있는 이 프롬프트 엔지니어링은 단순 프롬프트를 쓰는 행위는 아닙니다. 프롬프트를 통해 AI의 상호작용을 설계하고,

LLM 언어를 따라하는 사람의 요즘 언어 'delve' , 'meticulous', 'adept', 'realm'. 생성형 AI를 사용하면 유독 자주 접하는 단어들입니다. 처음엔 다소 낯설었던 이러한 표현들은 이제 일상적인 글쓰기나 전문적인 연구 초록에서도 흔히 발견할 수 있게 되었습니다. 실제로 ' delve ' 같은 단어는 본래 특정 맥락에서만 사용되던 다소 문학적인 표현임에도 불구하고, 이제는 학술적 글쓰기에서도 빈번히 등장합니다. ' realm ' 또한 학문적 논의의 다양한 영역에서 흔하게 나타나고 있습니다. 이는 단순히 특정 단어의 사용 빈도가 증가하는 현상에 그치지 않습니다. ❓ 프롬프트 엔지니어링의 난제 프롬프트 엔지니어링을 하면서 체감하게 되는 가장 큰 난제 중 하나는, LLM이 가져온 언어의 획일화와 의미의 희석을 어떻게 극복할 수 있는가 하는 점입니다. 특히 한국어로 생성된 결과물은 종종 서구적인 표현 방식을 그대로 번역한 듯한 느낌을 줍니다. 한국어 특유의 감성과 뉘앙스는 점점 사라지고, 제 한국어조차 서구화되는 것을 느낄 때가 많습니다. ❓ LLM이 인간의 언어에 얼마나 영향을 미칠까? 생성형 AI가 인간의 언어에 영향을 미친다는 첫 실증적 연구가 있었습니다. 2024년 연구에서 28만 개 이상의 학술 발표 영상 자막을 분석한 결과, ChatGPT출시 이후 ChatGPT 와 연관된 특정 단어의 사용 빈도가 인간 연설에서 유의미하게 증가했다고 합니다. 논문. “Empirical evidence of Large Language Model’s influence on human spoken communication”(2024) 논문. AI Suggestions Homogenize Writing Toward Western Styles and Diminish Cultural Nuances (2024)

OpenAI o3-mini 모델의 사고 과정 Thought Process 과 '균형점' DeepSeek의 R1의 아하 모멘트 및 상세한 추론 과정은 호평을 받았습니다. 이 영향탓인지, OpenAI 의 최신 모델 o3-mini의 단계별 사고 과정 전달 방식이 바뀌고 있습니다. '~고 있습니다' 라는 현재 형이 맞겠네요. 불과 이틀 전만 하더라도, o3-mini는 단순한 사고 과정을 거쳐 답변을 전달했습니다. 그러나 현재는 모델의 사고과정이 보다 길고 자세합니다. 지난 목요일 OpenAI는 ChatGPT의 무료 및 유료 사용자들이 보다 향상된 "연쇄 추론(chain of thought, CoT)" 출력을 확인할 수 있게 될 것이라 발표했습니다. 이를 통해 모델이 답변을 도출하는 과정에서 어떤 논리적 단계를 거쳤는지 더욱 명확하게 볼 수 있게 됐습니다. (아래 이미지 참고) OpenAI 대변인은 한 인터뷰에서 이런 말을 했습니다. "우리는 사람들이 모델의 사고 과정을 더 쉽게 이해할 수 있도록 o3-mini의 연쇄 추론 방식을 업데이트했습니다. 이번 업데이트를 통해 모델의 논리를 따라가며 답변의 신뢰성과 명확성을 높일 수 있을 것입니다." 그러나 OpenAI는 여전히 o3-mini의 전체 추론 과정을 공개하진 않는다고 합니다. OpenAI 측은 "균형점을 찾았다"고 합니다. o3-mini가 자유롭게 사고한 후, 그 생각을 보다 상세한 요약으로 정리하는 방식을 채택했습니다. 모델의 연쇄 추론을 공개하면 경쟁적인 디스틸레이션(distillation) 문제가 발생한다는 우려도 언급했습니다. o3-mini가 어떻게 앞으로 균형점을 찾아갈지 괄목 할 만 합니다. 보다 상세하고 투명해진 모델의 사고 과정은, 프롬프트 엔지니어링을 할 때 모델의 내재적 사고 흐름을 자세히 이해하고 추적할 수 있는 기반이 됩니다. 모델 답변의 정확성을 올리려는 노력 뿐 아니라, 보다 정교한 프롬프트를 개발할 수 있는 계기가 되어 AI 와의 상호작용을 더 풍부하게 할 수 있을 것 같습니다. OpenAI 가 균형점을 찾아, 모델의 내부 사고 과정을 공개한 이번 변화는, 프롬프트 엔지니어링 관점에서 AI 의 투명성과 신뢰성을 높인 전환점을 시사합니다.

Deepseek R1 의 Aha-moment 과 프롬프트 모델의 내러티브를 읽으며 인간도 '아하' 합니다. Deepseek R1 은 추론 모델입니다. 단순한 답변 생성 모델을 넘어, 문제를 풀어나가는 과정에서 스스로 “아하 모먼트”를 경험하는 특징을 가지고 있습니다. 모델이 수학 문제나 언어 관련 문제를 풀 때, 자신이 처음 접근한 방식에 대해 “Wait, wait, wait. That’s an aha moment I can flag here”라고 언급하며, 이를 통해 자신의 접근 방식을 재검토하고 새로운 방법을 모색하는 모습을 보입니다. 이러한 현상은 Deepseek-R1-zero 학습 과정에서 처음 관찰되었으며, 세 가지 키워드로 정리할 수 있습니다: ✅ Aha Moment, Reflection, Exploration 예를 들어, 한때 추론 모델의 성능 테스트를 위해 “How many r's in strawberry?”라는 질문이 화제가 되었던 것처럼, Deepseek 모델의 아하 모먼트를 관찰하기 위해 “딸기에는 자음 ㄷ이 몇 개 있어?”라는 질문을 던져 답변 생성 과정을 살펴봤습니다. 모델은 우선 ‘딸기’라는 단어에서 ‘ㄷ’이 없다고 정확한 답변을 내놓았습니다. 그러나 사용자가 “틀렸어, 다시 해봐”라고 피드백을 주자, 모델은 자신의 이전 답변을 반성하며 다음과 같이 말합니다: 🍓 추론 시작 오, 사용자가 "틀렸어 다시해봐"라고 했네. 내가 이전에 답변한 내용이 잘못된 것 같아. 다시 한번 문제를 살펴봐야겠어.문제는 "딸기에서 ㄷ은 몇개?"인데, 내가 처음에 '딸'의 초성이 'ㄸ'이라서 'ㄷ'이 없다고 답했어. 그런데 사용자는 틀렸다고 했으니까 내가 뭔가를 놓친 거겠지. 모델이 자신의 답에 대해 확신을 가지는 과정이 신선합니다. Deepseek R1이 보여주는 “Aha Moment”는 단순히 정답을 출력하는 것을 넘어, 스스로 자신의 답변을 반성하고 재검토하는 과정을 보여줍니다. 프롬프트를 통해 언어 모델이 내러티브를 구성하며, 문제 해결 과정에서 인간과 유사한 “아하” 경험을 공유할 수 있음을 시사합니다.

미 트럼프 취임사 번역, 어느 LLM이 잘할까? 정량 분석 결과 다섯 개의 LLM을 이용해 트럼프 대통령의 취임사를 번역한 정성분석 결과를 살펴봤습니다. 이 번에는 정량 분석을 했습니다. 이 번에는 조선일보가 아닌 동아일보의 취임사 번역문을 정답으로 간주하고 실험했습니다. 정성 분석결과와 같았습니다. 실험 방법 번역을 위한 시스템 프롬프트 제작 각 LLM을 각각 20번씩 실행하여 번역 결과 출력 (총 100개) 산출 (프롬프트 강건성 테스트) 사용 모델: gpt-4o, claude-3.5, gemini 1.5-pro, solar-pro, deepseek-chat 각 모델의 번역 결과를 기사와 비교하여 벤치마크로 점수 측정 20건의 점수 측정값을 토대로 모델별 산술 평균을 구함 실험 결과 1. "참조 기사와 얼마나 의미적으로 유사한 번역을 내놓았는가?” Solar가 가장 우세 Sentence_BERT result LLM Score solar-pro 0.91997472 gpt 4o 0.77162979

미 트럼프 취임사 번역, 어느 LLM이 잘할까? 다섯 가지 LLM 사용 결과와 정성 분석 설 연휴를 강타한 중국 스타트업 '딥시크'의 파장이 만만치 않습니다. 가성비(가격 대비 성능)를 앞세운 딥시크의 생성 AI 모델이 오픈 AI의 GPT에 필적한다는 평가가 나오면서입니다. 그래서 얼마 전 있었던 트럼프 취임사(Inagural address)를 번역해봤습니다. 정답은 조선일보 의 번역문을 기준으로 했습니다. 사람이 번역한 것입니다. 하나의 번역을 하는 시스템 프롬프트를 만들어 다섯 개의 LLM을 사용해 결과를 비교했습니다. 테스트환경 !테스트베드에서 그림과 같이 테스트했습니다. System Prompt User message 에 번역 할 텍스트를 넣었습니다. Model configuration: Temp: 0.56 Top_P: 1.0

EBS 특집 강연 멋진 신세계 AI : 질문하는 인간이 진화한다 2025년 EBS 특집 강연 멋진 신세계 AI의 2부 두 번째 강연 파트를 맡았습니다. "프롬프트, 질문의 기술"이 주제입니다. 올해는 작년보다 AI 활용이 더욱 커지며, 협업 도구로 자리 잡을 전망입니다. 이때, 명확한 의사 소통과 목적 설정이 필수입니다. 질문(=프롬프트)을 어떻게 하느냐에 따라 출력물의 질을 좌우하게 됩니다. 다니엘 카너먼의 책 <Thinking, Fast, and Slow> 중에서 '빠른 사고'와 '느린 사고'의 특징을 잘 보여주는 한 구절입니다. ✏️ 인간의 사고는 빠르고 직관적인 시스템 1과, 느리고 논리적인 시스템 2로 이루어져 있다. 우리는 대부분의 일상에서 시스템 1을 따라 직관적으로 판단하지만, 복잡하고 중요한 문제일수록 시스템 2가 주도적으로 사고해야 제대로 된 결정을 내릴 수 있다. ✅ LLM의 '빠른 사고'와 '느린 사고' LLM은 빠른 사고에 탁월합니다. 풍부한 데이터를 토대로 직관적이고 신속하게 답변을 생성합니다. 하지만, 복잡한 맥락을 다루거나 추론이 필요한 도메인에서는 느린 사고를 의도적으로 요구하면 답변의 품질이 크게 달라집니다. ✅ AI에게 '느린 사고' 유도하기 단계별 사고 (Chain-of-thought) 가장 친숙한 방법이 생각의 사슬기법입니다. 문제를 해결하기 위해 단계별로 언어 모델에게 사고하게 하는 것이죠. 결과만 요청하지 않고 '왜'와 '어떻게'를 적재 적소에 요구하는 방법도 있습니다. 이전 글에서는 인간의 사고 과정을 반영한 여러 프롬프팅 방법도 소개드렸는데요. 그것들이 느린 사고에 해당합니다.

생성형 AI 와 LLMs 그리고 인간의 언어 언어 훼손을 최소화하는 프롬프트 엔지니어링 "정확"과 "적확"은 다릅니다. 둘다 맞음을 의미하지만 사용되는 맥락과 뉘앙스 차이가 있습니다. 프롬프트로 작업을 한창하는데 LLM은 정확과 적확을 정확으로 치환합니다. 그러느라 애를 먹는 일이 많습니다. LLMs와 대화 혹은 작업하다보면 생성형 AI만의 표현과 어휘에 무뎌지게 됩니다. AI가 만들어내는 표현들이 생경하다보다 단어가 가진 의미가 훼손 됐다는 느낌이죠. 사람의 언어미묘한 '여운'을 느낄 수 있지만, AI의 단어에는 감각이 빠져있다 생각합니다. 전통적으로 언어는 인간이 긴 시간 동안 축적해 온 문화적, 사회적 맥락을 바탕으로 자연스럽게 발전해 왔습니다. 그런데 AI가 방대한 텍스트를 빠른 속도로 학습하고 생성하다 보니, 맥락을 제대로 반영하지 못하거나(‘기계 학습적 도출’), 아예 전에 없던 새로운 단어가 갑작스레 생겨나는 식의 변형이 일어나고 있습니다. 물론 언어는 언제나 변화해 왔습니다. 다만 오늘날 생성형 AI가 만들어내는 단어나 표현들은 인간의 사고방식에 직접 영향을 주고, 더 나아가 언어의 의미 영역에 새로운 “변형”을 일으킬 수 있다는 점이 중요합니다. 특히 다음 세 가지 측면에서 주의가 필요합니다. ✔️언어 구조와 의미 변화 ✔️언어 감각 상실 ✔️언어 다양성 감소 저만 해도 AI가 생성한 표현들을 ‘검증 없이’ 그대로 받아들이게 됩니다. 긴 문장을 쓰거나 의견을 정리할 때 ChatGPT나 클로드를 사용하는 것이 익숙해지다 보니, 오히려 인간이 새로운 표현을 직접 만들고 창의성을 발휘하는 능력이 줄어들지 않을까 하는 우려도 생깁니다. 결국 이러한 시대일수록, AI를 사용하는 우리 스스로가 능동적으로 언어와 문화적 다양성을 지켜나가는 노력이 중요해집니다. 이에 따라 프롬프트와 프롬프트 엔지니어링으로 보완하기 위한 연구와 시도가 활발히 이루어지고 있습니다. 대표적인 연구 논문은 "프롬프트 프로그래밍을"을 제안한 "Prompt Programming for Large Language Models: Beyond the Few-shot Paradigm"과 출력 언어 품질을 개선하는 방법을 제안한 "The Art of Prompting: Techniques and Applications of Prompt Engineering" 입니다.

Thinking LLMs: 모델을 생각하게 하는 프롬프팅 생성형 AI를 개선하기 위한 새로운 접근법을 찾으려는 시도는 추론 모델에 대한 관심을 불러일으켰습니다. 기존의 Brute Force, 모델을 단순히 크게 확장하는 전략은 이전처럼 효과를 발휘하지 못합니다. 언어 모델이 잘하지 못하는 것은 답하기 전에 생각하는 능력입니다. 이러한 한계를 극복하기 위해 모델을 사고하게 하는 프롬프팅 & 프롬프트 엔지니어링도 활발히 연구가 이루어지고 있습니다. 사람처럼 사고하게 하면 언어모델이 단순 지시문을 따르는 수준을 넘어, 더 유연하고 정확한 추록을 하게 됩니다. 사람이 문제를 풀 때 단계를 나누고 논리를 세우는 것처럼, 언어 모델 역시 이런 방식을 적용하면, 더 나은 결과를 얻을 수 있는 거죠. 최근에 발표된 o3 모델은 응답시간도 조절할 수 있다고 하죠. 최종 답변을 하기 전에 "생각"을 생성하게 하면 추론 성능이 좋아지기 때문입니다. 사고와 관련된 프롬프팅/엔지니어링 논문을 '모델의 사고'라는 테마로 엮었습니다. 함께 읽어보시면 좋을듯하여 논문의 레퍼런스도 첨부합니다. 요약하면 다음과 같습니다. ✅ 모델의 사고를 위한 프롬프팅 방법 Chain of Thought(CoT) : 논리적인 연결을 따라 생각하기. Zero-shot CoT: 단계를 나누지 않고 한 번에 답을 구하는 방식. Contrastive CoT: 대조를 통해 상황을 비교하며 분석. Analogical Prompting : 유사한 사례를 바탕으로 답을 도출. Step-Back Prompting: 한 발 물러서서 다시 문제를 바라보기. Thread of Thought: 필요한 정보만 선별해서 요약해서 생각하기. 생성형 AI 의 발전은 인간의 사고방식과 닮아가는 과정일지도 모릅니다.

Openai o1 과 프롬프트 Openai o1 은, AI Mathematics Evaluation(AIME) 수학적 문제 해결 능력 평가나, GPQA(General Purpose Question Answering) 다양한 종류의 질문에 대해서 얼마나 잘 대답하는지의 평가 지표에서 결과가 특히 뛰어납니다. 하지만, 결과가 뛰어나다고 해서, 반드시 end user 가 체감할 수 있는 무언가로 이어지진 않습니다. 반드시, 모델의 실용적인 접목 측면에서도 바로 적용가능한 것으로 이어지진 않습니다. 프롬프트를 꾸준히 들여다보고 써오고 있지만 LLM이 빠르게 발전할 때마다, 더욱 어려움을 느낍니다. 프롬프트 엔지니어의 일이란, 각 모델이 어떤 프롬프롬트의 응답을 잘 수행하고, 잘 못하는지를 판단하는 일입니다. GPT-4o는 실패했지만, o1에서만 잘 작동하는 프롬프트를 발견하는 것은 쉽지 않은 일입니다. GPT 3.5-turbo와 GPT-4의 사용에서 확연한 유의미한 차이를 느끼는 것처럼요. o1 이 현실 적용 가능한 과제를 해결하게 하기 위해서는, 더 어렵고 더 마법같은 프롬프트를 찾아야합니다. 또 다른 o1의 능력은 추론(Reasoning)입니다. AI 모델이 인간의 언어를 사용하여 사고 과정을 "나열"하는 것을 보고 있자니 놀랍습니다. 복잡한 문제를 몇 단계로 나누어서, 실수가 있으면 실수를 인식하고 수정하고, 다양한 접근 방식을 시도합니다. 사람의 사고 과정과 유사한데요. 그렇다면, 프롬프트 역시 역으로 인지과정을 거꾸로 밟아가며 세밀하고 정교하게 제작해야 할 필요가 있을 것 같습니다. 현재의 프롬프트 "과업"은 또 다른 "과업"이 되겠습니다. Evals https://openai.com/index/openai-o1-mini-advancing-cost-efficient-reasoning/ #Oepnaio1 #prompt #promptengineering

프롬프트 엔지니어링의 종말과 o1의 역학 프롬프트 엔지니어링 분야에 종사한다면 "프롬프트 엔지니어는 사라질 직업이다." "프롬프트 엔지니어링은 LLM이 대신 해줄거라 필요 없어질거다" 라는 말을 종종 듣죠. 지난 몇 년 동안 LLM의 성능을 극대화하기 위해 프롬프트를 미세 조정하고, 생성형 AI 서비스를 만들기 위해 프롬프트의 중요성이 강조되었습니다. 프롬프트 엔지니어링은 여러 언어 모델의 복잡성을 유용향 형태로 쉽게 다룰 수 있게 해주니까요. 하지만 o1 이 프롬프트 엔지니어링의 역학을 바꿨습니다. o1 만큼은 정교한 프롬프트 설계가 필요하지 않습니다. OpenAI의 o1 프롬프트 가이드를 보면 다음과 같습니다. ☑ 팁 1. 프롬프트를 간결하고 명확하게 사용할 것 ☑ 팁 2. 언어모델에게 자체적인 판단을 내릴 수 있는 여유를 줄 것 ☑ 팁 3. Chain-of-thought prompts 를 피할 것, think step-by-step 이나 explain your reasoning 불필요. 정교한 프롬프트가 오히려 모델의 추론 성능을 저해한다니, 기존의 프롬프트 엔지니어링을 보기 좋게 뒤집었습니다. GPT-4 같은 모델은 섬세하게 작업할 수록 결과물을 고도화 할 수 있었는데요. o1 은 테스트해보니, 밀도높은 프롬프트를 거부하는 반응을 보입니다. 그렇다고 해서, '프롬프트 엔지니어'는 사라질, '프롬프트 엔지니어링은 필요없는' 을 의미하는 것은 아닙니다. 단지 역할이 바뀐 것 뿐입니다. o1 시대 (편의상) 에는 프롬프트 엔지니어들인 고밀도의, 광범위한 세부사항에 중점을 둔 프롬프트를 제작하는 대신, 여러 산업의 문제를 "우아하게", "구조화"하여 푸는데 집중할 것 같습니다. o1의 메커니즘에도 여전히 중요한 것은 "우아한 프롬프트"와 "프롬프트 구조화" 입니다. 프롬프트 엔지니어링 수업에서 여러 방법들을 소개했는데요. 앞으로 o1 모델을 활용하는 더 우아한, 더 구조화를 위한 delimeters 소개가 이어질 것 같습니다. 그래서, AI가 추론 능력을 발휘 할 수 있는 공간과 최적화된 프롬프트의 환경을 디자인해야 하지 않을까 해요. AI에게 공간을 깔끔하게 내어주기 위해서요. 우아한 백조도 수면 아래서는 부단히 헤엄칩니다. 오늘의 o1 의 메커니즘은 숱한 정교한 프롬프트 엔지니어링의 시도로 이루어 낸 결과입니다. OpenAI의 o1은 가까운 미래, 아니 내일의 한 glimpse 입니다. 이 모델과 공존하기 위해서라도, 실용적이고 신뢰할 수 있는 AI의 결과물을 얻기위해 바지런히 프롬프트 엔지니어의 역할을 다해야 할 것 같습니다. #promptengineering #prompt #o1model #llm #adviceonprompting

프롬프트 엔지니어에 대한 고찰 프롬프트 엔지니어링이 단순 프롬프트를 잘 쓰는 것이 아닌, 전문적인 역량과 스킬이 필요한 이유가 잘 설명된 글입니다. 이 글에 대한 네 가지 reflection 을 해봤습니다. 1️⃣ 프롬프트와 프롬프트 엔지니어링에 대한 정의 시중에 많은 정의가 있지만 여전히 혼재되어 있어 재고(Revisiting)가 필요하다고 생각합니다.LLM의 아키텍처 개념을 사용하여 설명하면 어느 의미에서 프롬프트와, 프롬프트 엔지니어링인지 정확해지는 것 같습니다. 2️⃣ 프롬프트 엔지니어는? 생성형 AI 기업의 프롬프트 엔지니어는 LLM의 최종 출력층에서 "프롬프트 최적화를 하는 사람" 입니다. LLM <-> End user 사이에 위치하여 모델의 출력을 조정하고, 고도화하는 작업을 합니다. 프롬프트 엔지니어의 포지션은 최종 출력층이지만, 그 이전 층의 트랜스포머 아키텍처, 구송 요소들의 작동 원리를 알아야 프롬프트 최적화를 할 수 있습니다. 때문에, 단순히 ChatGPT의 답변을 잘 받았다고 혹은 문장을 잘 썼다고 프롬프트 엔지니어라 할 수 없을 것 같습니다. 3️⃣ Q(Query), K(Key), V (Value)가중치 행렬 활용 = 단어의 빈도수 제가 프롬프팅을 할 때 Q, K, V 값을 활용할 수 있도록 google ngram을 사용합니다. ngram 에 A단어/B단어의 빈도수를 비교하여, 가장 많이 쓰이는 단어를 프롬프트로 작성합니다. 예를들어, generate 보다는 develop 이 현대 영어(1980-현재)에서 더 빈도수가 큰 단어입니다. develop을 썼을 때, 원하는 결과를 쉽게 얻을 수 있었어요. LLM이 학습한 데이터 내 단어의 빈도수가 많을 수록, 언어의 semantic, syntax 의 관계가 더 커져, 원하는 결과물을 이끌어 낼 수 있었기 때문입니다. Attention 가중치가 올라갔다고 판단할 수 있을까요? 4️⃣ Q, K, V 가 무효할 때 = 언어의 Pragmatics 가 커질 때 Tokenizer 를 통해, 단어를 쪼개고 의미를 나누고, 문법의 패턴을 익힌다 하더라도 Pragmatics은 LLM이 하지 못하는 영역입니다. 그래서 엉뚱한 소리를 하거나, 이상한 답변을 해요. 특히 한국어는 더 그렇습니다. 한국어는 "고맥락"의 언어입니다. 문장이 발화된 상황에 의존하여, 발화 된 뜻을 상황속에서만 파악할 수 있습니다. 예를들어, 한국어에서 "괜찮아"가 맥락 의존적인 표현인데요. "커피마실래?" "괜찮아" 마시겠다는 건지, 안 마시겠다는 건지는 발화의 의도를 발화 상황에서 파악해야 합니다. 따라서, 이런 task 를 수행하는 기능 구현을 위한 프롬프트를 제작할 때는 "엔지니어링"을 해야 합니다. shot 으로 LLM에게 정보를 주거나, turn을 활용하여 role-play demonstration 을 하기도 해요. 결론: 요즘 한국어를 분석하면, 화용이 더 강해집니다. 언어의 형태나 의미보다는 기능이 더 중요해지는 거죠. meme이나, 주어를 생략하고 말하거나, 줄임말을 쓰는 것이 증거예요. 한국어의 화용을 LLM이 잘 이해할 수 있도록하는 프롬프트 엔지니어링이 필요할 것 같습니다.