행동 로그만으로는 인간의 '판단'이 남지 않는다 — Continuous Reasoning Acquisition이라는 설계
AI를 업무에 통합할수록, 우리는 방대한 양의 로그를 갖게 되었습니다.
예를 들어 영업직이라면,
- 누구에게 제안했는지
- 무엇을 이야기했는지
- 어떤 자료를 보냈는지
- 어떤 건이 수주했는지
와 같은 정보는 CRM, 미팅 녹음, 채팅, 일일 보고서 등에 남습니다.
고객 지원(Customer Support)에서도, 개발에서도, 채용에서도 마찬가지입니다.
'무슨 일이 일어났는지'는 상당히 많이 남게 되었습니다.
반면, 거의 남아있지 않은 것이 있습니다.
그것은,
왜 그 사람이 그 판단을 했는지
입니다.
행동은 남지만 판단은 사라진다
예를 들어, 한 영업 담당자가 할인(discount)을 제안했다고 가정해 봅시다.
로그에는,
{
"action": "discount offered",
"outcome": "deal closed"
...
라고 남길 수 있습니다.
하지만 정말 알고 싶은 것은 그 사이의 과정입니다.
그 영업 담당자는,
- 고객의 무엇을 보고
- 어떻게 해석하고
- 무엇을 문제로 판단하며
- 왜 할인이라는 수단을 선택했는지
와 같은 과정을 거쳤을 것입니다.
예를 들어 실제로는,
고객이 가격보다 도입 리스크에 대해 반복적으로 질문했다
↓
진짜 우려는 가격이 아니라고 판단
...
같은 판단이었을 수 있습니다.
이 정보가 남아있다면,
- 최고 영업 담당자의 판단을 다른 멤버들이 배울 수 있고
- 매니저가 1on1에서 판단의 차이를 볼 수 있으며
- AI가 사용자별 판단 경향을 이해할 수 있고
- 여러 사람의 Reasoning을 비교할 수 있으며
- AI 학습 및 평가용 Reasoning Dataset을 만들 수 있습니다.
하지만 일반적인 로그에는 이 부분이 없습니다.
'LLM에 로그를 읽히면 된다'로는 부족하다
여기서 가장 먼저 떠오르는 것은,
미팅 로그나 일일 보고서를 LLM(Large Language Model)에 읽혀서 이유를 추출하고 추정하면 되는 것이 아닐까?
하는 방법입니다.
물론, 그것 자체는 할 수 있습니다.
문제는 그 이후입니다.
예를 들어 LLM이,
'이 담당자는 가격보다 도입 리스크가 주요한 우려라고 판단했다'
라고 생성했다고 가정해 봅시다.
이때 적어도 다음 의문점들이 남아있습니다.
- 그것을 본인이 실제로 말했는지
- 로그에서 추출했는지
- AI가 추정한 것인지
- 본인이 그 해석을 확인했는지
- 애초에 본인에게 물어봤는지
- 물어봤지만 답할 수 없었는지
- 애초에 판단 기준 자체가 존재하지 않았는지
생성된 문장만 보면, 이 모든 것이 뒤섞입니다.
즉 어려운 것은,
Reasoning을 생성하는 것이 아니라, Reasoning이 어디서 왔는지를 훼손하지 않고 데이터화하는 것
입니다.
Continuous Reasoning Acquisition
이 문제에 대해 설계한 것이 **Continuous Reasoning Acquisition (CRA)**입니다.
CRA는 인간의 Reasoning을 단 한 번만 상세히 인터뷰하기 위한 방법이 아닙니다.
일상 업무에서 발생하는 Event를 기점으로,
Event
↓
Initial Extraction
...
와 같은 형태로, Reasoning을 지속적으로 획득하고 축적하는 Method / Data Model입니다.
중요한 것은 모든 Event에 동일한 질문을 하는 것이 아니라는 점입니다.
먼저 기존 정보를 보고,
지금 이 Event에 대해 무엇이 알려져 있고, 무엇이 부족한지
를 판정합니다.
그 위에 필요한 경우에만 추가 획득하는 것입니다.
Gap Detection: 무엇을 물어봐야 할지는 사전에 완전히 정할 수 없다
Reasoning을 획득하는 데 어려운 점은, 질문 항목을 완전히 고정하기 어렵다는 것입니다.
예를 들어 같은 '제안을 보류했다(見送った)'라는 Event라도,
어떤 사람의 기록에는 이유까지 적혀 있을 수도 있습니다.
오늘은 가격 인상 제안을 보류했다.
담당자가 상사에게 상당히 몰리는 모습이었기 때문에,
지금 내도 사내 승인은 어렵다고 판단했다.
다른 사람은,
만 남길 수도 있습니다.
전자에 대해서는,
'왜 보류했나요?'
라고 다시 물어볼 필요가 없습니다.
반면, 후자에는 Reasoning이 없습니다.
따라서 CRA에서는 먼저 기존 Source에 부족 정보를 탐지합니다.
이를 Gap Detection이라고 부릅니다.
Gap의 예는,
missing_reason
missing_interpretation
missing_decision_criterion
...
등입니다.
필요할 때만 추가로 질문하기
Gap이 발견되었을 경우, 추가 질문을 진행합니다.
예를 들어,
'이번에는 왜 가격 인상 이야기를 꺼내지 않았나요?'
라고 묻는 것입니다.
답변이,
'담당자가 상사로부터 상당히 압박을 받고 있는 것처럼 보였고, 분위기가 무거웠기 때문입니다.'
였다고 가정해 봅시다.
이 답변을 통해,
- 행동 이유 (Action Reason)
- 상황 인식 (Situation Awareness)
두 가지를 동시에 얻을 수 있습니다.
반면, 새로운 Gap도 발견됩니다.
'분위기가 무거웠다'는 것을 본인은 어떻게 해석했는지?
여기서 더 나아가,
'그 상황에서 왜 지금이 가격 인상을 꺼낼 타이밍이 아니라고 생각하셨나요?'
라고 묻습니다.
그러면,
'지금 내도 사내 승인을 받을 수 없을 것 같다고 생각했습니다.'
라는 정보를 얻게 됩니다.
이처럼 질문은 고정된 흐름(fixed flow)이 아니라,
기존 정보 (Existing Information)
↓
Gap
...
와 같이 변화합니다.
'묻지 않은 것'인지 '물었지만 알 수 없었던 것'인지
여기는 CRA에서 특히 중요하게 다루는 부분입니다.
최종적인 Dataset만 보면,
decision criterion = null
로 되어 있을 수도 있습니다.
하지만 이 null에는 여러 가지 의미가 있습니다.
것인지,
것인지,
것인지는 완전히 다릅니다.
그래서 CRA에서는 Source의 상태와 Elicitation의 상태를 분리하여 보관합니다.
예를 들어,
Source state:
not_observed
observed_but_insufficient
...
입니다.
이를 통해,
'Reasoning Unit이 존재하지 않음'
것과,
'그 Reasoning을 얻으려고 시도했는지 여부'
를 구별할 수 있습니다.
Reasoning Unit이 존재하더라도 본인이 듣지 않은 경우가 있음
조금 복잡하지만, 중요한 케이스가 있습니다.
예를 들어 판단 기준에 대해 본인에게 질문하지 않았습니다.
하지만 기존의 여러 Source로부터 AI가,
'사내 승인이 어려운 상황에서는 가격 인상 제안을 뒤로 미룬다'
는 Decision Rule을 추정할 수 있었다고 가정해 봅시다.
이 경우,
Gap:
not_elicited
Reasoning Unit:
...
라는 상태가 성립합니다.
즉,
Unit이 존재한다 = 본인에게서 얻어낸 것
은 아닙니다.
이 구분을 남기지 않으면, 나중에 Dataset을 보는 사람이 AI 추정과 본인의 발언을 구분할 수 없게 됩니다.
실제로 만들어보니 알게 된 점
이 설계는 책상 위에서만 생각한 것이 아닙니다.
업무 회고를 통해 판단 이유를 추가로 얻어내는 프로토타입 Lessonary 를 만들고, 10명에게 각각 약 2주 동안 사용하게 했습니다.
45건의 initial entry에 대해, 각 입력마다 1~5회, 총 166회의 follow-up question이 진행되었습니다.
그 과정에서 LLM에 의해 정보를 구조화한 결과로, 적어도 두 가지 종류의 불일치(discrepancy)가 확인되었습니다.
하나는 확신도나 추측 표현이 누락되는 것입니다.
본인은 '사용하지 않을 것이라고 생각했던 것 같다'와 같이 추측을 포함하여 답변했습니다.
그런데 구조화된 결과에서는 '사용하지 않을 상태로 생각하고 있다'라는, 좀 더 단정적인 표현으로 바뀌어 있었습니다.
원래의 답변과 완전히 모순되는 것은 아닙니다.
하지만,
와,
는 같지 않습니다.
다른 하나는 **의미가 바뀌는 것 (meaning shift)**입니다.
본인은 첫 회고에서 '제안의 타이밍이 중요하다'라고 작성했고, 여기서 '타이밍'을
상대방으로부터 미팅 요청을 받았을 때
라는 의미로 설명했습니다.
그런데 최종적으로 구성된 판단 과정에서는 '타이밍'이,
상대가 기존 제품의 약점을 표명하고 그것과 개선점이 일치했을 때
라는 다른 의미로 대체되어 있었습니다.
이 역시 개별 Source와 완전히 모순되는 것은 아닙니다.
그래서 까다롭습니다.
최종적으로 생성된 Reasoning만 보면,
어디까지가 본인의 표현이고, 어디부터가 시스템에 의한 재구성인지
알아내기가 어렵습니다.
본인이 말한 것과 AI가 추출·추정·재구성한 것을 데이터 단계에서 분리해 둘 필요가 있습니다.
CRA(Continuous Reasoning Acquisition)에서 Source, Grounding, Derivation, Verification을 분리하고 있는 배경에는 이러한 구현 경험이 있습니다.
참고로, 이 예비적인 관찰은 Reasoning Trace의 인지적 타당성이나 취득 부하가 낮음을 증명하는 것은 아닙니다. 어디까지나 구현상 어떤 정보 손실 및 재구성이 발생할 수 있는지 확인한 것입니다.
Source / Grounding / Derivation / Verification을 분리하기
CRA에서는 Reasoning Unit의 생성 과정을 여러 축으로 나눕니다.
Source (출처)
원래가 된 정보입니다.
일일 보고서
상담 로그
본인의 추가 답변
...
등이 있습니다.
Grounding (근거화)
해당 Reasoning Unit이 어떤 Source에 근거하고 있는지를 나타냅니다.
{
"grounding": {
"source_ids": [
...
Derivation (도출)
Source로부터 해당 Unit이 어떻게 만들어졌는지를 보여줍니다.
예를 들어,
direct(직접 추출)
extracted(추출)
inferred(추론)
...
등입니다.
Verification (검증)
생성된 Unit이 이후에 확인되었는지를 나타냅니다.
confirmed(확인됨)
unconfirmed(미확인)
conflicting(상충함)
...
예를 들어,
extracted + unconfirmed
extracted + confirmed
inferred + unconfirmed
...
이 모두 가능합니다.
Derivation과 Verification은 별개의 축입니다.
'본인이 확인했다' = 인지 과정이 진실이었다는 의미가 아니다
여기서도 주의할 점이 있습니다.
본인이,
"네, 그 표현으로 맞습니다"
라고 확인했다고 하더라도, 그것은,
생성된 Unit이 본인의 의도나 현재 인식과 일치한다는 것을 의미합니다.
그 이벤트가 발생한 순간의 내부 인지를 완벽하게 재현할 수 있었다는 의미는 아닙니다.
인간의 자기 보고는 나중에 재구성될 가능성이 있습니다.
따라서,
subject-confirmed ≠ cognitively proven
입니다.
CRA의 Grounding이나 Verification은 인지의 '진실'을 보장하는 시스템이 아니라,
Dataset의 생성 과정을 추적 가능하게 만들기 위한 시스템
입니다.
JSON으로 만들면 이렇게 된다
예를 들어 하나의 Reasoning Unit은 다음과 같이 가질 수 있습니다.
{
"id": "unit_004",
"type": "decision_rule",
...
여기서,
- Unit이 존재하며
- 2개의 Source에 Grounding되어 있고
- AI에 의해
inferred된 Unit이며 - 본인 확인은 되지 않았고
- Confidence는 medium
라는 것을 알 수 있습니다.
문장만 저장하는 경우와 비교했을 때, 나중에 Dataset을 재평가하기 쉽습니다.
CRA는 LLM observability와 다른 레이어이다
LLM tracing이나 observability 시스템도 늘어나고 있습니다.
그것들이 기록하는 것은 주로,
어떤 모델을 호출했는지
어떤 Prompt를 보냈는지
어떤 Response가 돌아왔는지
...
입니다.
이것은 중요하지만, CRA가 기록하고 싶은 것과는 조금 다릅니다.
CRA가 다루는 것은,
본인은 무엇을 관찰했는지
어떻게 해석했는지
어디까지 본인이 말했는지
...
입니다.
즉,
LLM tracing은 'AI가 무엇을 했는지'를 추적합니다.
CRA는 '인간의 Reasoning에 관한 정보가 어떻게 취득되고 생성되었는지'를 추적합니다.
이 둘은 경쟁 관계가 아니라, 병용할 수 있습니다.
W3C PROV만으로는 안 되는가
CRA는 일반적인 Data Provenance 개념과 모순되지 않습니다.
W3C PROV와 같은 일반적인 Provenance 모델에 대응시킬 수도 있습니다.
다만 CRA에서는 인간의 Reasoning을 다루기 위해,
subject-stated
system-extracted
system-inferred
이러한 생성에 기인하는 차이나,
not_observed
not_elicited
elicited_but_unresolved
와 같은 획득 상태의 차이를 명시적으로 다룹니다.
즉, 새로운 Provenance 일반 이론을 만들고 싶은 것이 아니라,
Reasoning Dataset을 만들 때 무엇을 구분하여 남겨야 하는지를 구체화하고 있습니다.
활용 분야
이 설계는 특정 업무에 국한되지 않습니다.
예를 들어,
영업
상담 로그에 '무엇을 했는지'뿐만 아니라 판단 이유를 남깁니다.
AI 코칭
결과뿐만 아니라 어디에서 해석이나 판단이 어긋났는지를 확인합니다.
전문가 지식 캡처 (Expert Knowledge Capture)
숙련자의 방법뿐만 아니라,
어떤 상황에서 그 방법을 선택했는지를 축적합니다.
고객 지원 (Customer Support)
응대 결과뿐만 아니라, 오퍼레이터가 무엇을 보고 대응 방침을 바꿨는지를 남깁니다.
교육/훈련 (Education / Training)
정답/오답뿐만 아니라 판단 과정의 변화를 추적합니다.
AI 학습/평가 (AI training / evaluation)
최종 답변뿐만 아니라, 인간의 Event-grounded한 Reasoning Dataset을 구축할 수 있습니다.
등이 생각됩니다.
Acquisition Layer와 Representation Layer 분리하기
또 하나 중요한 것은 획득한 정보와 그 보여주는 방식을 분리하는 것입니다.
예를 들어 영업에서는,
observation
interpretation
decision_rule
...
과 같은 Representation이 유용할 수 있습니다.
다른 영역에서는 완전히 다른 분류가 될 수도 있습니다.
CRA에서는,
Acquisition Layer
↓
Representation Layer
을 분리합니다.
획득 시점의 Source, 질문, 답변, Derivation 등을 남겨둔 채로,
나중에 Representation Schema를 변경할 수 있도록 하기 위함입니다.
이를 통해,
처음 스키마 설계가 바뀌면 과거 데이터도 전부 사용할 수 없게 된다는 문제를 피하기 쉬워집니다.
GitHub에 Specification 공개했습니다
CRA의 Method 자체는 Preprint으로 공개했지만, Paper만으로는 구현 이미지가 파악하기 어려워 GitHub에도 Implementation-facing한 Specification을 공개했습니다.
Repository에는 현재,
README
Data Model
Elicitation History
...
등을 두고 있습니다.
Production Prompt나 구체적인 Gap Detection 로직 등은 포함하지 않고,
CRA를 구현할 때 최소한 어떤 정보를 구분하여 보존해야 하는지에 초점을 맞춰 공개하고 있습니다.
JSON Schema 역시 특정 애플리케이션의 고정 스키마가 아니라, CRA-compatible한 Record로서 잃어서는 안 될 구조를 중심으로 정의했으며, 도메인 고유의 Reasoning Unit이나 Gap 등은 확장할 수 있는 설계로 만들었습니다.
마지막으로
현재 AI 시스템은,
'인간이 무엇을 했는지'
를 획득하는 능력은 상당히 높아졌습니다.
반면,
'왜 그 사람이 그 판단을 내렸는지'
는 아직 Dataset으로서 거의 남아있지 않습니다.
LLM 덕분에 자유 기술(free description)에서 Reasoning을 추출/추정할 수 있게 되면서, 이 영역은 이전보다 다루기 쉬워졌습니다.
하지만 그때 중요한 것은 단순히 그럴듯한 Reasoning을 생성하는 것이 아닙니다.
무엇이 본인에게서 유래했는지
무엇이 AI에 의한 추출인지
무엇이 추론(Inference)인지
...
를 구분한 채로 축적해야 합니다.
Continuous Reasoning Acquisition은 그를 위한 하나의 설계입니다.
이미 '무슨 일이 일어났는지'를 가지고 있는 시스템에,
Reasoning Data Layer
을 추가하는 것.
그 가능성을 앞으로 여러 영역에서 검증해 나가고 싶습니다.
Links
본 Method의 구현, 기존 제품에의 통합, Reasoning Dataset 설계, 공동 연구 및 실증 등에 관심이 있으시면 GitHub 또는 프로필 기재 연락처로 문의해 주십시오.
＊본 기사 및 관련 자료는 LLM을 활용하여 작성되었습니다.
Discussion
