Conversation
1. Feedback_Ingestion_Pipeline_Spec.md 2. ML_Pipeline_Execution_Spec.md
학습 완료 이후 재색인·롤백 계약 및 제약사항 명시
HTTP / RPC / Consumer 인터페이스 -> 외부 진입 인터페이스 사유: 경우에 따라 HTTP / RPC / Consumer 세 항목에 포함 안되는경우도 있기 때문
|
0416 model_release_and_reindex_spec 작성하였습니다. 앞서 작성한 |
- Admin Control Plane 스펙을 추가해 관리자 조회 및 제어 액션 계약을 정의 - ML Pipeline Execution 스펙에 모델 평가 완료 후 릴리스 단계로 넘기는 조건을 구체화 - Model Release and Reindex 스펙을 공통 저장 상태를 다시 읽어 시작하는 방식에 맞게 정리
|
0417 Admin Control Plane spec 신규 추가 |
| ## 1. 목적과 범위 (Purpose and Scope) | ||
|
|
||
| ### 1.1 한 줄 요약 | ||
| - Feedback Ingestion Pipeline(FIP)은 Core API Server가 검증 완료한 검색 응답 단위 피드백 이벤트를 비동기로 수신하여, 손실을 최소화하면서 수정 불가능한 원본 로그로 Object Storage에 적재하는 컴포넌트다. |
There was a problem hiding this comment.
질문: 지금은 피드백을 Core API Server 가 받아주고 있는데, 별도로 APIi 를 분리하는 것과 Core API Server 가 받는 것의 장단점이 무엇이 있을까요?
There was a problem hiding this comment.
Core API가 받는 방식의 장점은, 이미 Core API가 가진 인증/인가 흐름과 사용자 컨텍스트를 그대로 활용해 피드백 유효성 검증을 일관되게 처리할 수 있다는 점입니다.
단점은 피드백 트래픽이 몰릴 경우 Core API의 다른 기능에도 부하가 전파될 수 있고, Core API에 업로드/삭제/재처리 외에 피드백 public endpoint와 검증 책임이 추가되어 책임 범위가 넓어진다는 점입니다.
별도 Feedback API를 두면 피드백 트래픽과 배포를 분리할 수 있지만, 인증/인가와 req_id 검증 책임을 다시 구현하거나 Core API/Metadata DB와 연동해야 하므로 중복과 운영 복잡도가 생깁니다.
| - Transport: Core API가 broker로 publish하고, FIP가 비동기로 consume한다. | ||
| - Routing surface: feedback 전용 메시지 경로를 둔다. 물리 queue/topic/exchange 이름은 이 SPEC에서 고정하지 않는다. | ||
| - Producer / consumer responsibility: | ||
| - Producer(Core API): `req_id` 스냅샷 검증, 사용자/시간 창/무효화 여부 검사, feedback 전용 계약으로 broker publish |
There was a problem hiding this comment.
질문: 사용자의 피드백이 매우 많은 경우에 어떻게 대응해야할까요?
- 인스턴스를 무한정 늘린다?
- 받을 수 있는 만큼만 받는다?
- 그 외에는??
There was a problem hiding this comment.
이런 로그를 받아들이는 vector.dev 같은 녀석은 어떻게 동작할까요?
|
|
||
|
|
||
| #### 외부 서비스 계약 (해당 시) | ||
| | Dependency | Used for | Required behavior / assumption | Failure impact | |
There was a problem hiding this comment.
질문: 그런데 이거 제가 vector.dev 같은 외부 서비스 쓰자고 했던 것 같은데..?
There was a problem hiding this comment.
여기서 말하는 “외부 서비스 계약”은 외부 인프라 여부가 아니라, 이 컴포넌트가 런타임 중 연동하는 다른 컴포넌트와의 계약사항을 적는 항목입니다.
다만 “외부 서비스”라는 표현이 외부 인프라/SaaS로 오해될 수 있어서, 섹션명을 “외부 연동 컴포넌트 계약”으로 바꾸겠습니다.
Vector처럼 FIP 자체를 구성하는 런타임 기술은 1.3 기술 스택 선택에 표기해뒀습니다.
|
|
||
| ### 2.4 한계와 운영 제약 | ||
| - Performance / latency target: | ||
| - 사용자 동기 응답이 아니라 비동기 적재 경로이므로 per-event 저지연보다 손실 최소화와 backlog 회복 가능성을 우선한다. |
There was a problem hiding this comment.
질문: 사용자 피드백을 "손실 최소화", "backlog 회복 가능성" 우선으로 두는 이유는?
There was a problem hiding this comment.
배치 처리 주기에 지장을 줄 정도로 적재가 밀리지 않는 한, 단건 저지연보다 검증된 피드백 이벤트를 잃지 않고 보존하는 것이 더 중요하다고 봤습니다.
왜냐하면 피드백 손실은 학습 데이터셋의 품질과 이후 모델 성능 역추적에 영향을 줄 수 있기 때문입니다.
|
|
||
| ### 간단한 흐름 (Simple Flow) | ||
| 1. 원본 피드백 로그에서 신규 이벤트를 읽어 학습 데이터셋 버전을 만든다. | ||
| 2. 활성 실행이 없으면 즉시 실행을 시작하고, 있으면 최신 데이터셋 기준 다음 실행 하나만 남긴다. |
There was a problem hiding this comment.
질문: 만약 검증 시간이 오래 걸리면 검증하는 동안 학습 데이터셋 버전을 미리 만들어두면 좋지 않을까요? 한번에 하나를 "반드시" 고수할 필요가 있는지..?
1. 외부 서비스 계약 -> 외부 연동 컴포넌트 계약 - 항목 명칭 수정 2. Vector 설정 기반 수집/재시도 계약으로 정리 - FIP를 custom consumer가 아니라 Vector 기반 ingestion pipeline으로 표현 - broker read, Object Storage sink, buffer/retry를 Vector source/sink 설정과 broker 재전달에 맡김 - 미지원 schema/필수 필드 누락을 error_logs/ sink로 라우팅 - “consume/ack/nack” 같은 직접 consumer 구현 뉘앙스를 줄임
- feedback event 전용 PostgreSQL MQ queue 계약을 명시한다. - `event_id` 기준 idempotency와 curation dataset dedupe 책임을 정리한다. - raw log 영속화 완료 기준, retry 고갈 시 보존 경로, Vector 설정의 버전 관리 대상 여부를 명시한다. - broad한 `invalid message` 상태를 `unsupported_schema_version`과 `malformed_feedback_event`로 분리한다. - raw log 적재 지연, 실패율, backlog/ingestion lag 노출 기준을 service level contract로 추가한다.
|
2 participants
summary
작성한 spec 문서
두 컴포넌트에 대한 spec 문서를 작성하였습니다.
피드백 루프의 경우 책임 범위가 넓어서,
(1) 피드백 데이터 전처리-> 모델 학습 및 평가 : ML_Pipeline_Execution_Spec.md
(2) 학습된 모델로 재색인 및 배포(모델 교체): Model_Release_and_Reindex_Spec.md
로 분리하여 작성하되 구현시에는 한 컴포넌트로 구현하려 합니다.
관리자 기능과 observation 부분도 이어서 작성되는대로 이 pr에 커밋하고 코멘트 달겠습니다.
해서 리뷰 해주실때
docs(admin-ops): 관리자 기능 컴포넌트별 spec 작성 이 commit만 보시면 됩니다!!
관련 이슈
Closes #55