Tree of Thoughts 프롬프팅: 분기를 늘릴 가치가 있는 조건

Tree of Thoughts 프롬프팅은 풀이를 끝내기 전에 중간 결과의 가능성을 판단할 수 있을 때 추가 모델 호출의 가치를 발휘합니다. 아래 예시의 호출 예산을 적용하면 작은 탐색만으로도 1회 호출로 끝나던 작업이 21회로 늘어납니다. 먼저 추론 모델의 기본 성능을 확인하고, 탐색으로 해결할 수 있는 실패에만 분기를 추가하는 것이 좋습니다.

출처 확인일: 2026년 10월 24일. 아래 벤치마크 결과는 모두 Shunyu Yao와 공동 연구진의 2023년 원 논문에서 가져왔습니다. 분기 예제와 모델 호출 예산은 원리를 설명하기 위해 구성한 계산이며, 실제 운영 환경에서 보고된 결과가 아닙니다.

Tree of Thoughts 프롬프팅은 어떻게 탐색할까요?

Tree of Thoughts(ToT), 즉 ‘사고의 트리’는 애플리케이션이 아직 완성되지 않은 풀이들을 비교하고, 어느 풀이를 더 진행할지 선택하게 하는 방식입니다. 대규모 언어 모델(LLM)이 다음 단계를 제안하면 평가기가 그 결과로 만들어진 상태를 판단하고, 탐색 절차가 어떤 상태를 유지하거나 확장하거나 버릴지 결정합니다. Yao 연구진은 2023년 5월 이 프레임워크를 발표했습니다. 원 논문의 방법론.

건물 안에서 이동 경로를 찾는 상황을 떠올려 보겠습니다. 갈림길에서 곧바로 한쪽으로 들어가는 대신 여러 복도를 살펴볼 수 있습니다. 막힌 복도에는 더 이상 시간을 쓸 이유가 없습니다. 통과할 가능성이 있는 복도는 후보로 남겨 두고 다른 길도 확인할 수 있습니다. 아직 방향을 바꾸는 데 비용이 많이 들지 않을 때 경로를 수정할 수 있다는 점이 핵심입니다.

여기서 **사고(thought)**는 중간 작업을 나누는 유의미한 단위입니다. 수식 하나, 십자말풀이에 넣을 단어 하나, 글의 구성안 등이 될 수 있습니다. **상태(state)**에는 원래 문제와 지금까지 진행한 풀이를 함께 기록합니다. 작업 단위는 평가할 수 있을 만큼 충분히 크되, 대안을 시도할 가치가 있을 만큼 작아야 합니다.

이 반복 과정은 세 가지 동작으로 이루어집니다.

• 분기: 현재 상태에서 서로 다른 다음 단계를 제안합니다.
• 평가: 각 단계의 결과가 제약 조건을 충족하는지, 유효한 답에 도달할 가능성이 있는지 확인합니다.
• 가지치기: 탈락한 상태의 확장을 멈추고 남은 예산을 더 유망한 후보에 씁니다.

논문은 이 동작들을 너비 우선 탐색과 깊이 우선 탐색에 결합합니다. 너비 우선 탐색은 같은 깊이에 있는 유망한 후보들을 유지합니다. 깊이 우선 탐색은 한 분기를 따라가다가 실패하면 이전 상태로 돌아갈 수 있습니다. 작업에 맞게 탐색 방식을 선택하면 되며, 어느 쪽도 새 모델을 학습할 필요는 없습니다. 프레임워크와 탐색 알고리즘.

개발자 관점에서 달라지는 핵심은 중간 단계의 대안을 직접 제어할 수 있다는 점입니다. 모델에 신중하게 생각하는 듯한 답변을 요구하는 것만으로는 애플리케이션이 이런 제어권을 얻지 못합니다.

Tree of Thoughts와 Chain-of-thought는 어떻게 다를까요?

차이는 대안을 비교하는 시점에 있습니다. 풀이가 진행되는 도중에 비교하는지, 답을 모두 완성한 뒤에 비교하는지가 다릅니다.

이 구분은 Yao 연구진의 배경 설명과 방법론에 나옵니다. 기본적인 자기 일관성 방식은 완성된 추론 경로를 여러 개 샘플링한 뒤 가장 자주 나온 답을 선택합니다. 따라서 서로 다른 표현이 같은 답인지 판별할 수 있어야 합니다. 형식에 제약이 없는 서술형 답변은 수치형 결과보다 다수결로 판단하기가 까다롭습니다.

