- Update roadmap milestones and phase docs across multiple phases - Update plan, code-review, create-roadmap, update-roadmap, finalize-task-routing skills - Update dev-corp-runtime-deploy, dev-runtime-deploy, orchestrate-agent-task-loop skills - Refactor agent-task-loop dispatch script - Add streamgate Go package (commit_boundary, evidence_tail, filter_registry, stream_release) - Add test inventory files (dev, dev-corp, unified) - Update test smoke tests and rules for dev/dev-corp - Update docs/edge-local-dev-guide and e2e scripts - Update inventory-query Go package - Remove deprecated templates and inventory.yaml files - Add orchestrate-agent-task-loop tests
141 lines
17 KiB
Markdown
141 lines
17 KiB
Markdown
# Milestone: Provider 입력 컨텍스트 선택과 축소
|
|
|
|
## 위치
|
|
|
|
- Roadmap: [ROADMAP.md](../../../ROADMAP.md)
|
|
- Phase: [PHASE.md](../PHASE.md)
|
|
|
|
## 목표
|
|
|
|
Agent, Open WebUI 같은 OpenAI-compatible chat client와 일반 API caller의 요청에서 누적된 이전 user 요청, assistant 답변, tool 결과와 검색 자료 중 현재 요청 수행에 필요한 내용만 provider 입력으로 전달하는 방향을 스케치한다.
|
|
최적화는 현재 요청과 관계없는 과거 요청-답변 묶음 전체를 제외하는 `요청-답변 단위 절단`과, 유지한 과거 답변·tool 결과 안에서도 필요한 문단·코드 블록·구간만 남기는 `단위 내부 내용 절단`을 구분한다.
|
|
관련성 판정과 구간 선택은 별도 로컬 모델이 수행하며 이 Milestone의 비용 평가는 로컬 모델 호출 금액을 `0`으로 간주한다. 다만 로컬 실행 latency, provider prompt cache 할인 손실과 잘못된 절단으로 발생한 provider 재시도 비용은 순절감 평가에 포함한다.
|
|
이 Milestone은 `caller/user -> IOP -> provider` 입력 경계만 소유하며, provider가 생성한 응답을 사용자에게 전달하는 출력 경계의 필터링·절단·보정은 다루지 않는다.
|
|
|
|
## 상태
|
|
|
|
[스케치]
|
|
|
|
## 승격 조건
|
|
|
|
- [ ] 최초 지원할 provider 입력 요청 표면과 누적 source 범위를 결정한다.
|
|
- [ ] 과거 user 요청부터 연결된 assistant/tool 호출·결과와 terminal assistant 답변까지를 하나의 요청-답변 단위로 묶는 경계를 결정한다.
|
|
- [ ] 유지한 요청-답변 단위 안에서 자연어 문단, 코드 블록, tool 결과와 검색 자료를 절단할 segment 및 원자적 보존 경계를 결정한다.
|
|
- [ ] 현재 요청 관련성, 후속 참조와 단위 간 의존 closure를 판정해 요청-답변 단위 전체 제거와 단위 내부 부분 제거를 수행할 정책 후보를 결정한다.
|
|
- [ ] system/developer/current user message, role/trust label, tool call-result 쌍, tool schema, 정확한 원문이 필요한 구간과 provenance/source pointer의 보존 경계를 결정한다.
|
|
- [ ] 사용자 요청, 상위 호출 계층 또는 provider dispatch가 확정한 target과 provider context window에서 출력 reserve·필수 입력을 제외한 effective input token budget을 컨텍스트 최적화 계층이 소비하는 단방향 책임 경계를 확정한다.
|
|
- [ ] 최초 MVP는 추출식 선택·제거를 우선하고, 새 내용을 생성하는 summary/compression은 별도 후속 후보로 분리할지 결정한다.
|
|
- [ ] 로컬 모델이 원문을 재작성하거나 tool을 실행하지 않고 제한된 형식의 요청-답변 단위 및 segment 보존·제거 선택만 반환하는 계약 후보를 정한다.
|
|
- [ ] 요청-답변 단위만 절단, 단위 내부 내용만 절단, 두 단계를 결합한 경우의 품질 손실, 원문 추적, token/cost 절감과 latency를 비교할 평가 기준과 fallback 후보를 정한다.
|
|
- [ ] 로컬 모델 호출 금액 `0`을 전제로 prompt cache 적중·할인 변화, 로컬 실행 지연과 provider 재시도 비용을 포함해 순절감 효과를 평가할 기준을 정한다.
|
|
- [ ] 짧은 입력이나 예상 절감량이 임계값보다 작은 요청을 bypass할 기준을 정한다.
|
|
- [ ] Advisor, Context Hook, RAG 운영 프로젝트, provider dispatch와의 연동·제외 경계를 확정한다.
|
|
- [ ] 요청-답변 단위 절단과 단위 내부 내용 절단을 각각 독립적으로 구현·검증할 후속 Milestone으로 분리한다.
|
|
- [ ] 후속 구현 Milestone별 provider 입력 API/request schema/runtime 호출 계약과 SDD를 작성할 수 있을 만큼 acceptance/evidence 경계를 정리한다.
|
|
|
|
## 구현 잠금
|
|
|
|
- 상태: 잠금
|
|
- SDD: 불필요
|
|
- SDD 문서: 없음
|
|
- SDD 사유: 현재 Milestone은 caller-neutral provider 입력 컨텍스트 최적화의 제품·책임 경계를 정리하는 스케치다. API/request schema와 runtime 호출 계약을 다루는 후속 구현 Milestone은 각각 SDD 대상으로 둔다.
|
|
- 잠금 해제 조건: 아래 체크리스트
|
|
- [ ] 승격 조건의 미정 항목이 사용자 검토로 해소되어 있다.
|
|
- [ ] 구현 가능한 MVP 범위와 후속 Milestone이 분리되어 있다.
|
|
- 결정 필요: 아래 체크리스트
|
|
- [ ] 최초 MVP가 직접 처리할 provider 입력 request surface와 source 조합을 결정한다.
|
|
- [ ] 요청-답변 단위 및 단위 내부 segment의 관련성을 rule, embedding/rerank, 별도 모델 판정 또는 hybrid 중 어떤 방식으로 판정할지 결정한다.
|
|
- [ ] 최초 배포를 observe-only/shadow, 명시 opt-in, 정책 기반 기본 적용 중 어떤 방식으로 시작할지 결정한다.
|
|
- [ ] 코드 블록, 구조화 tool 결과와 로그에서 통째 보존할 최소 원자 단위와 더 작은 구간 절단을 허용할 조건을 결정한다.
|
|
- [ ] 입력 길이, 예상 provider token 절감량과 로컬 실행 latency 중 어떤 조합으로 bypass 임계값을 정할지 결정한다.
|
|
- [ ] 품질 손실 또는 `cannot-fit` 발생 시 원문 fallback, 다른 target 재요청, 안전 중단 중 어떤 의미를 반환할지 결정한다.
|
|
|
|
## 범위
|
|
|
|
- Agent 요청뿐 아니라 Open WebUI와 일반 OpenAI-compatible client처럼 message history가 누적되어 들어오는 요청을 provider에 보내기 직전 구성하는 입력 컨텍스트
|
|
- 과거 user 요청부터 연결된 assistant/tool 호출·결과와 terminal assistant 답변까지를 하나의 요청-답변 단위로 구성하는 후보
|
|
- 현재 요청과 관계없음이 높은 신뢰도로 판정된 과거 요청-답변 단위를 전체 제외하고, 불확실하거나 참조·의존 관계가 있는 단위는 보존하는 후보
|
|
- 유지한 과거 assistant 답변, tool 결과와 검색 자료 안에서 현재 요청에 필요한 자연어 문단, 코드 블록, 로그·검색 구간만 선택하고 나머지를 제외하는 후보
|
|
- 코드 블록과 구조화 payload는 통째 보존을 기본으로 하고, symbol/file/line source pointer처럼 복원 가능한 경계가 있을 때만 더 작은 구간 절단을 허용하는 후보
|
|
- provider request의 role 순서, assistant tool call과 대응 tool result의 id·순서·쌍, endpoint별 schema invariant를 깨지 않는 입력 재구성 방향
|
|
- 요청-답변 단위 절단을 먼저 수행하고 남은 단위에 내부 내용 절단을 적용하되, 단위 간 참조·의존 closure를 함께 보존하는 방향
|
|
- target 모델의 context window와 token budget을 입력으로 받아 관련성 선택, dedupe, rerank와 extractive removal을 적용하는 최초 MVP 후보
|
|
- 로컬 모델이 원문을 재작성하지 않고 보존·제거할 요청-답변 단위와 segment reference만 제한된 형식으로 반환하며 tool을 호출하지 않는 selector 방향
|
|
- system/developer/current user 역할, instruction precedence, source trust label, tool/schema payload, exact-source 구간과 provenance/source pointer를 보존하는 방향
|
|
- 짧은 입력, 압축 불가 입력, 품질 손실 위험이 큰 입력의 bypass/abstain/cannot-fit 후보
|
|
- 로컬 모델 호출 금액은 `0`으로 두되 요청-답변 단위만 절단, 단위 내부 내용만 절단, 두 단계를 결합한 경우별 provider token/cost 절감, prompt cache 적중·할인, 로컬 실행 지연, provider 재시도 비용, 필요한 컨텍스트의 false-negative omission, 품질 변화와 pointer 유효성을 함께 보는 평가 방향
|
|
|
|
## 기능
|
|
|
|
### Epic: [context-opt] Provider Context Assembly Boundary
|
|
|
|
provider 입력 최적화의 source, budget, selector, request invariant와 fidelity 경계를 묶는다.
|
|
|
|
- [ ] [source-boundary] `caller/user -> IOP -> provider` 입력 경계에서 과거 user 요청부터 연결된 assistant/tool 호출·결과와 terminal assistant 답변까지를 하나로 묶는 source 및 요청-답변 단위 경계 후보가 정리되어 있다.
|
|
- [ ] [target-budget] 사용자 요청, 상위 호출 계층 또는 provider dispatch가 확정한 target과 provider context window에서 출력 reserve·필수 입력을 제외한 effective input token budget을 소비하되 컨텍스트 최적화 계층이 target을 선택하거나 재라우팅하지 않는 경계가 정리되어 있다.
|
|
- [ ] [selector-contract] 로컬 모델이 raw history를 재작성하거나 tool을 실행하지 않고 제한된 형식의 요청-답변 단위 및 segment 보존·제거 선택만 반환하며, IOP가 reference 유효성과 허용된 선택값을 검증하는 계약 후보가 정리되어 있다.
|
|
- [ ] [request-validity] 절단 후 provider request가 role 순서, assistant tool call과 대응 tool result의 id·순서·쌍, endpoint별 message/item schema invariant를 유지하고 orphan tool result나 깨진 구조화 payload를 만들지 않는 기준이 정리되어 있다.
|
|
- [ ] [fidelity] system/developer/current user message, role과 instruction precedence, source trust label, tool/schema payload, 단위 간 참조·의존 closure, exact-source 구간, provenance/source pointer와 품질 손실 위험을 보존하는 기준 후보가 정리되어 있다.
|
|
|
|
### Epic: [context-pruning] Extractive Context Pruning
|
|
|
|
요청-답변 단위와 단위 내부 segment를 extractive하게 절단하는 MVP 후보를 묶는다.
|
|
|
|
- [ ] [turn-prune] 현재 요청과 관계없음이 높은 신뢰도로 판정된 과거 요청-답변 묶음만 전체 제거하고, 현재 요청이 참조하거나 의존하는 이전 요청·답변·tool 결과의 closure와 불확실한 단위는 함께 보존하는 판정 후보가 정리되어 있다.
|
|
- [ ] [content-prune] 유지한 과거 assistant 답변과 tool/search 결과 안에서 현재 요청에 필요한 문단과 구간만 선택하되, 코드 블록·구조화 payload는 통째 보존하거나 복원 가능한 symbol/file/line 경계에서만 절단하는 판정 후보가 정리되어 있다.
|
|
- [ ] [opt-candidates] 최초 MVP는 요청-답변 단위 선택과 단위 내부 segment의 extractive removal을 우선하고, 새 내용을 생성하는 summary/compression은 별도 후속 후보로 분리하는 기준이 정리되어 있다.
|
|
|
|
### Epic: [context-rollout] Context Evaluation and Rollout
|
|
|
|
실패 의미, 품질·비용 평가, 연동 위치와 단계적 활성화 기준을 묶는다.
|
|
|
|
- [ ] [failure-result] timeout, invalid source pointer와 high loss risk에서는 원문이 budget 안에 들 때만 원문 fallback하고, 그렇지 않으면 임의 절단 없이 abstain/cannot-fit을 반환하는 의미 후보가 정리되어 있다.
|
|
- [ ] [quality-roi] 로컬 모델 호출 금액 `0`을 전제로 각 절단 모드의 제거율과 provider token/cost 절감뿐 아니라 prompt cache 적중·할인, 로컬 실행 지연, provider 재시도 비용, 필요한 컨텍스트의 false-negative omission, 응답 품질 변화, hallucination과 pointer validity를 비교할 평가 기준 후보가 정리되어 있다.
|
|
- [ ] [integration] provider 입력 assembly와 dispatch 사이에서 실행하되 라우팅, provider 응답 출력 필터, RAG 저장·최신화, Advisor 판단, Context Hook lifecycle과 겹치지 않는 연동 경계가 정리되어 있다.
|
|
- [ ] [rollout-policy] 짧거나 예상 절감량이 작은 입력은 bypass하고, 두 절단 단계를 독립적으로 enable/disable해 `shadow -> 고신뢰 요청-답변 단위 절단 -> 자연어 segment 절단 -> 제한된 코드·구조화 segment 절단` 순서로 활성화하는 정책 후보가 정리되어 있다.
|
|
|
|
## 완료 리뷰
|
|
|
|
- 상태: 없음
|
|
- 요청일: 없음
|
|
- 완료 근거: provider 입력의 두 단계 절단 방향을 정리한 스케치이며 관련성 판정, 보존 기준과 실패 정책은 아직 확정되지 않았다.
|
|
- 검토 항목: 없음
|
|
- agent-ui 상태 반영: 해당 없음
|
|
- 리뷰 코멘트: 없음
|
|
|
|
## 범위 제외
|
|
|
|
- direct, Plan, Milestone 분류와 local/cloud/model/provider target 선택
|
|
- provider가 생성한 응답을 사용자에게 전달하는 구간의 stream hold/release, 출력 필터링, 내용 절단·재작성, validation, retry와 repair
|
|
- RAG ingestion, embedding/index, 장기 기억 저장, freshness/update cycle
|
|
- teaching, self-update, shadow/canary, 증류·튜닝과 학습 데이터 운영
|
|
- Advisor의 조언·검토 정책과 generic Context Hook lifecycle 구현
|
|
- 현재 system/developer/current user 지시를 관련성 판정만으로 제거하거나 instruction precedence를 바꾸는 동작
|
|
- 검색/RAG/tool 결과의 비신뢰 content를 system/developer 지시처럼 승격하거나 source trust label을 바꾸는 동작
|
|
- assistant tool call과 대응 tool result를 분리하거나 id·순서·schema invariant를 깨는 절단
|
|
- 최초 MVP에서 추출 근거 없이 새 내용을 생성하는 summary/compression
|
|
- 로컬 selector 모델의 자유 형식 history 재작성, 새로운 사용자 지시 생성 또는 tool 실행
|
|
- 전체 conversation history 또는 최적화 결과의 중앙 영구 저장
|
|
- 세부 API field, event/schema, 패키지 구조와 특정 최적화 모델 확정
|
|
|
|
## 작업 컨텍스트
|
|
|
|
- 관련 경로: `apps/edge/internal/openai`, `apps/edge/internal/service`, `apps/node/internal/adapters/openai_compat`, `packages/go/policy`, `packages/go/metadata`
|
|
- 표준선(선택): 이 Milestone은 provider 입력 assembly와 dispatch 사이의 `caller/user -> IOP -> provider` 방향만 대상으로 한다. 과거 provider 답변이 다음 요청의 history source로 다시 들어온 경우에는 입력 source로 처리하지만, 생성 중인 provider 응답이나 사용자에게 전달되는 출력은 수정하지 않는다.
|
|
- 표준선(선택): 요청-답변 단위는 단순 인접 user/assistant 두 메시지가 아니라 user 요청부터 연결된 assistant/tool 호출·결과와 terminal assistant 답변까지의 묶음이다.
|
|
- 표준선(선택): 1차로 현재 요청과 무관함이 높은 신뢰도로 판정된 과거 요청-답변 단위를 제거하고, 2차로 유지한 단위의 assistant 답변·tool/search 결과에서 필요한 문단·코드 블록·구간만 남긴다. 불확실한 단위와 의존 closure는 보존한다.
|
|
- 표준선(선택): 코드 블록과 구조화 payload는 통째 보존을 기본으로 하며, symbol/file/line source pointer처럼 복원 가능한 경계가 있을 때만 더 작은 구간 절단 후보로 본다.
|
|
- 표준선(선택): assistant tool call과 대응 tool result는 id·순서·쌍을 유지하는 원자적 dependency로 취급하고, 절단 후 provider endpoint의 message/item schema를 다시 검증한다.
|
|
- 표준선(선택): 최초 MVP는 원문에서 필요한 구간을 고르는 extractive 방식으로 제한하고, 새 문장을 만드는 summary/compression은 별도 후속 후보로 둔다.
|
|
- 표준선(선택): 로컬 selector 모델은 요청-답변 단위와 segment reference에 대한 제한된 보존·제거 선택만 반환하고, IOP는 허용된 값, reference 존재와 provider request invariant를 결정적으로 검증한다.
|
|
- 표준선(선택): 짧은 입력이나 예상 provider token 절감량이 임계값보다 작으면 로컬 selector 호출과 절단을 bypass한다.
|
|
- 표준선(선택): 같은 입력과 정책에서 선택 결과가 안정적으로 재현되게 해 불필요한 prompt prefix 변동을 줄인다. 로컬 모델 호출 금액은 `0`으로 계산하되 provider token 감소에서 prompt cache 할인 손실과 provider 재시도 비용을 뺀 순비용, 로컬 실행 latency와 품질을 함께 평가한다.
|
|
- 표준선(선택): rollout은 두 단계를 독립 제어하며 `shadow -> 고신뢰 요청-답변 단위 절단 -> 자연어 segment 절단 -> 제한된 코드·구조화 segment 절단` 순서로 진행한다.
|
|
- 표준선(선택): caller가 agent인지 여부와 관계없이 누적되어 들어온 요청을 대상으로 하며, 특정 UI나 agent-family protocol에 종속된 분기를 기본 계약으로 두지 않는다.
|
|
- 표준선(선택): target과 budget은 사용자 요청, 상위 호출 계층 또는 provider dispatch가 확정하고 최적화 계층은 target별 context package만 반환한다. budget 불충족은 `cannot-fit` 같은 결과로 상위 계층에 알리되 자체 재라우팅하지 않는다.
|
|
- 표준선(선택): RAG retrieval 결과는 여러 context source 중 하나이며, RAG 저장·최신화와 튜닝 lifecycle은 이 Milestone이 소유하지 않는다.
|
|
- 표준선(선택): 현재는 구현 계약을 고정하지 않고 후보 동작과 책임 경계만 남긴다.
|
|
- 큐 배치: [Provider-Device-Model Qualification 리포트와 Lifecycle 관리](../../operational-observability-provider-management/milestones/provider-device-model-qualification-report.md) 뒤, [장기 기억과 RAG 업데이트 사이클 (2차)](long-term-memory-rag-second-wave.md) 앞
|
|
- 선행 작업: 기본 OpenAI-compatible 입력/relay 안정화, [요청 실행 로그와 Usage Ledger 기반](../../operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md)
|
|
- 후속 작업: 요청-답변 단위 절단 구현 Milestone, 단위 내부 내용 절단 구현 Milestone, 두 단계 결합 replay 평가, RAG와 Context Hook 연동
|
|
- 확인 필요: `구현 잠금 > 결정 필요` 항목
|