언어 모델의 Thinking Time 과 Slow Thinking Prompt 'think harder' 프롬프트는 모델의 사고 시간을 늘려줍니다. 같은 질문을 던져도, 'think harder'를 사용한 모델은 5분 43초가 걸린 반면, 사용하지 않은 모델은 1분 8초 만에 답변을 내놓았습니다. (이미지 참고) 프롬프트는 단어 하나로 모델의 답변에 큰 차이를 만들어냅니다. ✅ Thinking Time의 개념 Thinking Time(생각 시간) 개념이 점점 더 중요해지고 있습니다. 모델이 출력을 내기 전에 내부적으로 수행하는 일련의 처리 단계를 의미합니다. 입력된 프롬프트 해석 내부 reasoning chain(추론 과정) 생성 중간 계산 수행 후보 답안 평가 및 선택 모델이 최종 답변을 내기까지의 숨은 연산 과정 전체가 Thinking Time에 해당합니다. ✅ Thinking Time과 프롬프트 엔지니어링 Thinking Time은 단순히 모델의 연산 효율 문제를 넘어서 프롬프트 설계 방식에 따라 크게 달라집니다. 이유는 두 가지입니다. 1️⃣ 복잡한 문제 해결 시 효과 단순히 "답만 내라"는 지시보다, 중간 추론 과정을 유도하는 프롬프트(Chain-of-Thought, CoT)를 사용하면 정답률이 높아집니다. 2️⃣ 모델의 불확실성 해소

AI Agent Tool 이름의 중요성: 왜 중요할까? Prefix vs. Suffix 네이밍 방식의 핵심 AI 에이전트를 위한 프롬프트 엔지니어링을 하다보면 수백 개의 툴과 MCP 서버관련 작업을 합니다. 프롬프트는 단순 지시문이 아닌, 에이전트를 어떻게 행동하게 할지를 규정하는 역할을 합니다. ✅ 툴 네이밍이 중요한 이유 프롬프트는 다음과 같은 판단의 기준이 됩니다: 툴을 어떤 맥락에서 사용할지 우선순위를 어떻게 둘지 실패 시 어떻게 복구할지 비슷한 기능을 가진 툴이 섞여 있으면, 에이전트의 툴 콜링 정확도가 떨어집니다. 이때 중요한 것이 바로 네임스페이싱(Namespacing) 입니다. LLM은 툴의 이름을 읽고 그 의미를 해석하기 때문에, 네이밍은 모델의 이해 정확도와 직결됩니다. ✅ Naming을 잘못했을 때 생기는 문제 엉뚱한 툴 호출 맞는 툴에 잘못된 파라미터를 넣음 필요한 툴을 missing 함 툴 응답을 잘못 처리함 👉 효과적인 네이밍 원칙

LLM 의 할루시네이션과 프롬프트: 할루시네이션이 발생하는 이유 OpenAI 연구를 중점으로 살펴본 '할루시네이션' LLM의 할루시네이션 발생원인과 프롬프트 작성법 OpenAI 연구를 중점으로 살펴본 '할루시네이션' 모델의 할루시네이션을 완화하기 위한 프롬프트 작성법음로 모르는 사실에 대해 "I don't know" 라고 프롬프트에 쓰는 것이 보편적입니다. 제가 사용하는 방식은 조금 다릅니다. 한 정보나 이슈에 대해 앎고 있음에 대한 epistemic gradient (*지식에 대한 확신 정도) [+/-] 를 활용하여 "어느 정도를 모르는지" tilting 하는 방식입니다. 100% 제어는 불가능하지만, 답변의 정확성을 높이는 데 효과적입니다. 언어 모델의 할루시네이션은 다양한 원인으로 발생합니다. 선행 연구는 할루시네이션의 원인을 모델의 과도한 확신, 디코딩의 무작위성, 스노우볼링 효과, 긴 꼬리 학습 샘플, 오도된 정렬 학습, 노출 편향 등으로 분석했습니다. 최근 OpenAI 는 이러한 현상을 구조적으로 분석한 논문을 발표했습니다. ✅ 할루시네이션 정의와 연구 결론 할루시네이션은 부정확한 정보를 사실처럼 생성하는 현상입니다. OpenAI 연구의 핵심은, 이것이 단순한 오류가 아니라 학습 및 평가 체계에서 발생하는 통계적 특성이라는 점을 강조합니다. 다시 말해, 언어 모델이 오류를 만드는 것은 ‘이상’이 아니라 자연스러운 결과라는 것입니다. ✅ OpenAI 가 밝힌 할루시네이션의 원인 1️⃣ 통계적 오류로서의 할루시네이션 언어 모델은 “추측하도록 보상받기” 때문에 불확실한 상황에서도 가장 가능성이 높은 답을 생성합니다. 이 과정에서 과도한 확신이 오류로 이어집니다. 2️⃣ 평가 체계의 구조적 문제 모델 학습·평가 방식은 정답률을 높이는 방향으로 설계되어 있습니다. 불확실할 때도 추측하는 편이 점수를 잘 받기 때문에, 모델은 자연스럽게 ‘추측을 지속’하게 됩니다. 3️⃣ 예측 문제의 불가피성 언어 모델은 확률적 생성 모델입니다. 따라서 불확실성을 표현하는 대신 그럴듯한 답변을 내놓는 것이 기본 동작이며, 할루시네이션은 불가피한 부산물로 나타납니다. ✅ 연구 기반 생각해 볼 점들 OpenAI 연구의 Discussions 를 읽고 생각해보면 좋은 점을 정리해봤습니다.