Chain-of-thought 프롬프팅은 중간 작업을 표현하는 데 도움이 될 수 있습니다. 자기 일관성은 완성된 여러 시도 사이의 다양성을 확보합니다. ToT는 가능성이 낮은 경로를 끝까지 진행하는 데 비용을 쓰기 전에 중단할 수 있도록 컨트롤러를 추가합니다. 다만 이 컨트롤러 때문에 새로운 실패도 생깁니다. 끝까지 진행했다면 성공했을 경로를 가지치기로 제거할 수 있습니다.

비슷해 보이는 다른 두 기법은 해결하는 문제가 다릅니다. 퓨샷 프롬프팅은 원하는 동작이나 출력 형식의 예시를 제공하므로 생성기나 평가기가 정해진 입출력 규약을 따르도록 도울 수 있습니다. 프롬프트 체이닝은 사실을 추출한 다음 답변 초안을 쓰는 식으로 여러 단계를 연결합니다. 고정된 단계의 연결이 탐색이 되려면 대안을 유지하고, 그중 어느 대안을 살펴볼지 결정해야 합니다.

실패 원인을 해결할 수 있는 가장 단순한 구조를 쓰는 것이 좋습니다. 출력 형식이 들쭉날쭉하다면 더 명확한 예시나 검증이 필요합니다. 근거가 빠져 있다면 관련 정보를 검색해야 합니다. 어느 경우도 곧바로 트리가 필요하다는 뜻은 아닙니다.

예제로 보는 분기·평가·가지치기

중간 수식이 맞더라도 결국 답을 구할 수 없는 상태에 이를 수 있습니다. 평가기는 이 차이를 구별해야 합니다.

논문의 Game of 24 예제를 보겠습니다. 4, 9, 10, 13을 각각 정확히 한 번씩 사용하고 사칙연산으로 24를 만들어야 합니다. 아래 풀이는 동작 원리를 보여 주기 위해 구성한 예시이며, 실제 모델 대화를 기록한 것이 아닙니다. 각 상태에서 풀이를 이어갈 수 있는지 여부는 남은 수로 만들 수 있는 연산 조합을 모두 열거해 확인했습니다. 논문에 나온 예제 입력.

1. 1

   시작 상태에서 분기하기

   후보 A는 4 + 9 = 13을 계산합니다. 남은 수는 10, 13, 13입니다.

   후보 B는 13 - 9 = 4를 계산합니다. 남은 수는 4, 4, 10입니다.

   두 계산 모두 규칙에 맞습니다. 같은 숫자가 반복되더라도 각각 별도로 남아 있는 값이므로, 상태를 기록할 때 개수를 그대로 유지해야 합니다.

2. 2

   분기 결과 평가하기

   후보 A는 남은 값을 각각 한 번씩 사용해 덧셈, 뺄셈, 곱셈, 나눗셈을 하더라도 24를 만들 수 없습니다. 이 분기는 제거합니다.

   후보 B는 정답으로 이어질 수 있습니다. 10에서 남은 4 하나를 뺀 다음, 다른 4를 곱하면 됩니다. 이 분기는 유지합니다.

   이 예제에서는 판단 과정을 확인할 수 있도록 정확한 산술 검사를 사용합니다. 논문의 탐색은 모델이 추정한 상태의 가치를 사용했으며, 그 추정은 틀릴 수 있습니다.

3. 3

   살아남은 분기 확장하기

   4, 4, 10에서 4 + 4 = 8을 계산하면 8, 10이 남습니다. 또는 10 - 4 = 6을 계산하면 4, 6이 남습니다.

   첫 번째 상태는 남은 연산으로 24를 만들 수 없습니다. 두 번째 상태는 4 × 6 = 24로 정답에 도달합니다. 이 경로를 유지하고 완성된 식을 검증합니다.

4. 4

   최종 답 검증하기

   (13 - 9) × (10 - 4) = 24는 원래 주어진 모든 수를 한 번씩 사용하며 목표값을 만듭니다. 결과가 문제의 검증 조건을 통과했으므로 탐색을 종료합니다.

