에이전트 워크플로우에서의 FreshContext: 컨텍스트 전달 시점의 판단

FreshContext를 공개적으로 공유한 후, 몇 가지 의견 덕분에 이것이 어디에 적합한지 더 명확히 다듬을 수 있었습니다.

한 분은 더 큰 데이터셋이나 운영 환경(production workloads)에서 테스트해 보았는지 물었습니다.

또 다른 분은 데이터 수집(ingestion)에 관한 중요한 점을 지적했습니다. 만약 테이블이 헤더를 잃어버리거나, 조항(clause)이 잘못된 위치에서 분리된다면, 판단 계층(judgment layer)이 확인하기도 전에 이미 컨텍스트(context)가 손상된 상태라는 것입니다.

그 덕분에 제품의 경계(product boundary)를 생각하는 더 나은 방법을 찾게 되었습니다.

FreshContext는 컨텍스트 전달(context handoff) 시점에 유용합니다.

단순한 구조는 여전히 다음과 같습니다:

후보 컨텍스트(candidate context) 입력  
결정 준비가 된 컨텍스트(decision-ready context) 출력

호출자(caller)가 후보 컨텍스트를 제공합니다. FreshContext는 신선도(freshness), 출처(provenance), 신뢰도(confidence), 유용성(utility), 소스 프로필(source profile)과 같은 신호(signals)를 사용하여 이를 평가합니다. 그런 다음 해당 컨텍스트를 어떻게 처리해야 하는지에 대한 결정을 반환합니다.

...

이것을 인용하라 (cite this)
이것을 검증하라 (verify this)
이것을 갱신하라 (refresh this)
배경 지식으로 사용하라 (use as background)
이것을 주시하라 (watch this)
이것을 제외하라 (exclude this)

이 부분이 제가 명확하게 유지하고 싶은 지점입니다.

...

더 큰 워크플로우(workflows)의 경우, 동일한 아이디어를 에이전트(agents) 사이에 배치할 수 있습니다:

리서치 에이전트 (research agent)
-> FreshContext 판단 (judgment)
-> 플래닝 에이전트 (planning agent)

모든 단계에 판단(judgment call)이 필요한 것은 아닙니다. 어떤 전달(handoffs)은 위험도가 낮습니다.

유용한 질문은 다음과 같습니다:

이 컨텍스트가 앞으로 넘어가기 전에, 우리가 이 컨텍스트를 얼마나 신뢰해야 하는지 알고 있는가?

검색(Retrieval)은 후보를 제공합니다. 판단(Judgment)은 처리를 제공합니다.

...

무엇이 관련이 있을 수 있는가?

FreshContext는 다음과 같이 묻습니다:

...

관련 있는 소스(source)라도 여전히 오래되었을(stale) 수 있습니다.

최근의 소스라도 여전히 취약할(weak) 수 있습니다.

유용한 소스라도 배경 지식(background)으로서만 적절할 수 있습니다.

공식 페이지라도 여전히 날짜 확인이 필요할 수 있습니다.

포럼 게시물은 유용한 신호(signal)일 수는 있지만, 증거(proof)는 아닐 수 있습니다.

이것이 바로 출력이 단순한 관련성 점수(relevance score) 이상이어야 하는 이유입니다.

점수는 컨텍스트(context)의 순위를 매길 수 있습니다.

하지만 결정(decision)은 다음 단계를 안내할 수 있습니다.

예시:

결정: verification_필요 (needs_verification)
이유: 관련은 있으나, 출처(provenance)가 불분명하고 소스 날짜가 명확하지 않음.
조치: 확인될 때까지 주요 출처로 인용하지 말 것.

이러한 종류의 출력은 에이전트(agent)에게 단순한 원문 텍스트(raw text)만 제공하는 것보다 훨씬 유용합니다.

인제스션 (Ingestion)은 여전히 중요합니다

