update roadmap: knowledge-tool-optimization-extension, routing-policy-model-orchestration
This commit is contained in:
parent
0879dedc85
commit
1319e328fe
4 changed files with 147 additions and 0 deletions
|
|
@ -63,6 +63,10 @@ provider/device/model별 qualification report와 모델 lifecycle 관리는 prov
|
|||
- 경로: [PHASE.md](phase/knowledge-tool-optimization-extension/PHASE.md)
|
||||
- 요약: 로컬 모델 성능 향상 축으로 단계 호출, tool/schema 강제, 검증/retry/fallback의 MVP 실행 모드를 먼저 스케치하고, RAG 장기 기억, advisor, context hook은 2차로 분리한다.
|
||||
|
||||
- [스케치] 라우팅 정책과 모델 오케스트레이션
|
||||
- 경로: [PHASE.md](phase/routing-policy-model-orchestration/PHASE.md)
|
||||
- 요약: OpenAI-compatible 요청을 local/cloud/API provider 후보로 선택하는 routing policy, score policy, local triage, context optimizer, policy learning loop를 별도 도메인 축으로 스케치한다.
|
||||
|
||||
## 로딩 정책
|
||||
|
||||
- 일반 작업에서는 [ROADMAP.md](ROADMAP.md)를 매번 읽지 않는다.
|
||||
|
|
|
|||
|
|
@ -50,3 +50,4 @@ Ollama serving 경로와 운영 기반이 안정화된 뒤, 단계 호출, tool/
|
|||
- 기본 `/v1/models`, `/v1/chat/completions`, Edge-Node relay, Ollama option/API passthrough 안정화는 `Ollama 서빙 안정화 기반` Phase 책임이다.
|
||||
- 추가 추론 서버 provider의 adapter/config/target/model 매핑 표준화는 `추론 서버 provider 확장` Phase 책임이다.
|
||||
- 단계 호출, schema 강제, validation/fallback은 1차 MVP 후보로 검토하되, 장기 기억/RAG, advisor, context hook, cloud fallback, 품질 평가 feedback은 2차 또는 그 이후의 확장 책임으로 둔다.
|
||||
- local/cloud/provider API 선택, routing score, policy versioning, route learning loop는 별도 `라우팅 정책과 모델 오케스트레이션` Phase 책임으로 둔다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,29 @@
|
|||
# Phase: 라우팅 정책과 모델 오케스트레이션
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 목표
|
||||
|
||||
IOP의 OpenAI-compatible, A2A, IOP native 입력 표면에서 들어온 요청을 local/cloud/provider API 후보로 선택하는 라우팅 정책 도메인을 별도로 관리한다.
|
||||
이 Phase는 단순 provider capacity routing을 넘어 skill/예약어 기반 고신뢰 route, 자동 triage, context optimizer, score policy, route learning loop, API provider catalog를 연결해 비용, 품질, latency, local 우선 전략을 함께 최적화하는 책임을 다룬다.
|
||||
초기에는 컨셉과 정책 경계를 스케치하고, 구현 가능한 단위로 승격할 때 OpenAI-compatible metadata/config/schema, usage ledger, provider catalog와의 계약을 별도 SDD로 재판정한다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
스케치 Milestone은 아직 구현 가능한 계획이 아니므로 계획 Milestone보다 아래에 둔다.
|
||||
|
||||
- [스케치] OpenAI-compatible 하이브리드 라우팅과 컨텍스트 최적화
|
||||
- 경로: [openai-compatible-hybrid-routing-context-optimization](milestones/openai-compatible-hybrid-routing-context-optimization.md)
|
||||
- 요약: skill/예약어 기반 lane/grade 라우팅을 고신뢰 경로로 유지하고, DiffusionGemma 같은 로컬 모델을 자동 triage, negative guard, cloud context 최적화 보조, 주기적 scoring policy 학습 루프로 선택적으로 사용하는 hybrid local/cloud routing 방향을 스케치한다.
|
||||
|
||||
## Phase 경계
|
||||
|
||||
- 이 Phase는 routing policy, model/API provider selection, score policy, policy versioning, learning loop, local/cloud escalation 기준을 소유한다.
|
||||
- provider/device/model의 실제 serving path, lifecycle, model acquisition, runtime launch/restart는 `운영 관측과 Provider 관리` 및 provider runtime 후속 Milestone 책임으로 둔다.
|
||||
- planner/generator/verifier 단계 호출, tool/schema validation, output validation 자체는 `지식과 도구 최적화 확장` Phase 책임으로 두고, 이 Phase는 그 실행 모드를 어떤 provider/target으로 보낼지에 대한 route policy를 다룬다.
|
||||
- CLI agent task file 기반 `PLAN-{lane}-GNN.md`/`CODE_REVIEW-{lane}-GNN.md` 생성과 code-review loop lifecycle은 agent-ops skill 책임이며, 이 Phase는 그 결과를 runtime route signal로 해석하는 정책과 운영 데이터를 다룬다.
|
||||
- billing/chargeback, 조직 IAM, 장기 retention 정책은 후속 운영/보안 Milestone에서 결정한다.
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
# Milestone: OpenAI-compatible 하이브리드 라우팅과 컨텍스트 최적화
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: [ROADMAP.md](../../../ROADMAP.md)
|
||||
- Phase: [PHASE.md](../PHASE.md)
|
||||
|
||||
## 목표
|
||||
|
||||
OpenAI-compatible 방식으로 들어온 요청을 local/cloud provider와 여러 API 모델 후보에 안전하게 라우팅하는 하이브리드 라우팅 방향을 스케치한다.
|
||||
기존 `PLAN-local-GNN.md`, `CODE_REVIEW-cloud-GNN.md` 같은 skill/예약어 기반 라우팅은 frontier 모델이 판단한 고신뢰 경로로 유지하고, DiffusionGemma 같은 로컬 모델은 자동 라우팅 보조, triage schema filler, cloud context 최적화 전처리기로 선택적으로 사용한다.
|
||||
최종 라우팅은 deterministic hard gate, skill route 우선순위, local triage 결과, resource/quota/latency/cost 가중치, usage ledger feedback을 함께 보는 정책으로 구체화한다.
|
||||
이 Milestone은 지식/도구 hook의 하위 기능이 아니라 IOP의 별도 라우팅 정책 도메인에서 관리되는 최상위 스케치 작업으로 둔다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] 기존 skill/예약어 기반 lane/grade 라우팅과 OpenAI-compatible 자동 라우팅의 우선순위와 override 경계를 결정한다.
|
||||
- [ ] DiffusionGemma 또는 동급 local triage 모델이 채울 schema, confidence, abstain, validation 기준을 결정한다.
|
||||
- [ ] hard gate, weighted scorer, context optimizer, fallback/shadow mode를 어떤 실행 단계로 나눌지 결정한다.
|
||||
- [ ] local/cloud/provider API 후보의 capability, 비용, latency, quota, historical success를 어떤 metric으로 수집하고 route score에 반영할지 결정한다.
|
||||
- [ ] route score 정책을 즉시 self-mutation하지 않고, 학습 데이터가 일정량 쌓였을 때 주기적으로 policy proposal과 shadow/canary 검증을 거쳐 업데이트하는 루프를 결정한다.
|
||||
- [ ] 낮은 Gemma 계열 local 모델도 쉽게 판별할 수 있는 local 금지 예외 기준선과 negative guard label을 정리한다.
|
||||
- [ ] 이 Milestone을 별도 구현 Milestone으로 승격할 때 필요한 API/config/schema/ledger SDD 필요 여부를 재판정한다.
|
||||
- [ ] 사용자가 하이브리드 라우팅 MVP 범위와 후속 구현 우선순위를 검토했다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- SDD: 불필요
|
||||
- SDD 문서: 없음
|
||||
- SDD 사유: 현재 Milestone은 하이브리드 라우팅의 제품/운영 컨셉 스케치이며, OpenAI-compatible metadata/config/schema/ledger 구현으로 승격할 때 SDD 필요 여부를 재판정한다.
|
||||
- 잠금 해제 조건: 아래 체크리스트
|
||||
- [ ] 승격 조건의 미정 항목이 사용자 검토로 해소되어 있다.
|
||||
- [ ] 구현 가능한 목표, 범위, 기능 Task, 후속 구현 Milestone 후보가 분리되어 있다.
|
||||
- 결정 필요: 아래 체크리스트
|
||||
- [ ] skill/예약어 기반 라우팅 결과가 있을 때 자동 triage가 advisory로만 동작할지, hard gate 위반 시 cloud escalation을 제안할 수 있을지 결정한다.
|
||||
- [ ] 명시 route가 없는 OpenAI-compatible 요청에서 `iop-auto` 같은 자동 routing alias를 도입할지 결정한다.
|
||||
- [ ] DiffusionGemma 출력 schema를 route decision의 source of truth가 아니라 feature extraction/advisory signal로만 둘지 결정한다.
|
||||
- [ ] explicit `cloud` route를 local로 downgrade하는 동작을 금지할지, 어떤 사용자 opt-in에서 허용할지 결정한다.
|
||||
- [ ] explicit `local` route가 context/capability/tool/schema/privacy hard gate를 위반할 때 fail-fast, cloud escalation 권고, 또는 자동 cloud 전환 중 어떤 정책을 쓸지 결정한다.
|
||||
- [ ] fallback과 retry를 shadow/로그만 남길지, 같은 lane/grade 후보로 1회 자동 fallback할지, 사용자 승인 기반으로 둘지 결정한다.
|
||||
- [ ] 학습 모드가 frontier teacher 분석으로 policy proposal을 만들 때 필요한 최소 샘플 수, 업데이트 주기, 승인/검증 gate를 결정한다.
|
||||
- [ ] local로 보내면 안 되는 예외를 deterministic hard gate, 낮은 Gemma classifier, frontier teacher label 중 어느 단계에서 잡을지 결정한다.
|
||||
- [ ] 작은 local model이 판별할 negative guard 기준을 keyword/metadata/context feature/schema feature처럼 단순한 신호로 시작할지, 학습된 classifier로 확장할지 결정한다.
|
||||
- [ ] Claude, GPT, Gemini, GLM 같은 API provider 호출을 IOP 내부에서 어떤 `adapter + target` 후보로 표현하고 capability/catalog를 어떻게 관리할지 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- OpenAI-compatible 요청의 local/cloud/API provider 자동 선택 컨셉
|
||||
- 기존 skill/예약어/lane/grade routing과 자동 triage routing의 병행 운영 원칙
|
||||
- DiffusionGemma 같은 local model을 이용한 요청 분석 schema filling, confidence/abstain, parser validation, retry/repair 후보
|
||||
- context size, compressibility, exact-source 필요성, tool/function calling, strict JSON/schema, multimodal, privacy/local-only, latency SLA, provider availability를 포함한 hard gate 후보
|
||||
- route score 가중치 후보: capability fit, explicit route bonus, historical success, resource availability, quota remaining, latency fit, cost saving, local triage confidence, local risk, context loss risk, queue penalty
|
||||
- local model을 cloud context optimizer로 사용해 chunk, dedupe, rerank, summary, source pointer를 만들고 cloud token cost를 줄이는 방향
|
||||
- shadow mode, route log, usage ledger feedback으로 자동 라우팅 threshold를 보정하는 운영 루프
|
||||
- 주기적 learning mode: 실제 라우팅은 현재 policy version으로 유지하되, 축적된 요청/결과를 frontier teacher가 분석해 다음 scoring policy 후보를 제안하고 shadow/canary 검증 후 승격하는 방향
|
||||
- local 금지 예외 탐지: 낮은 Gemma 계열 모델도 판별 가능한 negative guard 기준선, cloud escalation reason, abstain/fail-fast 후보
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [hybrid-route] Hybrid Routing Concept
|
||||
|
||||
skill route와 자동 route를 경쟁시키지 않고 서로 다른 신뢰도의 라우팅 신호로 결합하기 위한 컨셉 산출물을 묶는다.
|
||||
|
||||
- [ ] [route-sources] skill/예약어 기반 `PLAN-{lane}-GNN.md`와 `CODE_REVIEW-{lane}-GNN.md` 라우팅을 권위 있는 경로로 두고, 자동 triage를 advisory 또는 명시 route 부재 시 기본 경로로 쓰는 우선순위가 정리되어 있다.
|
||||
- [ ] [triage-schema] DiffusionGemma 또는 동급 local 모델이 채울 `task_type`, `difficulty`, `context_dependency`, `compressibility`, `required_capabilities`, `local_success_probability`, `cloud_quality_need`, `fallback_required`, `abstain`, `risk_reasons` schema 후보가 정리되어 있다.
|
||||
- [ ] [hard-gates] context window, tool/function calling, strict JSON/schema, multimodal input, privacy/local-only, latency SLA, provider availability, explicit local/cloud/user mode 같은 deterministic gate 후보가 정리되어 있다.
|
||||
- [ ] [score-policy] hard gate를 통과한 후보에 대해 explicit route bonus, capability fit, historical success, resource/quota, latency, cost, triage confidence, risk/queue penalty를 조합하는 weighted scorer 후보가 정리되어 있다.
|
||||
- [ ] [context-opt] 100k 이상 같은 단순 token threshold보다 compressible/exact-source 기준을 우선하고, local context optimizer가 cloud prompt를 줄이는 경로가 정리되어 있다.
|
||||
- [ ] [fallback-shadow] D01류 실행 실패 정책과 충돌하지 않도록 초기에는 shadow/advisory/route log 중심으로 운영하고, 자동 fallback은 별도 결정 뒤 구현하는 기준이 정리되어 있다.
|
||||
- [ ] [learning-loop] route score를 즉시 변경하지 않고, 일정량의 route log/outcome/teacher label이 쌓였을 때 policy proposal, offline evaluation, shadow/canary, version 승격 또는 폐기를 수행하는 주기적 학습 루프가 정리되어 있다.
|
||||
- [ ] [negative-guards] local로 보내면 안 되는 예외 케이스를 낮은 Gemma 계열 모델이 쉽게 판별할 수 있도록 단순 feature, label, escalation reason, abstain 기준으로 정리되어 있다.
|
||||
- [ ] [api-provider] Claude, GPT, Gemini, GLM 등 API provider와 local provider를 IOP 내부 `adapter + target` 후보로 표현하는 catalog/capability 방향이 정리되어 있다.
|
||||
- [ ] [ops-feedback] route decision, 후보 점수, 선택/실패 사유, token 절감량, 품질/성공 결과를 usage ledger와 qualification/report 후보에 연결하는 feedback loop가 정리되어 있다.
|
||||
- [ ] [user-review] 사용자가 skill route 우선, 자동 triage 보조, weighted scorer, context optimizer, fallback/shadow 운영 방향을 검토했다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
|
||||
- 검토 항목:
|
||||
- [ ] 사용자가 컨셉 방향을 검토했다.
|
||||
- [ ] 승격 조건과 결정 필요 항목이 후속 구현 Milestone으로 분리되었다.
|
||||
- [ ] archive 이동을 승인했다.
|
||||
- agent-ui 상태 반영: 해당 없음
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- OpenAI-compatible metadata/config/proto/API schema 구현 확정
|
||||
- 실제 route scorer, provider adapter, cloud API 호출 코드 구현
|
||||
- DiffusionGemma 또는 특정 local model serving 배포 구현
|
||||
- 자동 retry/fallback, 중복 실행 방지, partial output 정리의 최종 정책 구현
|
||||
- billing/chargeback, 조직 IAM, 장기 retention 정책
|
||||
- RAG 장기 기억 저장소나 Agent Shell 전용 advisor UX
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/edge/internal/openai`, `apps/edge/internal/service`, `apps/node/internal/adapters/openai_compat`, `packages/go/config`, `packages/go/policy`, `proto/iop`, [openai-compatible-api.md](../../../../agent-contract/outer/openai-compatible-api.md)
|
||||
- 표준선(선택): 내부 실행은 `adapter + target` 기준을 유지하고, 외부 OpenAI-compatible 경계의 `model` 표현은 alias 또는 compatibility surface로만 취급한다.
|
||||
- 표준선(선택): skill/예약어 기반 lane/grade 결과는 frontier 모델이 판단한 고신뢰 route signal이며, 자동 triage는 명시 route가 없는 요청이나 context optimizer/advisory 경로에서 우선 사용한다.
|
||||
- 표준선(선택): DiffusionGemma 출력은 최종 판결이 아니라 feature extraction 결과로 보고, schema validation, confidence threshold, abstain, cloud escalation 후보를 함께 둔다.
|
||||
- 표준선(선택): explicit `cloud` route는 자동 local downgrade하지 않고, explicit `local` route도 hard gate 위반 시에는 fail-fast 또는 cloud escalation 권고를 남기는 방향을 우선 검토한다.
|
||||
- 표준선(선택): learning mode는 현재 scoring policy를 즉시 바꾸지 않고, versioned policy proposal을 만든 뒤 offline evaluation과 shadow/canary 검증을 통과한 경우에만 주기적으로 승격한다.
|
||||
- 표준선(선택): 작은 Gemma 계열 모델이 맡는 negative guard는 복잡한 품질 판단보다 local 금지 신호를 낮은 비용으로 감지하는 역할을 우선하며, 애매하면 `abstain` 또는 cloud escalation 후보로 남긴다.
|
||||
- 선행 작업: [CLI Agent Group Grade Routing](../../automation-runtime-bridge/milestones/cli-agent-group-grade-routing.md), [요청 실행 로그와 Usage Ledger 기반](../../operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md), [Provider-Device-Model Qualification 리포트와 Lifecycle 관리](../../operational-observability-provider-management/milestones/provider-device-model-qualification-report.md)
|
||||
- 후속 작업: 자동 route scorer 구현, OpenAI-compatible routing alias/config 구현, local context optimizer 구현, 품질 기반 routing/fallback 고도화
|
||||
- 확인 필요: `구현 잠금 > 결정 필요` 항목
|
||||
Loading…
Reference in a new issue