이 작은 퍼즐은 모든 경우를 탐색하는 풀이 프로그램만으로 해결할 수 있습니다. 여기에 LLM을 추가하면 불필요하게 복잡해집니다. 예제의 목적은 반복 구조를 설명하는 데 있습니다. 실제 애플리케이션에서는 모델이 타당해 보이는 계획을 제안하고, 모델의 추측에 맡겨서는 안 되는 제약 조건은 코드가 확인하도록 역할을 나누는 것이 유용한 경우가 많습니다.

Tree of Thoughts 논문은 어떤 결과를 보고했을까요?

원 논문의 결과는 연구진이 선택한 작업에서 의도적인 탐색이 도움이 되었음을 보여 줍니다. 현재 운영 중인 작업에서도 그만큼 개선될 것이라고 보장하지는 않습니다.

Game of 24에서는 상대적으로 어려운 문제 100개로 GPT-4를 평가했습니다. 실험은 2023년 5월에 진행했습니다. 논문의 표 2에 보고된 성공률은 다음과 같습니다.

출처: Yao 연구진, 표 2와 Game of 24 실험 설정.

탐색 너비는 유지하는 상태의 수이며, 모델 호출 횟수가 아닙니다. 후보를 생성하고 평가하는 데도 작업이 필요합니다. Game of 24 실험에서 연구진은 각 후보의 가치 평가를 세 번씩 샘플링했습니다. 실험 설정.

논문은 창작 글쓰기(Creative Writing)와 소형 십자말풀이(Mini Crosswords)도 다룹니다. 각각 성격이 다른 작업이며 평가 방식도 다릅니다. 실무에서 이끌어 낼 수 있는 결론은 “ToT를 쓰면 모델 성능이 좋아진다”보다 범위가 좁습니다. 중간에 유망한 방향을 선택하는 것이 중요하고 그 방향을 평가할 수 있을 때 탐색이 도움이 될 수 있다는 뜻입니다. 개발자는 컨트롤러를 추가하기 전에 자신의 작업에서도 효과가 있는지 확인해야 합니다.

분기를 추가하면 모델 호출은 얼마나 늘어날까요?

생성, 평가, 최종 응답 생성을 따로 계산해야 합니다. 평가기가 후보 생성기보다 더 많은 호출을 사용할 수 있습니다.

논문의 실험 설정과는 별개로, 탐색 범위를 제한한 예시를 살펴보겠습니다. 여기서 호출은 애플리케이션이 보내는 모델 요청 한 번을 뜻합니다. 부모 상태 하나에 대한 제안 요청 한 번으로 모든 자식 후보를 생성하고, 각 자식은 별도의 요청으로 평가한다고 가정합니다. 재시도나 조기 종료 없이 정해진 깊이까지 탐색한 뒤, 마지막 호출 한 번으로 응답을 만듭니다.

확장하는 부모마다 자식 세 개를 생성하고, 각 깊이에서 상태 두 개를 남기며, 세 단계 깊이까지 확장한다고 하겠습니다. 깊이별로 확장하는 부모의 수는 1, 2, 2입니다. 따라서 호출 횟수는 다음과 같습니다.

• 생성: 1 + 2 + 2 = 5회.
• 평가: 3 × (1 + 2 + 2) = 15회.
• 최종 응답: 1회.
• 합계: 5 + 15 + 1 = 21회. 즉, 기본 방식의 1회 호출 대비 21배입니다.

각 후보의 평가를 세 번씩 반복하면 같은 트리에서도 호출이 5 + 45 + 1 = 51회가 됩니다. 반대로 각 깊이의 모든 후보 평가를 요청 하나로 묶으면 5 + 3 + 1 = 9회가 됩니다. 평가를 묶으면 평가기의 맥락과 판단 조건이 달라집니다. 이는 구현 방식의 선택지이며, 평가 품질이 같다는 보장은 아닙니다.

비교하자면, 자기 일관성 방식으로 샘플 다섯 개를 각각 요청하고 최종 다수결은 결정론적 코드로 처리할 경우 모델 호출은 다섯 번입니다. 별도의 모델 심사기를 쓰면 호출이 추가되므로 비교 조건도 달라집니다.

일반적인 호출 계산식은 C = Σ nₜ(g + kv) + f입니다. 여기서 nₜ는 깊이 t에서 확장하는 부모의 수, g는 부모당 생성 요청 수, k는 부모당 자식 수, v는 자식당 평가 요청 수, f는 최종 응답 생성 요청 수입니다. 이 식은 각 자식을 별도로 평가한다고 가정합니다. 평가를 묶어서 처리한다면 묶음 단위의 실제 요청 수를 직접 계산해야 합니다.