한 커뮤니티의 댓글이 이 점을 잘 짚어주었습니다: 인제스션 (ingestion) 단계에서 구조를 보존할 때 판단(judgment)이 더 잘 작동합니다.

즉, 다음과 같은 요소들을 유지해야 한다는 의미입니다:

표 헤더 (table headers)
페이지 번호 (page numbers)
섹션 제목 (section titles)
소스 URL (source URLs)
타임스탬프 (timestamps)
저자 이름 (author names)
스키마 컨텍스트 (schema context)
문서 경계 (document boundaries)

만약 이러한 구조가 제거된다면, FreshContext가 불확실성을 표시할 수는 있겠지만 활용할 수 있는 정보는 줄어들게 됩니다.

...

구조 보존형 인제스션 (structure-preserving ingest)
-> 컨텍스트 판단 (context judgment)
-> 추론 (reasoning)

이는 각 계층(layer)마다 역할이 부여되어 있기 때문에 유용한 아키텍처(architecture)입니다.

...

이러한 소스들을 모두 동일하게 취급해서는 안 됩니다.

연구 논문(research paper)은 채용 공고(job post)처럼 가치가 빠르게 소멸하지 않습니다.

지원 티켓(support ticket)은 공식 문서(official documentation)와 동일한 증거 가치를 지니지 않습니다.

데이터베이스 행(database row)은 정밀해 보일 수 있지만, 주변의 스키마(schema)나 비즈니스적 의미가 누락되어 있을 수 있습니다.

포럼 게시물(forum post)은 유용한 커뮤니티 신호(community signal)를 보여줄 수 있지만, 여전히 증거로서는 취약할 수 있습니다.

FreshContext는 이러한 차이를 처리하기 위해 소스 프로필(source profiles)을 사용합니다.

목표는 간단합니다: 서로 다른 소스 유형에 대해 서로 다른 기대치를 가지고 판단하는 것입니다.

예시:

학술 연구 (academic_research)
공식 문서 (official_docs)
채용 기회 (jobs_opportunities)
...

사용자에게 보여지는 출력은 평이하게 유지되어야 합니다.

내부 규칙은 시간이 지남에 따라 더 구체화될 수 있습니다.

확장 가능성

현재 공개된 버전은 초기 단계입니다.

현재 evaluate_context 경로, 소스 프로필, 결정 출력, 데모, arXiv 증명 작업, 참조 어댑터(reference adapters), 그리고 신뢰 게이트(trust gates)가 작동하고 있습니다.

이는 아이디어의 형태를 테스트하기에는 충분합니다.

하지만 대규모 프로덕션 검증(production validation)을 주장하기에는 충분하지 않습니다.

다음으로 유용한 테스트는 실무적인 것들입니다:

더 큰 후보-컨텍스트 배치 (candidate-context batches)
더 많은 소스 프로필 (source profiles)
지연 시간 (latency) 및 처리량 (throughput) 점검
멀티 에이전트 파일럿 워크플로우 (multi-agent pilot workflows)
수집 품질 신호 (ingestion quality signals)
의사결정 벤치마크 세트 (decision benchmark sets)

저는 단순히 시스템이 더 커 보이게 만들기 위해 기능을 추가하고 싶지 않습니다.

...

판단(judgment)이 다음 단계를 개선하는가?

만약 그렇다면, 엔진은 성장할 가치가 있습니다.

...

만약 한 에이전트가 다른 에이전트에게 컨텍스트를 전달한다면, 받는 에이전트는 해당 컨텍스트가 신선한지(fresh), 출처가 명확한지(provenanced), 인용 가능한 수준인지(citation-grade), 불확실한지(uncertain), 배경 정보로만 사용될 것인지(background-only), 혹은 검증이 필요한지(in need of verification)를 알아야 합니다.

그것이 바로 FreshContext가 구축된 목적입니다.

후보 컨텍스트 입력 (candidate context in)
의사결정 준비 완료된 컨텍스트 출력 (decision-ready context out)

그것이 제가 유지하고자 하는 제품의 정체성입니다.