"말고"가 답변을 망치는 이유: "부정어"와 "프롬프트" 부정어를 처리하는 프롬프트 작성법 최근 티타임즈TV 컨텐츠를 통해 GPT-5 와 프롬프트를 주제로 실험한 내용을 소개했습니다. LLM은 한국어/영어의 부정(negation)과 여러 지시문에 취약합니다. "A 말고 B" 와 같은 한국어 부정 대조 지시에서 특히 답변이 망가집니다. 이미지/멀티모에서 부정어 처리를 잘 못한다는 내용의 피드를 작성한 적이 있습니다.텍스트 생성에 있어서도 LLM이 부정 표지 (예: not, -지 말고) 의 의미를 안정적으로 반영하지 못합니다. GPT-5 도 그렇습니다. "요약하지 하지 말고 인용구만 뽑아줘" 라고 했을 때 답변이 망가집니다. LLM의 크기가 커지면 negation 처리능력도 향상된다고는 하나, 여전히 해결되지 않은 문제입니다. ✅ LLM 은 왜 '부정(negation)'에 약한가? LLM은 기본적으로 다음 토큰 예측 확률을 최대화하도록 학습됩니다. 입력에 “하지 말고 / ~는 제외하고”처럼 원치 않는 단어가 등장하면, 모델 내부 표현은 그 단어를 억제하기보다 연상시키는 자극으로 처리하는 경우가 잦습니다. 고전 연구인 ✔️ Kassner & Schütze(2019/2020)는 PLM이 “Birds cannot [MASK]”와 “Birds can [MASK]”를 잘 구분하지 못하는 negation blindness를 보고했습니다. ✔️ 또한 다국어 NLI 설정에서 부정은 여전히 난제로 남아 있고, 모델 크기 증가가 부정 취약성을 줄이지만 완전히 해결하진 못한다는 최근 결과도 있습니다(Vrabcová et al., 2025). 이미지 내용: 모델들은 부정(negation)이 포함된 문장을 이해할 때 정확도가 크게 떨어지며, 작은 모델일수록 성능 저하가 심각함. 하지만 큰 모델들은 상대적으로 강건하게 부정을 처리하며 언어와 데이터셋에 따라 차이를 보임. ✅ 한국어 "말고"의 구조적 특징 "말고"는 한 문장 안에 두 지시를 묶습니다. 동사 연결: “A-하지 말고 B-해” → 금지(¬A) + 대체행위(B) 명사구 대조: “A-말고 B” → 예외/배제(A 제외) + 선택(B) 한 줄에 배제와 선택이라는 상호 의존 제약이 동시에 들어갑니다. 지시 개수가 늘수록 전체 준수율이 급락하는 “curse of instructions”가 관찰되는데, 최근 공개 심사 논문에서도 제약 수↑ → 전부를 만족할 확률↓ 패턴이 보고됩니다. “말고”는 이 현상을 언어 차원에서 증폭시키는 셈입니다.

GPT-5 새로운 파라미터: Verbosity 와 System Prompt 출력물의 길이와 상세 수준을 조절하는 방법 프롬프트 제작 단계에서 으레 하는 일은 출력물의 길이와 상세 수준을 조절하는 것입니다. 기존에는 시스템 프롬프트에 단순히 "길게", "간결하게" 등의 지시를 합니다. 하지만 원하는 길이와 밀도를 정확히 맞추기는 쉽지 않습니다. 불필요하게 장황하거나 , 핵심이 없거나, 지정한 길이에 맞지 않는 결과가 나오는 경우가 많습니다. ✅ 세 가지 방법 저는 다음의 세 가지 방법으로 출력 길이와 밀도를 조정합니다. 1️⃣ 하위 구조 지정: 출력 내용을 세부 항목으로 나누어 각 항목을 프롬프트에 명시 예시: 하위 구조 1, 하위 구조 2, 하위구조 3 2️⃣ 문단 수 지정: 원하는 분량을 문단 단위로 구체적으로 지시 3️⃣ 내용 확장 방식 명시: 어떤 부분을 어떻게 상세히 해야 하는지 'how-to ' 설명 또 때로는 'in sequence', 'in detail', 'thorough' 같은 단어를 사용하여 길이를 늘릴 수 있습니다. ✅ GPT-5의 새로운 기능: Verbosity 최근 GPT-5에는 출력물의 길이와 밀도를 조정하는 새로운 파라미터 기능이 생겼습니다. 사용자나 개발자가 API 호출 시 응답의 길이와 세부정도를 직접 제어할 수 있습니다.