Tree of Thoughts LLM 설계: 탐색 제어는 애플리케이션이 맡습니다

탐색 상태와 종료 규칙은 애플리케이션 코드에서 관리해야 합니다. 모델에는 범위가 정해져 있고 직접 확인할 수 있는 결과물을 제안하거나 평가하도록 맡깁니다.

이 구조의 한계는 평가기의 품질에서 드러납니다. 평가기가 답으로 이어질 수 있는 부분 풀이와 그럴듯하지만 막힌 경로를 구별하지 못한다면, 분기를 늘릴수록 잘못 선택할 기회만 더 많아집니다.

1. 1

   확인 가능한 상태 정의하기

   제약 조건이 있는 일정 배정 기능이라면 상태에 배정된 작업, 남은 작업, 사용 중인 시간대, 아직 충족하지 못한 제약 조건을 담을 수 있습니다. 다음 사고 단위는 새로운 배정안으로 정의합니다. 상태, 후보 식별자, 부모 식별자, 판단 근거는 각각 분리해 저장합니다.

   현재 단계에서 검증할 수 있는 결과물을 선택해야 합니다. 좋은 전략을 세웠다는 막연한 설명만으로는 신뢰할 만한 가지치기가 어렵습니다.

2. 2

   생성과 평가의 역할 나누기

   생성기에는 다음과 같이 지시할 수 있습니다. “현재 상태에서 서로 다른 다음 배정안을 제안하세요. 각 후보의 배정안과 갱신된 상태를 반환하세요. 명시된 제약 조건을 유지하세요.”

   평가기에는 다음과 같이 지시할 수 있습니다. “각 후보가 제약 조건을 충족하는지 확인하세요. 후보 식별자와 위반한 제약 조건을 반환하고, 계속 진행할 수 있는지 ‘가능’, ‘불확실’, ‘불가능’으로 판단하세요. 판단의 근거가 되는 상태 필드를 제시하세요.”

   시간대 중복이나 필수 필드 누락처럼 규칙으로 판별할 수 있는 항목은 결정론적 검사를 먼저 적용합니다. 모델의 판단이 필요하다면 LLM-as-a-judge 평가 절차를 통해 정답을 알고 있는 사례로 그 판단을 검증해야 합니다.

3. 3

   가지치기 기준과 예산 명시하기

   반드시 지켜야 하는 제약 조건을 위반한 상태는 제거합니다. 남은 후보의 순위를 매기고, 앞으로 확장할 후보군의 크기를 제한하며, 중복 상태를 없앱니다. 예산이 허용하면 판단이 불확실한 후보도 남겨 둡니다. 평가기의 확신이 낮다는 이유만으로 해당 분기에서 답을 찾는 것이 불가능하다고 볼 수는 없습니다.

   요청 수, 탐색 깊이, 토큰 사용량, 경과 시간의 한도는 컨트롤러가 강제해야 합니다. 평가와 재시도도 이 한도에 포함합니다. 어떤 상태를 왜 버렸는지 기록해 두면, 가지치기가 성공 경로를 제거한 사례를 나중에 확인할 수 있습니다.

4. 4

   결과를 채택하거나 실행하기 전에 검증하기

   모든 일정 제약 조건 충족이나 관련 소프트웨어 테스트 통과처럼 최종 완료 여부를 확인할 검사를 사용합니다. 예산이 소진될 때까지 어떤 후보도 조건을 충족하지 못하면 미해결 결과를 반환하거나 검토 절차로 넘깁니다.

   분기 탐색은 샌드박스 안에서 수행하거나 실행 제안 상태로 유지해야 합니다. 아직 검토 중인 일정 배정 분기가 초대장을 보내서는 안 됩니다. 코딩 분기도 컨트롤러가 후보를 비교하는 동안 변경 사항을 배포해서는 안 됩니다.

최종 답뿐 아니라 평가기의 성능도 측정해야 합니다. 잘못된 탈락 판정은 유용한 분기를 영구적으로 없앨 수 있습니다. 잘못된 통과 판정은 남은 예산을 막힌 경로의 확장에 모두 쓰게 할 수 있습니다. 이 두 실패는 해결 방법도 다릅니다.

추론 모델만으로 충분한 경우는 언제일까요?

