AI에게 질문을 요청하는 지시어는 '질문할지 여부'가 아니라 '어떻게 질문하게 할지'를 바꾸었다
요약
본 글은 AI에게 모호하거나 정보가 부족한 요청을 받았을 때, 단순히 질문할지 말지를 통제하는 것이 아니라 '어떻게' 질문하게 할지에 초점을 맞춘 연구 결과를 다룹니다. 특히, 확인 질문의 개수를 제한하더라도 내용 자체는 유지되면서 그룹화되는 경향을 관찰했습니다.
핵심 포인트
- 질문 개수 제한은 질문 여부를 바꾸지 않고 통합 및 구조화에 영향을 줌.
- AI가 추측으로 채우는지, 확인 질문을 하는지는 입력의 단서(prior) 유무에 달려있음.
- 정보 부족 시 AI는 자발적으로 확인 질문을 반환하는 경향이 있음 (조건 A).
TL;DR
- note 버전과 블로그 버전에서는 비엔지니어 사용자를 대상으로, AI에게 무작정 모든 것을 맡기는 요청에 "질문을 3가지로 제한하라"는 지시어를 추가하면 질문의 개수를 줄일 수 있다는 절차를 소개했다. Zenn 버전에서는 왜 이 지시어가 효과가 있었는지 한 단계 더 깊이 파고든 내용이다.
- 정보가 거의 없는 요청(대상도, 내용도 불분명한 "공지문을 작성해 줘" 등)을 (A) 무지시어, (B) "질문은 3가지까지", (C) B + "개조식/중요도 순"의 세 가지 조건으로 독립된 서브 에이전트에게 전달했다.
- (A) 단계에서 AI는 이미 추측에 의존하여 공지문을 생성하지 않고, 6가지 항목의 확인 질문을 반환했다. '질문은 3가지까지'를 추가한 B와 C는, 질문할지 안 할지를 바꾼 것이 아니라, 6개 항목을 줄이지 않으면서 3개의 그룹으로 통합하고, 게다가 "가안을 먼저 제시한다"는 제안을 제거했다. - (C)의 형식 지정(개조식/중요도 순)은 (B)에 비해 관찰 가능한 차이를 거의 만들지 못했다.
- 09-10 기사(작업 우선순위 지정)에서는 AI가 누락된 정보를 확인 질문 없이 추측으로 채우고 있었다. 오늘 다룬 작업과의 차이점에서, "확인 질문을 할지, 아니면 추측으로 채울지"의 경계는 추측의 발판이 되는 단서(prior를 적용할 수 있는 문맥)가 입력에 남아 있는지 여부일 것이라는 작업 가설을 세웠다.
배경
09-10 기사에서는 7개의 작업 이름만 전달하여 우선순위를 지정하게 했을 때, AI는 소요 시간이나 긴급도 정보가 없어도 확인 질문을 전혀 반환하지 않고, 추측으로 채워진 단정적인 출력을 내놓았다. 이 결과는 LLM 에이전트가 불명확한 지시에 직면했을 때 확인을 요청하지 않고 파라미터를 채우는 "task-completion bias"를 보고한 연구(Learning to Ask: When LLM Agents Meet Unclear Instruction, arXiv:2409.00557)나, LLM은 모호함을 인식하고 있어도 확인 질문을 거의 내놓지 않는다고 보고하는 연구(Knowing but Not Showing, arXiv:2605.25284)와 일치했다.
오늘 다룬 내용은, 그 "확인 질문을 하도록 유도하는" 쪽에 명시적인 허가 문구를 추가했을 때 행동이 달라지는지 검증하기 위해, 09-10보다 정보량이 더 적은 요청(대상 상품도 내용도 전혀 불분명한 "공지문을 작성해 줘")을 소재로 삼았다. 그 결과는, 09-10과는 대조적으로, 지시를 아무것도 추가하지 않은 조건 (A) 단계에서 AI가 자발적으로 확인 질문을 반환한다는 것이었다.
검증
입력(정보가 거의 없는 요청)
다음 주 판촉 캠페인 공지문을 작성해 줘
대상 상품, 할인 내용, 기간, 배포처, 톤 등 어느 것도 지정하지 않았다.
조건과 출력
조건 A (무지시어)
위의 요청을 그대로 전달했다.
반환된 것은 공지문이 아니라, 6개 항목의 확인 질문(캠페인 내용, 기간, 대상자, 배포/게재처, 문체/톤, 회사명/문의처)이었다. 게다가 "알 수 있는 범위 내에서 괜찮으니, 가상의 내용으로 초안을 먼저 만드는 것도 가능합니다"라는 대안 제시가 붙어 있었다.
조건 B (질문 개수 제한)
다음 주 판촉 캠페인 공지문을 작성해 줘. 모르는 점이 있으면,
답변하기 전에 모아서 질문해 주세요(3가지까지).
반환된 것은 3개 항목의 질문이었다. 내용을 대조해 보면, A에서 나온 6개 항목을 줄인 흔적은 없었고, "내용/기간/대상자", "배포처/타겟 독자", "톤/필수 요소"라는 3개의 그룹으로 통합되어 있었다. A에 있던 대안(가안 제시)은 사라져 있었다.
조건 C (형식 지정까지)
다음 주 판촉 캠페인 공지문을 작성해 줘. 모르는 점이 있으면,
답변하기 전에 모아서 질문해 주세요(3가지까지).
질문은 중요도 순으로 개조식으로 해 주세요.
반환된 질문은 B와 거의 동일한 3개 항목이었으며, 개조식/굵은 제목으로 정리되어 있다는 점을 제외하고는, 중요도의 배열 순서나 내용에 눈에 띄는 변화는 확인되지 않았다.
관찰 요약
질문할지 여부 자체: A, B, C 모두 확인 질문을 반환했고, 공지문을 추측으로 생성한 조건은 없었다. 지시어의 유무는 이 판단에 영향을 주지 않았다. -
질문의 개수와 구성: A는 6개 항목을 개별적으로 나열했고, B와 C는 같은 정보 범위를 3개 항목으로 통합했다. 항목이 누락된 것은 확인되지 않았다. -
대안 제시: A만 "가안을 먼저 제시할 수 있다"는 대안을 제시했으며, B와 C에는 없었다. -
형식 지정(C)의 효과: B와 비교했을 때, 시각적인 정리 이상의 차이는 관찰되지 않았다.
원리적 해석
⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.
원리적 해석
- '질문은 3개까지'라는 지시는, 확인 질문을 발생시키는 지시가 아니라 이미 발생하는 확인 질문의 제시 형식을 압축하는 지시였던 것으로 보인다. 정보가 완전히 결여된 요청에서는 확인 질문의 생성 자체가 지시에 의존하지 않고 일어나고 있으며, 개수 제한은 '개별적인 우려 사항을 몇 개의 발화 단위로 묶을 것인가'라는 표현 수준의 조작에 작용한 것으로 추정된다. -
항목이 누락되지 않았다는 점에서, 이번 통합은 요약적 압축(중요도가 낮은 항목을 잘라내는 것)이 아니라 관련 우려 사항을 그룹핑하는 작업이었던 것으로 보인다. '내용・기간・대상자'처럼 공지문의 골자를 구성하는 정보들끼리 묶였고, 독립적인 우려(배포처, 톤 등)와는 별도의 묶음으로 유지되었다. -
09-10과의 대비를 통해, 확인 질문을 할 것인지 추측으로 채울 것인지의 경계는 의존할 수 있는 prior(사전 지식으로 추측 가능한 단서)의 유무에 따른 것이 아닐까 하는 작업 가설이 세워진다. 09-10의 태스크명('거래처 이메일 회신' 등)은 일반적인 작업상으로부터 소요 시간이나 우선순위를 추측할 수 있는 발판이 있었던 반면, 오늘의 '홍보 캠페인 공지문'은 대상 상품도 내용도 전혀 제시되지 않아 추측의 출발점 자체가 존재하지 않았다. 이는 정보의 '양'이 아니라 '추측 가능성'이 확인 질문 발생의 분기점일 가능성을 보여주는 1차 관찰이며, CLAMBER 벤치마크(모호한 사용자 요구를 '해소 필요 모호성'의 타입별로 분류하는 연구, arXiv:2405.12063)와도 방향성이 일치한다. -
이 가설은 검증 부족으로 과도하게 일반화해서는 안 된다. 각 조건 1회 시도 및 요청문 1개만을 관찰한 것이며, 정보의 결여 정도를 단계적으로 변화시켰을 때 확인 질문 발생이 어디서 전환되는지는 미검증이다. 또한 09-10과는 다른 태스크 종류(우선순위 지정 vs 문장 생성)와 다른 모델 호출 방식(오늘은 Agent 도구를 통한 서브 에이전트)이라는 조건 차이가 있어, 요인을 엄밀하게 분리할 수 없다.
제약・재현성
- 검증은 Claude(본 세션, Agent 도구를 통한 독립 서브 에이전트 3체), 각 조건 1회 시도에 한정됨
- 요청 내용은 '홍보 캠페인 공지문' 1종류에 국한되어, 다른 무작위 위임 요청이나 다른 정보 결여 패턴에서의 재현성은 미검증
- ChatGPT・Gemini에서 동일하게 작동할지는 미검증
- 09-10 기사와의 대비는 다른 태스크 종류・다른 호출 방식을 포함하므로, '정보의 추측 가능성' 가설의 엄밀한 검증이 되지는 못함
참고문헌
- Learning to Ask: When LLM Agents Meet Unclear Instruction (arXiv:2409.00557)
- Knowing but Not Showing: LLMs Recognize Ambiguity but Rarely Ask Clarifying Questions (arXiv:2605.25284)
- CLAMBER: A Benchmark of Identifying and Clarifying Ambiguous Information Needs in Large Language Models (arXiv:2405.12063)
논의

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기