LLM 코드 생성 시 '프롬프트 변동성' : 오타와 문장 재구성 >> 프롬프트 엔지니어링이 지금 중요한 까닭 최근 많은 개발자와 비개발자들이 코드 생성용 LLM을 적극 활용하고 있습니다. 자연어로 작성한 간단한 요청만으로도 고품질의 코드를 빠르게 생성할 수 있는 시대입니다. 그러나, 쉽게 간과하고 있는 부분이 있습니다. 프롬프트는 '변화'에 취약합니다. 그리고 두 가지 질문에 의심해야합니다. "과연 LLM이 자연어를 올바르게 이해하고 있는가? " "같은 기능을 요청했을 때, 프롬프트가 달라지면 결과물이 달라지지 않을까?" 🔵 영국 케임브리지 대학 연구팀의 최근 논문 영국 케임브리지 대학 연구팀은 2025년 6월, 다음 논문을 발표했습니다. ‘Prompt Variability Effects on LLM Code Generation’ 연구는 LLM기반 코드 생성 과정에서 프롬프트의 미묘한 변화가 결과물에 어떤 영향을 미치는지 체계적으로 분석했습니다. 🔵 프롬프트 변화가 결과에 미치는 영향 연구팀은 다양한 실험을 통해 LLM의 코드 생성 결과가 입력 프롬프트의 변화에 매우 민감하다는 사실을 밝혔습니다. 타이포(오타), 동의어, 문장 재구성(Paraphrasing)과 같은 변화만으로도 LLM이 전혀 다른 코드를 생성할 수 있다는 것이죠.