추론 모델이 이미 품질과 지연 시간 요구사항을 충족하고, 애플리케이션이 중간 단계의 대안을 직접 제어할 필요가 없다면 외부 ToT는 필요하지 않습니다.

추론 모델은 답변을 내놓기 전에 내부적으로 작업을 수행합니다. Anthropic의 현재 프롬프팅 지침은 사고 기능이 있는 모델에 추론 단계를 하나하나 지정하기보다 전반적인 목표를 제시할 것을 권장합니다. 따라서 명확한 작업, 제약 조건, 통과 기준부터 제시하는 접근이 타당합니다. 그렇다고 특정 모델이 내부에서 Yao 연구진의 ToT 알고리즘을 구현한다는 근거가 되는 것은 아닙니다. Anthropic 프롬프팅 지침.

작은 코드 변환 기능을 추가한다면 먼저 적합한 추론 모델을 써 보고, 결과에 관련 테스트를 실행합니다. 이 기본 방식으로 출시 기준을 충족한다면, 외부 트리는 효과가 입증되지 않은 채 상태 관리, 평가, 실패 처리 작업만 추가하게 됩니다.

애플리케이션이 모델 외에 기여할 수 있는 수단이 있다면 외부 탐색을 계속 선택지로 둘 수 있습니다. 시뮬레이터, 제약 조건 검사기, 격리된 테스트 환경이 있거나 서로 다른 후보 계획을 보존해야 하는 요구사항이 있는 경우입니다. 더 강력한 모델도 이 탐색 안에서 생성기 역할을 할 수 있습니다. 모델 자체의 추론과 애플리케이션이 제어하는 탐색은 별개의 설계 선택입니다.

결정은 실험 결과를 따라야 합니다. 측정된 자원 사용량을 정당화할 만큼 검증된 결과가 좋아질 때만 트리를 유지합니다. 답변이 더 길어지거나 추론 기록이 더 정교해지는 것 자체는 성공 기준이 아닙니다.

Tree of Thoughts를 둘러싼 과장은 무엇일까요?

가상의 전문가들에게 토론하라고 지시하는 프롬프트만으로는 통제된 트리 탐색이 구현되지 않습니다. 대안은 생성할 수 있지만, 운영 환경에서 ToT를 구현하려면 상태, 평가, 분기 선택, 종료 정책이 명시되어 있어야 합니다. 이 요소들이 모두 한 번의 응답 안에만 존재한다면, 설명한 탐색이 의도대로 실행되었다고 가정할 수 없습니다.

분기가 많을수록 더 좋은 답이 보장된다는 주장도 과장입니다. 여러 분기가 같은 아이디어를 반복할 수 있습니다. 평가 모델이 생성기와 똑같은 잘못된 가정을 공유할 수도 있습니다. 초기에 가지치기를 하다가 유일하게 쓸모 있는 후속 경로를 버릴 수도 있습니다. 확신에 찬 표현은 작업 결과의 검증을 대신하지 못합니다.

마지막으로, 논문에서 Game of 24의 최고 성적이 나왔다고 해서 모든 업무 흐름에 ToT가 필요하다는 뜻은 아닙니다. 문서 추출기의 출력이 스키마와 맞지 않는다면 더 나은 예시와 검증이 필요할 수 있습니다. 지원 어시스턴트가 정책을 모르고 있다면 올바른 출처를 제공해야 할 수 있습니다. 같은 정보가 빠진 상태에서 경로를 더 많이 탐색해도 누락된 사실이 생기지는 않습니다.

평가할 수 있는 여러 의사결정 대안이 있을 때 탐색을 사용합니다. 빠진 맥락과 지켜지지 않는 입출력 규약은 직접 바로잡아야 합니다.

이번 주 개발에 무엇을 적용할까요?

실패 사례에 초반 선택을 바꾸면 만회할 수 있는 문제가 있고, 중간 상태를 신뢰할 만하게 평가할 방법이 있다면 지금 적용해 볼 수 있습니다. 격리된 환경에서 검사하는 코드 변경 후보나 명시적인 일정 제약 조건으로 검증하는 계획이 그 예입니다. 이런 사례에만 적용하는 좁은 처리 경로를 만들고 탐색 예산을 고정한 상태에서 시작합니다.

어느 부분 풀이가 다른 풀이보다 왜 나은지 아직 설명할 수 없다면 기다리는 편이 좋습니다. 허용할 수 있는 상태와 허용할 수 없는 상태를 모아 평가기의 결정을 확인하고, 트리를 넓히기 전에 판단의 품질부터 개선합니다.

단순한 추출, 분류 또는 고정된 단계로 이루어진 작업이 이미 통과 기준을 충족한다면 크게 바꿀 필요가 없습니다. 더 단순한 현재 구조를 유지합니다.

주초에 바로 할 수 있는 일은 구체적입니다. 현재 Chain-of-thought 워크플로의 실패 사례를 모으고, 별도로 확보한 동일한 평가 과제에서 추론 모델의 기본 방식과 탐색 범위를 제한한 ToT 방식을 비교합니다. 최종 검증기는 그대로 유지합니다. 통과한 결과, 모델 호출 수, 토큰 사용량, 지연 시간, 가지치기로 성공 경로가 사라진 사례를 기록합니다. 이 결과가 도입을 뒷받침하는 작업 범위에만 탐색을 적용합니다.

Tree of Thoughts 자주 묻는 질문

추론과 Chain-of-thought는 같은 개념인가요?

추론은 문제를 풀어 나가는 전반적인 능력을 뜻합니다. Chain-of-thought는 중간 단계를 활용하는 프롬프팅 방식입니다. 모델은 그 단계를 답변에 출력하지 않고도 내부적으로 추론할 수 있습니다.

AI에서 트리란 무엇인가요?

트리는 상태와 그다음에 취할 수 있는 행동을 표현합니다. 노드 하나가 상태 하나를 나타내며, 자식 노드는 한 단계 더 진행해서 도달할 수 있는 대안들입니다. ToT에서 이 상태들은 부분 풀이를 나타냅니다.

추론 트리란 무엇인가요?

이 맥락에서는 여러 부분 풀이를 분기로 구성하고 평가한 다음, 어느 풀이를 계속 진행할지 선택하는 것을 뜻합니다. Yao 연구진이 제안한 구체적인 프레임워크의 이름은 Tree of Thoughts입니다.

Tree of Thoughts 프롬프팅이란 무엇인가요?

언어 모델로 중간 단계의 대안을 제안하고 평가하며, 탐색 절차를 결합해 확장할 상태를 선택하는 방식입니다. 전체 답을 완성하기 전에 앞선 결정을 다시 검토할 수 있다는 점이 실무적인 이점입니다.

프롬프팅의 세 가지 C는 무엇인가요?

Yao 연구진의 ToT 알고리즘은 세 가지 C 규칙을 정의하지 않습니다. 이 암기법은 ToT의 명세가 아닙니다. 논문은 사고 단위의 분해와 생성, 상태 평가, 탐색을 설명합니다.

Chain-of-thought와 Tree of Thoughts의 핵심 차이는 무엇인가요?

기본적인 CoT는 하나로 이어지는 추론 경로를 생성합니다. ToT는 서로 다른 부분 경로를 명시적으로 고려하고 탐색 도중에 평가합니다. 자기 일관성은 이들과 또 다릅니다. 완성된 경로를 여러 개 샘플링한 뒤 최종 답을 집계합니다.

Chain-of-thought 프롬프팅의 예시를 볼 수 있나요?

산술 풀이 예시로 13 - 9 = 4, 다음으로 10 - 4 = 6, 마지막으로 4 × 6 = 24를 보여 줄 수 있습니다. 이처럼 중간 단계를 예시로 제공하는 방식이 CoT입니다. 여기에 다른 단계들을 비교하고 어느 분기를 남길지 결정하는 과정이 더해지면 ToT의 탐색 구조가 됩니다.

Chain-of-thought를 쉽게 설명하면 무엇인가요?

계산이나 추론 같은 중간 단계를 통해 질문과 답을 연결하는 방식입니다. 이 단계들은 풀이 과정을 이해하는 데 도움이 될 수 있지만, 여전히 오류를 포함할 수 있습니다.

Chain-of-thought는 실제로 어떻게 작동하나요?

기본적인 프롬프팅 구성에서 모델은 문제와 앞서 생성한 텍스트를 바탕으로 중간 단계를 차례로 생성한 다음 답을 내놓습니다. 이 단계의 나열만으로는 정확성을 독립적으로 검증할 수 없으며, 애플리케이션이 관리하는 탐색 후보군도 생기지 않습니다.

신뢰할 수 있는 AI 워크플로를 만드는 실용적인 가이드를 받아 보려면 뉴스레터를 구독하세요.