RAG 마지막 단계, 시스템 프롬프트 작성팁 >> 도서 리뷰 'LLM 엔지니어링' : 기본이 중요한 이유 한빛 미디어의 신간 <LLM 엔지니어링> (원제: LLM Engineer's Handbook) 도서의 추천사를 작성했습니다. 책의 역자 Woocheol Cho 차장님과는 작년 포스코 이앤씨의 강연으로 인연을 맺었는데요, 감사하게도 장님께서 책을 선물로 보내주셨어요. 책은 문자그대로 'Handbook' 입니다. 교과서처럼 정독하며, RAG 시스템과 에이전트의 기본을 사전처럼 찾아보고 있습니다. ✅ 프롬프트 엔지니어링 '기본'에 충실해야 하는 이유 프롬프트만 무작정 수정하다 보면, 근본 개념을 놓쳐 해결 불가능한 과제에 부딪히기 쉽죠. 잘못 알고 있었던 개념이나 놓친 원리를 바로 잡을 때, 문제를 해결할 수 있습니다. ✅ 가장 도움을 받 은 부분은 'RAG 기본' 챕터 RAG에서 프롬프트 엔지니어링은, 최종적인 품질을 좌우합니다.

부정어를 잘 처리하도록 하는 프롬프팅 방법 부정어를 인지하지 못하는 VLM(Vision Language Models) VLM을 사용하여 프롬프트 엔지니어링을 하다보면 '부정어' 보다는 '긍정어'를 사용할 때 결과가 훨씬 좋음을 체감하고 경험할 수 있습니다. '부정어'를 인식을 못하여 결과에 오류를 낼 때도 허다합니다. 관련하여, 최근 MIT 연구진의 부정어 관련 연구가 있어 정리해봤습니다. ✅ MIT 연구진이 실험한 'VLM의 부정어 이해 한계" 최근 MIT 연구진은 'VLM의 부정어 이해에' 한계가 있다고 실험 결과를 발표했습니다. VLM 이 '가 아니다', '하지 않는다' 와 같은 부정어 (negation)을 제대로 인식하지 못한다는 결론입니다. 이 연구는 특히 의료 진단, 제품 결함 감지 등 고위험 분야에서 VLM 을활용할 때, 부정어를 인식하지 못해 심각한 오류를 초래할 수 있음을 경고합니다. ✅ 연구의 핵심 요약 ✔️ 문제: 방사선 전문의가 흉부 엑스레이 판독시 "조직 부종은 있지만 심장 비대는 없다"라고 판단합니다. VLM을 활용해 비슷한 케이스 보고서를 찾으려 할 때, VLM이 부정어를 놓친다면 "심장 비대가 있다"는 보고서를 잘못 검색해 전혀 다른 진단 방향으로 흐릅니다. ✔️ 실험 결과: 부정어가 포함된 프롬프트에서 평균 이미지 검색 25% 감소 이미지 검색 25% 감소 VLM은 주로 “이미지 속 존재하는 객체”만을 기준으로 판단해, “부재(absence)”를 표현하는 부정어를 무시하는 경향(=긍정 편향, affirmation bias)이 강함

프롬프트를 조금 더 잘 쓰는 방법 '현재 시제만 쓰고 있었다면...' "좋은 프롬프트는" 생성형 AI 혹은 LLM을 이용하며 원하는 결과를 얻게 하는 프롬프트입니다. 실증적 연구로 입증된 프롬프트 엔지니어링 기법이 많지만, 언어 property 를 이용한 방법을 소개하겠습니다. 👉 이번 글은 (Leidinger et al., 2023) 연구 내용과 프롬프트 엔지니어링 개인 경험을 바탕으로 작성했습니다. 결론: ✅ 프롬프트의 언어 구성을 어떻게 하느냐에 따라 결과가 달라진다. 영어로 프롬프트를 쓴다면, 다음과 같은 언어적 속성을 다양하게 사용할 수 있습니다. 문법적 법(mood): 평서문, 의문문, 명령문 시제(tense): 과거, 현재, 미래 태(aspect): 능동태 vs 수동태 양상(modality): can, must, might 등 조동사 어휘 대체(synonymy): 동일 의미의 동의어 치환 🍓 프롬프트를 잘 쓰는 다섯 가지 방법 방법 1. 프롬프트의 문장을 '질문형' 으로 바꿔보자

챗GPT 4o 말투, 왜 이렇게 달라졌지? 아첨을 하지않는 프롬프트 작성법 챗GPT 4o의 말투가 사용자 사이에서 뜨거운 화제였습니다. 예전에는 하지 않던 말투들을 사용하기 때문인데요. 다음의 네 가지로 말투의 특징을 꼽을 수 있습니다. ✅ 지나친 캐쥬얼함 (Yo, LOL, Yo Brooo..) 비속어나 슬랭 사용 ✅유치해진 말투로 인한 Dumber 챗GPT, ✅ 과도한 칭찬과 동조의 긍정 편향 (sycophancy streak) ✅ 사용자 지시를 무시하고 쓸데없는 말이 길다 ❓ 왜 이런 변화가 있었을까? OpenAI 공식 문서는 GPT-4o 업데이트를 소개하며 "대화 흐름 개선과 사용자 경험 향상"을 주요 목표로 내세웠다 합니다. 사용자가 느끼는 대화의 부드러움과 몰입감 강화를 위해 말투와 감정에 친근함을 더했습니다. https://help.openai.com/en/articles/6825453-chatgpt-release-notes ❓ 어떻게 이런 아첨하는 모델을 만들었을까? 요즘의 LLM은 Question-Answering 패턴을 가르치는 Instruction Tuning 과정에서 사용자의 지시사항과 의견을 구분하지 못하고, 사용자 의견에 동조하는 경향성을 학습했습니다. 인간 선호도 기반 강화학습(RLHF)도 모델의 답변에 영향을 줬겠죠. 인간이 맞는 답보다는 듣고 싶어하는 말을 듣는 것을 선호한다는 것이에요. 그리고 시스템 프롬프트로 최종 답변을 조정했겠지요. (자세한 글은, 변형호 박사님의 글을 읽어보시면 도움이 될 거예요) → 꼭 읽어보세요!

[프롬프트 실험실] 공손한 언어 vs 무례한 언어 AI로부터 좋은 답변을 잘 받는 방법은? 프롬프트와 프롬프트 엔지니어링을 하다 보면 '카더라' 가 많습니다. 하지만 프롬프트는 '과학'이에요. 프롬프트 실험실이란 제목으로 카더라를 하나하나씩 팩트체킹하려고 합니다. 🍓 첫번째는 '공손한 언어'와 '프롬프트' 예요. 얼마 전, 이런 기사가 있었습니다. 샘 알트먼 "챗GPT"에 '감사합니다' 할 때마다 수천만 달러를 지출하고 있다. 공손한 프롬프트는 AI가 실제로 더 나은 응답을 하게, 사용 신뢰에 있어 매우 중요한 요소입니다. 🔥 기사: https://futurism.com/altman-please-thanks-chatgpt ✔️ 왜 그럴까요? 작년에 'LLM에게 공손해야 할까?' 라는 주제로 피드를 썼습니다. 글에서 말씀 드린 것처럼 '공손한 언어'는 LLM에게 더 좋은 답변을 하게 합니다.

한국어로 프롬프트를 작성하는 방법 한국어는 맥락에 크게 의존하는 ‘고맥락 언어’입니다. LLM에 그대로 입력하면 종종 의도가 왜곡되거나 핵심이 누락됩니다. 저는 영어로 프롬프트를 작성하지만, 한국어만 해야하는 모델을 사용할 때는 다음과 같은 방법을 사용합니다. 1️⃣ 형태소 단위로 “의미 덩어리” 고정하기 고유한 의미 덩어리를 명확히 구분해야, 모델이 어절 간 경계를 놓치지 않습니다. 한국어는 한 어절 안에 조사, 어미, 접두사 접미사등이 붙어 있을 수 있어요. LLM이 input의 경계를 구분하는 과정에서 잘못 분리하게 되면 의미를 왜곡하기도 합니다. 그 결과 할루시네이션이나, 잘못된 답변을 생성합니다. ✅ 의미 덩어리(semantic chunk)란? 문장을 이루는 최소 의미 단위, 핵심 명사, 동사, 형용사 같은 틀을 말해요. ✅ 왜 고정해야 할까? LLM은 입력 텍스트를 내부적으로 토큰(token) 단위로 분해한 뒤 확률적으로 처리합니다. 의미 덩어리를 띄어쓰기나 강조 표시(…, 《…》)하면, 모델이 그 단어 그룹을 하나의 토큰 묶음으로 인식할 가능성이 높아집니다. 🔥 프롬프트에 적용하는 방법 ✔️ 꼭 띄어쓰기 하기: 모든 조사, 어미 앞뒤로 띄어 쓰기 ✔️ 주격 조사(은/는, 이/가), 목적격 조사(을/를) 꼭 써주기 ✔️ 핵심 어간 강조: 중요한 키워드를 굵게 혹은 << >>로 감싸 의미 경계를 표시하기 ✔️ 토큰 분할 도구 활용: KoNLPy 같은 형태소 분석기로 사전 테스트해 보세요. 모델이 한국어 문장을 어떻게 분해하는지 확인 후 프롬프트 결과를 고도화하기도 해요. 2️⃣ 한국어 특화 어말어미·어투 제어 ✔️ 어말어미 일관성 유지하기 ✔️ 존댓말(–습니다) vs 반말(–해요) 중 하나 선택. Deferential form '-습니다'를 사용하면 openAI 모델은 답을 더 길고 상세하게 합니다. ⭕ 두 가지 방법의 프롬프트 기대 결과 모델이 핵심 정보(명사구·동사구 등 의미 단위)를 정확히 파악해, 출력의 일관성과 정확도를 크게 향상 시킬 수 있어요. 숫자·단위·고유명사처럼 분리 오류가 치명적인 부분에서 실수를 줄여 줍니다. 한국어로 프롬프트를 작성할 때는, 한국어의 고맥락적 특수성을 온전히 반영해야 결과가 개선되기 때문에, 섬세함을 기울여야 합니다.

>> '프롬프트' 와 '구분 기호' 기호만 잘 사용해도 답변의 품질이 달라진다. 프롬프트 작성에서 기호 사용은 중요합니다. 구조화 때문인데요. 구조가 명확해지면, 모델이 불필요한 중복 설명을 하거나 엉뚱한 부분을 답변하는 확률이 줄어듭니다. 사용자가 어떤 기대 형식을 가지고 있는지도 모델에게 분명하게 전달할 수 있어요. 보안 측면에서도, 사용자 입력을 구분자로 묶어 프롬프트 주입 공격을 예방하기도 합니다. 이런 기호를 구분자 (Delimiters) 라고 합니다. ✅ 구분자란? 프롬프트 내부에서 서로 다른 부분을 명확히 구별하기 위해 사용하는 특수 문자열이나 기호. """ (트리플 따옴표), ` (트리플 백틱), --- (트리플 대시), <...> (각종 꺾쇠 괄호 또는 XML 태그) 등. → 구분자 사용은 프롬프트 엔지니어링의 기본 기법입니다. OpenAI 와 Anthropic 등의 모델사에서는 프롬프트에 기호 사용을 권장합니다. ✅ 구분자 사용이 LLM 응답 품질에 미치는 영향과 관련 연구 최근 2-3년간 프롬프트 형식이 LLM에 미치는 연구들이 진행되고 있습니다. 소형언어 모델일 수록 프롬프트의 형식이 LLM에 성능에 미치는 영향이 큽니다. Sclar (2023): 의미는 동일하고 표현이 다른 프롬프트 성능 편차 심함 입증. Voronov (2024): 프롬프트 템플릿을 잘못 선택하면 가장 성능이 좋은 모델도 정답률이 떨어짐을 입증.

Multi-Persona Collaboration 프롬프트 엔지니어링과 '인간의 사고' 여러 전문가 호출한다는 의미 한 사람이 여러 역할을 맡아 토론하는 AI 프롬프트 기법이 있습니다. 멀티 전문가 역할 지정, 페르소나 부여하기 기법은 자주 쓰는 방법입니다. 이 기법에는 "인간의 사고 과정"이 고스란히 담겨 있습니다. Multi-Persona collaboration 기법의 정의와 기능을 정리해봤습니다. ✅ 연구 제목 작년 3월 Synthminds 팀은 일리노이 대학교(University of Illinois)에서 진행된 아주 흥미로운 연구를 소개했습니다. 제목은 “Unleashing Cognitive Synergy In Large Language Models: A Task-Solving Agent Through Multi-Persona Self-Collaboration”입니다. ✅ SPP(Solo Performance Prompting) 기법 LLM(Large Language Model) 내부에 여러 ‘가상의 전문가(페르소나)’를 호출해 스스로 협업하며 문제를 해결하도록 유도하는 프롬프팅 방법. 예를 들어, 새로운 제품 아이디어를 구상한다고 하면 마케팅 전문가 페르소나는 시장 트렌드와 고객 니즈를 분석해주고, 엔지니어 페르소나는 기술적 타당성과 리소스를 검토합니다. 디자이너 페르소나는 사용자 경험과 미적 요소를 제안합니다. 이렇게 ‘가상 전문가 팀’이 주고받는 대화를 통해, 혼자서는 떠올리기 힘든 솔루션이 탄생하죠. 이것이 SPP 입니다. 여러 전문가 역할을 설정해 대화를 진행하는 것은, 우리가 여러 사람과 토론하며 아이디어를 발전시키는 모습과 흡사합니다. 이는 AI가 단순히 ‘최적의 답변’만을 내놓는 것을 넘어, 과정 중심의 사고를 수행하도록 하는거죠. ✅ 인간의 사고와 닮은점 세 가지 ✔️ Distributed Cognition (분산인지) 실제로 여러 사람이 모여 서로 다른 아이디어와 지식을 결합하는 것처럼, 모델 내부에서 ‘가상 전문가’들이 정보를 주고받으며 공동 해결책 도출 ✔️ Group Creativity (집단 창의성) 마케팅 전문가, 엔지니어, 디자이너 등 다양한 관점을 합치면, 혼자서는 떠올리지 못할 새롭고 창의적인 결과물이 나올 수 있음 ✔️ Metacognition (메타인지) 러 페르소나가 서로의 논리를 비판적으로 검토하고, 결론 도출 과정에서 자기성찰 과정을 수행함으로써, 정확도와 일관성을 높임 인간의 사고 과정을 모사하는 SPP 기법은 AI를 단순 답변기에서 ‘협업 파트너’로 발전시킬 수 있는 방법입니다. 이 방식이 더 정교해진다면, 우리는 AI와 함께 새로운 아이디어를 탐색하고 실험하는 데 있어 다양한 경험을 할 수 있을거라 기대합니다. 그래서 요즘은 인간은 어떻게 사고하는가와 관련된 글을 많이 읽습니다. 그러다보면 프롬프트로 해결할 수 있는 저변이 넓어질 거라 생각합니다. 논문링크: https://arxiv.org/pdf/2307.05300 hashtag#promptengineer hashtag#promptengineering hashtag#prompting hashtag#multipersona hashtag#roleprompting hashtag#cognitiveandprompt hashtag#MultiPersonaCollaboration

Few-shot prompting 과 Few-shot learning 의 차이점 ChatGPT같은 모델에 프롬프트를 쓴다고 즉시 학습되진 않습니다. Few-shot prompt engineering 기법은 기본 테크닉 중 하나입니다. A라는 과제를 하기 위해서 두 개 이상의 예제를 사용해서 결과물을 도출하는 방법입니다. 수업을 하다보면 '퓨샷 프롬프팅'과 '퓨샷 러닝'을 동의어로 사용하는 것을 흔히 들을 수있습니다. ❓LLM 모델에게 질문만 해도 모델이 학습되나요? 프롬프트 관련 자주 묻는 질문 그리고 잘못 알고 있는 것 중 하나입니다. ✅ Few-shot Learning 머신러닝 모델이 훈련단계에서 적은 수의 데이터를 사용하여 학습하면, 이를 바탕으로 새로운 데이터를 처리할 수 있게 하는 방법입니다. 사람이 새로운 단어를 한 두 번 들으면 바로 의미를 이해하고 사용하는 것처럼, 모델은 몇 가지 예제만 보고 학습할 수 있는 방식이죠. ✅ Few-shot prompting 이미 훈련이 끝난 LLM (대규모 언어 모델)이 추론 과정에서 몇 가지 예제를 참고하여 질문 (프롬프트)에 대한 결과를 생성하게 하는 기법입니다. 모델 자체의 파라미터는 업데이트 되지 않고, 주어진 프롬프트 (질문과 예제 등) 으로만 작동합니다. 📚 두 가지 개념이 정리된 논문들 Few-Shot Prompting (Brown et al., 2020) is the paradigm, where the GenAI learns to complete a task with only a few examples(exemplars). Few-Shot Learning (FSL) (Fei-Fei et al., 2006; Wang et al., 2019) is often conflated with Few-Shot Prompting (Brown et al., 2020). It is important to note that FSL is a broader machine learning paradigm to adapt parameters with a few examples, while Few-Shot Prompting is specific to prompts in the GenAI settings and does not involve updatingmodel parameters. 👉 요약 프롬프트를 챗GPT 에 입력한다고 해서, LLM이 실시간으로 내부 매개변수(가중치)를 업데이트하며 재학습하는 것이 아닙니다. 다만, 나중에 모델 개발사가 사용자 데이터를 활용해 모델을 훈련하거나 개선할 수는 있겠어요. 👉 논문 링크

세밀한 요약을 위한 프롬프팅 LLM이 발산하며 요약을 잘하지만 세밀하지는 않습니다. 촘촘한 요약을 하다보면 가독성이 떨어지거나 가독성을 올리면 밀도가 떨어지는데요. 문제 해결을 위한 아이디어를 얻었던 논문 두 편을 소개합니다. 물론 논문이라고하여 모두 신뢰할 수는 없습니다. 문제 해결을 위한 아이디어정도를 프롬프트에 응용하는 편입니다. ☑ Elment-Aware Summary ☑ Chain-of-Density (CoD) Prompting === ☑ Elment-Aware Summary LLM의 요약 품질을 올리기 위한 프롬프트로 Chain-of-thought 을 적용한 Summary CoT를 제안합니다. 요약할 텍스트의 핵심 요소(인물, 날짜, 사건, 결과를 중심으로)를 반영한 프롬프트에서 요약의 일관성과 정확성을 올렸습니다. 포인트는 "Element" 을 프롬프트에 반영하는 것인데요 슬라이드에 상세를 정리했습니다. ☑ Chain-of-Density (CoD) Prompting 2023년 SalesForce AI, MIT et al 에서 요약의 정보 밀도 향상 프롬프트 연구 논문입니다. CoD Prompting 는 기존 요약의 entity 밀도를 단계적으로 높이는 방법입니다. 압축과 통합을 통해 내용 길이를 유지하는 것이 특징입니다.

>> ChatGPT로 번역의 품질을 높이기위한 프롬프팅 챗지피티(GPT 포함)으로 높은 품질의 번역을 하기는 참 어렵습니다. 크게 네 가지 이유입니다. 1️⃣ 영어와 다른 목표언어의 Grammar와 Sentence Structure 2️⃣ 영어와 다른 목표언어의 Culture References 3️⃣ 영어가 아닌 다른 언어의 Lack of Data 4️⃣ 특정 분야의 용어, Technical Terms 번역관련 프롬프트를 개발하다가, 참고할 만한 논문을 몇 개 읽었습니다. 영어-> 한국어(혹은 한국어 ->) 로 번역할 때, 다음의 방법으로 번역 품질을 개선할 수 있었습니다. 1️⃣ Few-shot in Context Learning 정답에 가까운 예시를 주는 방식입니다. 이 때 Fuzzy matches의 방식은 품질의 일관성과 정확도를 높여줍니다. Fuzzy matches 는 task 와 유사한 컨텍스트를 활용하는 방식입니다. 예제를 프롬프트에 사용할 때는 5개 미만으로 주어야 품질에 영향을 미치는 것을 경험하였습니다. 2️⃣ Task Information Prompting 해결해야 하는 과제에 중점을 둔 상세한 프롬프트 작성 방식입니다. 프롬프트의 구조화와 상세한 내용을 '과제' 중심으로 세분화하는 것입니다. 3️⃣ Domain Specific Prompting 특정 도메인에 적합한 프롬프트를 제공하여 번역 성능을 향상 시키는 방법입니다. 도메인에 해당하는 단어를 선별하여 context 를 추가합니다. 위의 내용을 슬라이드에 정리하여 이미지로 첨부했습니다. 논문의 핵심 내용만을 발췌했습니다.

Anthropic 의 Prompt workbook : Google Sheets Adds-on 과 프롬프트 Anatomy Google Sheets 에 Claude API를 호출해 셀에서 직접 prompt 의 결과물을 확인할 수 있는 Claude for Sheets : template workbook 을 사용해봤습니다. Google Sheets를 사용해서 프롬프트 평가, 테스트, DB관리와 버져닝, Token Tracking을 많이 하실텐데요. 저도 프롬프트 DB관리를 Google Sheets에 한 적이 있어서, Claude에서 제공한 template 을 보니 매우 흥미롭더라구요. 특히 실시간 데이터 분석이나 처리에서 이 sheets 을 활용하는 장점이 확실히 있을 것 같습니다. 오프라인 프롬프트 엔지니어링 수업 준비를 하면서, 다양한 유형의 프롬프트 제작 실습을 하고 포트폴리오를 만들기 위해 이상적인 Workbook의 유형을 고민하고 있는데, Anthropic 의 Prompt workbook에서 많은 아이디어를 얻었습니다. 저는 프롬프트는 네 가지 요소로 구분하고 있습니다. 해부를 하면서, 하나하나의 요소의 결합과 그의 결과물을 분석합니다. Prompt Anatomy 1️⃣ Type A: 명령문 (Instruction) 2️⃣ Type B: 맥락 (context) 3️⃣ Type C: 예시 (example) Delimiter ("" 나 <> </> ::, -- 등의 기호) 를 사용해 예시임을 LLM에게 explicit 하게 hinting 함을 선호하고 있습니다. 4️⃣ Type D: 외부 데이터 (Output source) Type D는 unstrcutred data (비정형 데이터)를 줄글 형태의 프롬프트와 어떻게 assemble 할 수 있는지 조립방법에 대한 연구를 많이 합니다. 레고 블럭처럼 조립하는 거죠. Blocking을 했을 때, 비정형 데이터와 기존 프롬프트 {{Text}} 간의 이질감이 가장 없다라 생각하고 있습니다. Prompt Workbook을 보며, 프롬프트 요소와 구조화, 이상적인 프롬프트 텍스트 포맷에 대한 아이디어를 더 상세하게 얻을 수 있었습니다. ✅ Prompt Workbook의 다양한 프롬프트 템플릿과 유용한 팁 1️⃣ 기본 프롬프트 테스트

공손한 언어와 프롬프트의 효과 프롬프트를 써오면서 AI에게 예의를 갖추는 것이 혹은 예의바른 문장을 사용하는 것이 가치가 있는 일이라고 말하고 싶습니다. 두 가지 이유인데요, 1️⃣ 공손한 표현 사용은 AI로 부터 더 좋은 결과물을 얻는다. 2️⃣ 공손한 표현은 AI 사용의 윤리적 담화를 형성한다. "AI는 감정이 없는데, 예의를 차리는 것이 효과가 있을까?" 라고 생각하는 분들도 있을거예요. 하지만 인간은 다른 사람과 감정적으로 연결하려하고, 예의를 갖추려 하기 때문에 생성형 AI를 사용하면서도 예의 바른 표현과 공손한 매너가 기본인 분들도 많죠. (세상에 100%는 없기 때문에, 다수라 저는 믿습니다) 이 글에서는, 공손한 표현의 프롬프팅 효과에 대해 다뤄보겠습니다. 프롬프트를 작성할 때 다음 세 가지 중 한 가지 표현을 사용할 거예요. (1) 중립적인 어조: 특별히 예의바르지도, 무례하지도 않은 "AI가 해야 할 일"을 명령하는 중립적인 프롬프트 (2) 예의바른 표현: 공손성이 높은 표현이 있는 프롬프트 (3) 무례한 표현: 불공손성(impoliteness)을 표현한 프롬프트 생성형 AI 이용자의 프롬프트 언어 분석을 하고 있습니다. 그 중 "공손성과 불공손성"에 있어서 제가 목격한 것은 대다수가 자연스레 친절하고 공손한 어조로 프롬프트를 작성한다는 점입니다. "안녕? ~~~좀 해줄 수 있어?" "고마워~ 너 정말 대단하다" "안녕하세요 저는 이런 것들이 필요한데, ~ 해주시겠어요?"

Biomimicry 으로부터의 프롬프트 엔지니어링: 프롬프트 구조화 프롬프트 엔지니어로 일을 할 때 두 가지 역량이 중요하다 생각해요. 1️⃣ LLM의 가능성 탐구를 위한 독창성 2️⃣ LLM의 한계를 인지한 과학적 접근 다양한 학문 분야에서 영감을 얻을 수 있습니다. 그 중 하나는 Biomimicry 입니다. Biomimicry 는 '생체 모방' 입니다. 자연으로부터 배워 문제를 해결하는 방법이에요. 자연과 생물들이 백만 년 동안 진화하면서 발전시킨 해결책들을 연구하고, 이를 인간의 문제 해결에 적용하는 것입니다. 이 열매 아세요? 도꼬마리 열매입니다. 아마도 이 열매가 옷이나 몸에 붙어서 고생한 적이 있을 거예요. 열매 끝을 보면, 갈고리 처럼 생겼죠. 자세히 확대한 사진을 보면 갈고리 모양이 잘 보여요. 그리고 이 열매에서 영감받아 오늘의 "벨크로"가 탄생하게 됩니다. 출처: Biomimicry, An Approach Towards Future of Design and Sustainability 💡 벨크로 발명 계기 전기 공학자이자 발명다 Gorge De Mestral 은 산책 후 강아지 털에 붙은 도꼬마리를 떼어냈어요 호기심이 가득했던 그는 현미경으로 열매를 관찰했어요. 확대해 보니, 갈고리 끝에 붙는 메커니즘을 발견하고 1951년 "벨크로'를 특허 출원했습니다.