Skip to content

English {#english}

Worker AI Implementation Plan

Purpose: Define scope, requirements, and architecture for Edge-Native Worker AI to build and use Prego’s core knowledge base. No code generation — planning and specification only.

Document version: 1.0

References: rag-ai-edge-architecture-plan.md, rag-ai-phase1-implementation-plan.md, zuplo-ai-metering-policy.md.

Contents: §1 Purpose·scope · §2 Assumptions·refs · §3 Architecture · §4 Module requirements · §5 UI/UX · §6 Security·compliance · §7 Deployment · §8 Implementation order·Phase · §9 Verification · §10 Open items · §11 API · §12 D1·Vectorize schema · §13 Limits·errors · §14 PDF extraction · §15 Streaming · §16 Tenant·onboarding · §17 Monitoring · §18 Glossary · §19 Related plans.

Recommended reading order for implementation: §8 → §11 → §12 → §4 → §7. Before deploy: §9 verification, §13 limits, §13.1 edge constraints.


1. Purpose and Scope

1.1 Purpose

  • Edge-Native Data Ingestion: PDF (and similar) upload → text extraction → chunking → embedding → Vectorize storage, all on the Cloudflare edge.
  • RAG Query: User question → embedding → Vectorize similarity search (tenant-isolated) → context augmentation → Workers AI answer.
  • Compliance Checker: Cross-check central (MOM) statutory knowledge and tenant company policy → CRITICAL / WARNING / COMPLIANT.
  • PII protection: NRIC/FIN etc. masked at the edge, inbound (before AI) and outbound (before client).
  • UI/UX: Context-aware AI chat, source attribution, streaming responses, chat history with auto-deletion policy.

1.2 Scope

In scopeOut of scope
Requirements, interfaces, pipeline spec for Data Ingestion, RAG Query, Compliance Checker, PII FilterActual TypeScript/code
Vectorize, D1, R2, Workers AI bindings and deployment layoutPulumi scripts (see RAG Phase1·architecture)
Zuplo gateway, metering, PII strategyZuplo Config as Code detail
Security·compliance (PDPA, tenant isolation) principlesAudit log schema detail

2. Assumptions and References


3. Architecture Overview

3.1 Data Ingestion Pipeline

[Client] PDF upload (Multipart Form)
[Worker] R2 temp store (audit/reprocess, tenant prefix)
[Worker] Text extraction (edge: WASM-compatible PDF lib)
[Worker] Chunking (e.g. 512 tokens, dedup/whitespace trim)
[Worker] Workers AI embedding (same model: bge-small-en-v1.5)
[Vectorize] upsert (id, values, metadata: tenantId, source, content, page)
[Worker] Delete R2 temp object when done (PDPA retention)

3.2 RAG Query Pipeline

[Client] POST { question } + x-tenant-id
[Worker] (optional) PII Inbound filter
[Worker] Question embedding (same model as Ingestion)
[Vectorize] query(vector, topK, filter: { tenantId }, returnMetadata: true)
[Worker] Assemble context (top K chunks + source metadata)
[Workers AI] System prompt + Context + Question → answer (anti-hallucination)
[Worker] (optional) PII Outbound filter
[Response] answer + sources, x-ai-usage-tokens (for Zuplo metering)

3.3 Compliance Checker Pipeline

Client POST { topic, tenantId } → Vectorize global-statutory + tenant filter → Workers AI comparison → CRITICAL / WARNING / COMPLIANT + rationale.

3.4 PII Filter Placement

  • Inbound: Mask NRIC/FIN etc. immediately before question reaches Workers AI / RAG.
  • Outbound: Mask again immediately before AI response goes to client.
  • Zero-Log: Original (pre-mask) only in memory; not logged.
  • Extension: Zuplo Outbound Policy for full response scan, DLP, de-identified audit logs.

4. Module Requirements (Summary)

  • Data Ingestion: Multipart PDF, x-tenant-id required; R2 temp path by tenant; WASM PDF extraction; chunking (e.g. 512 tokens); Workers AI embedding; Vectorize upsert with tenantId/source/content/page; delete R2 temp on success.
  • RAG Query: JSON { question }, x-tenant-id; always filter: { tenantId } on Vectorize; topK 3–5; system prompt for context-only answers and no hallucination; response: answer, sources, x-ai-usage-tokens.
  • Compliance Checker: JSON { topic, tenantId }; Vectorize global-statutory + tenant filter; Workers AI → CRITICAL/WARNING/COMPLIANT + reason.
  • PII Filter: NRIC/FIN with regex + checksum; Inbound + Outbound; fixed mask token; Zero-Log; optional Zuplo Guardrail.

5. UI/UX

  • Prego AI Assistant: Context-aware (e.g. “my leave balance” + employee + policy); source transparency; streaming (typing effect); chat history in D1, 7-day auto-deletion.
  • Onboarding: Expose AI assistant at end of onboarding; Compliance results (CRITICAL/WARNING) in admin only.

6. Security and Compliance

  • Tenant isolation: Every Vectorize query uses filter: { tenantId }; R2 paths with tenantId prefix; Worker-only access.
  • PDPA: R2 temp files deleted after processing; chat retention then auto-delete; PII edge-only, Zero-Log.
  • Zuplo: PII Outbound Policy; API metering (tokens → Stripe usage_record).
  • Cost: Chunk dedup, topK 3–5, R2 temp delete, x-ai-usage-tokens for accurate billing.

7. Deployment and Infra

  • Layout: e.g. workers/rag-ingestion, rag-query, compliance-checker, shared PII util; wrangler.toml with AI, VECTORIZE, D1, R2_BUCKET, vars/secrets.
  • Deploy order: (1) Pulumi D1·Vectorize·R2·token → wrangler; (2) D1 migrations; (3) Ingest global-statutory; (4) Workers Ingestion → Query → Compliance → PII; (5) Zuplo policies and upstreams; (6) Frontend + streaming.

8. Implementation Order and Phase

PhaseContentDeps
P0Vectorize·D1·R2 provisioning, wrangler bindings
P1Data Ingestion (PDF → text → chunk → embed → Vectorize), R2 temp store·deleteP0
P2RAG Query (question → embed → Vectorize + tenant filter → LLM → response), sources·tokensP0, P1
P3PII Filter Inbound/Outbound, NRIC/FIN checksum·mask, Zero-LogP2
P4Compliance Checker (global-statutory + tenant cross-check)P0, P1
P5Zuplo metering·PII Outbound, Stripe usage_recordP2, P3
P6UI: AI chat, context-aware, sources, streaming, history D1·7-day deleteP2, P5

§§9–19 (verification checklist, open items, API summary, D1·Vectorize schema, limits·errors, PDF extraction options, streaming format, tenant·onboarding, monitoring, glossary, related plans) — full tables, API contract, schema, edge limits, and retry policy are in the Korean section below.


한국어 {#korean}

Worker AI 구현 기획서

목적: Prego의 핵심 지식 기반을 구축·활용하기 위한 Edge-Native Worker AI 구현 범위·요구사항·아키텍처를 정의한다. 코드 생성 없음 — 기획·명세만 포함.

문서 버전: 1.0

참조: rag-ai-edge-architecture-plan.md, rag-ai-phase1-implementation-plan.md, zuplo-ai-metering-policy.md.

문서 목차: §1 목적·범위 · §2 전제·참조 · §3 아키텍처 개요 · §4 모듈별 요구사항 · §5 UI/UX · §6 보안·컴플라이언스 · §7 배포·인프라 · §8 구현 순서·Phase · §9 검증 체크리스트 · §10 미결정 · §11 API 인터페이스 · §12 D1·Vectorize 스키마 · §13 제한·에러 · §14 PDF 추출 옵션 · §15 스트리밍·응답 · §16 테넌트·온보딩 연동 · §17 모니터링·운영 · §18 용어·약어 · §19 관련 기획서.

구현 시 권장 읽기 순서: §8(Phase·산출물) → §11(API) → §12(스키마) → §4(모듈 요구사항) → §7(배포). 배포 전 §9 검증·§13 제한·§13.1 에지 제약 확인.


1. 목적·범위

1.1 목적

  • Edge-Native Data Ingestion: PDF 등 문서 업로드 → 텍스트 추출 → 청킹 → 임베딩 → Vectorize 저장을 Cloudflare 엣지에서 일괄 처리.
  • RAG Query: 사용자 질문 → 임베딩 → Vectorize 유사도 검색(테넌트 격리) → 문맥 증강 → Workers AI 답변 생성.
  • Compliance Checker: 중앙 법령(MOM) 지식과 테넌트 사내 규정을 교차 분석하여 위반/주의/준수 판정.
  • PII 보호: 질문·답변 경로에서 NRIC/FIN 등 개인식별정보를 엣지에서 이중(Inbound/Outbound) 마스킹.
  • UI/UX: Context-Aware AI 채팅, 출처 표시, 스트리밍 응답, 채팅 이력 보관·자동 파기 정책.

1.2 범위

포함제외(별도 기획)
Data Ingestion Worker, RAG Query Worker, Compliance Checker, PII Filter의 요구사항·인터페이스·파이프라인 명세실제 TypeScript/코드 구현
Vectorize·D1·R2·Workers AI 바인딩 및 배포 구조Pulumi 상세 스크립트(기존 RAG Phase1·아키텍처 문서 참조)
Zuplo 게이트웨이·메터링·PII 연동 전략Zuplo Config as Code 상세
보안·컴플라이언스(PDPA, 테넌트 격리) 원칙감사 로그 스키마 상세

2. 전제·참조 문서


3. 아키텍처 개요

3.1 Data Ingestion 파이프라인

[클라이언트] PDF 업로드 (Multipart Form)
[Worker] R2 임시 저장 (감사·재처리용, tenant prefix)
[Worker] 텍스트 추출 (엣지 가능: WASM 기반 PDF 라이브러리)
[Worker] 청킹 (예: 512 토큰 단위, 중복/공백 정리로 비용 절감)
[Worker] Workers AI 임베딩 (동일 모델: bge-small-en-v1.5)
[Vectorize] upsert (id, values, metadata: tenantId, source, content, page)
[Worker] 완료 후 R2 임시 객체 파기 (PDPA 보관 제한)

3.2 RAG Query 파이프라인

[클라이언트] POST { question } + x-tenant-id
[Worker] (선택) PII Inbound 필터
[Worker] 질문 임베딩 (Ingestion과 동일 모델)
[Vectorize] query(vector, topK, filter: { tenantId }, returnMetadata: true)
[Worker] Context 조립 (상위 K개 청크, 출처 메타 포함)
[Workers AI] 시스템 프롬프트 + Context + Question → 답변 (할루시네이션 방지 지침)
[Worker] (선택) PII Outbound 필터
[응답] answer + sources (출처 목록), x-ai-usage-tokens (Zuplo 메터링용)

3.3 Compliance Checker 파이프라인

[클라이언트] POST { topic, tenantId }
[Vectorize] 중앙 법령(MOM) 검색 (namespace: global-statutory, topK)
[Vectorize] 테넌트 사내 규정 검색 (filter: { tenantId }, topK)
[Workers AI] 두 문맥 비교 → CRITICAL / WARNING / COMPLIANT + 이유
[응답] analysis

3.4 PII Filter 위치

  • Inbound: 사용자 질문이 Workers AI·RAG 검색으로 넘어가기 직전에 NRIC/FIN 등 마스킹.
  • Outbound: AI 생성 답변이 클라이언트로 나가기 직전에 한 번 더 마스킹.
  • Zero-Log: 마스킹 전 원본은 메모리에서만 처리, 로그에는 남기지 않음.
  • 확장: Zuplo Outbound Policy로 응답 전수 검사·DLP·비식별 감사 로그 가능.

4. 모듈별 요구사항

4.1 Data Ingestion Worker

항목요구사항
트리거Multipart Form으로 PDF 업로드. x-tenant-id 헤더 필수.
저장원본을 R2 temp/{tenantId}/{timestamp}-{filename}에 임시 저장 후, 처리 완료 시 삭제(PDPA).
텍스트 추출WASM 호환 PDF 라이브러리 사용. Node 전용 라이브러리는 Worker 미지원.
메모리Worker 메모리 제한(예: 128MB) 고려. 대용량 PDF는 스트리밍 또는 세그먼트 단위 처리 검토.
청킹고정 토큰 수(예: 512) 또는 문자 수 단위. 중복·과도한 공백 제거로 임베딩 비용 최소화.
임베딩Workers AI @cf/baai/bge-small-en-v1.5. Ingestion·Query 동일 모델 유지.
Vectorizeupsert 시 metadata: tenantId, source(파일명), content(청크 원문), page(또는 chunk index). 검색 시 tenantId 필터 필수.
응답success, chunks 개수, 임시 파일 파기 완료 메시지.

4.2 RAG Query Worker

항목요구사항
입력JSON body { question }, 헤더 x-tenant-id.
테넌트 격리VECTORIZE.query 시 반드시 filter: { tenantId } 적용. 타 테넌트 데이터 유출 금지.
Top-K3~5개 청크 권장. 과다 시 토큰 비용·혼동 증가.
시스템 프롬프트Context 기반 답변, Context에 없으면 “해당 정보를 찾을 수 없습니다” 응답, 할루시네이션 금지 명시.
출처응답에 sources(문서명·페이지 등) 포함해 사용자가 검증 가능하도록.
메터링응답에 x-ai-usage-tokens(또는 동일 스펙) 포함. Zuplo Post-proc에서 D1·Stripe 연동.

4.3 Compliance Checker

항목요구사항
입력JSON { topic, tenantId }. 주제(예: 연차, 초과수당)와 테넌트.
지식 소스(1) Vectorize global-statutory namespace — 중앙 MOM 법령. (2) Vectorize tenant filter — 해당 테넌트 사내 규정.
분석Workers AI에 두 문맥 전달, “위반/주의/준수” 판정 및 이유 생성. 출력: CRITICAL / WARNING / COMPLIANT.
역할온보딩·정책 등록 시 실시간 검증, 엔터프라이즈 HR 법적 리스크 관리 셀링 포인트.

4.4 Edge-side PII Filter

  • 선택 연동: RAG 엣지 아키텍처 rag-ai-edge-architecture-plan.md §2.1의 Guardrail(질의·응답 전후 검사)을 Query Worker 전후에 두어, PII 필터와 함께 이중 검사로 활용할 수 있다.
항목요구사항
대상NRIC/FIN 등 싱가포르 개인식별정보. 정규식 + 체크섬 검증으로 유효 번호만 마스킹(오탐 감소).
위치Inbound(질문), Outbound(답변). AI 요청/응답 경로 양단.
형식마스킹 시 [CONFIDENTIAL_ID_MASKED] 또는 [REDACTED_NRIC] 등 고정 토큰으로 치환.
시스템 지침LLM 프롬프트에 “실명·NRIC를 답변에 포함하지 마라” 지침 추가해 필터와 상호보완.
PDPA보호 의무 이행 근거로 정책·감사에 활용.

5. UI/UX 요구사항

5.1 Prego AI Assistant (채팅)

항목요구사항
Context-Aware”내 연차는 몇 일이야?” 등 질문 시, 이미 알고 있는 직원 정보(입사일 등)와 사내 규정을 결합해 개인화 답변.
Source Transparency답변 하단에 “출처: 사내 복지 규정 제4조” 등 표기. 신뢰도·검증 가능성.
StreamingWorkers AI 스트리밍 응답으로 한 글자씩 타이핑 효과(UX).
스택 제안Frontend: React + Tailwind. 채팅 이력: D1 저장, 7일 후 자동 파기 정책.

5.2 온보딩 연동

  • 온보딩 마지막 단계에서 신규 입사자 대상 AI 비서 노출.
  • Compliance Checker 결과(CRITICAL/WARNING)는 관리자 대시에서만 노출하는 등 권한 분리.

6. 보안·컴플라이언스

6.1 테넌트 격리

  • Vectorize: 모든 query에 filter: { tenantId } 적용. namespace 또는 metadata 필터로 타 테넌트 미접근.
  • R2: 경로에 tenantId prefix. Worker만 접근, 클라이언트 직접 접근 없음.

6.2 PDPA·데이터 최소화

  • R2 임시 파일: 처리 완료 후 즉시 삭제.
  • 채팅 이력: 보관 기간(예: 7일) 후 자동 파기.
  • PII: 엣지에서만 처리, 로그 비저장(Zero-Log).

6.3 Zuplo 연동

  • PII Filter: 게이트웨이 Outbound Policy로 응답 전수 검사·마스킹·비식별 감사 로그.
  • API Metering: Query 1회당 토큰량 측정 → Stripe usage_record 전송.

6.4 비용·최적화 원칙

  • Ingestion: 청킹 시 중복·과도한 공백 제거로 임베딩 토큰 최소화. 동일 문서 재업로드 시 기존 벡터 덮어쓰기(id 정책)로 중복 축적 방지.
  • Query: topK 3~5 유지, Context 길이 제한으로 LLM 토큰 비용·지연 제어.
  • R2: 임시 파일 처리 완료 후 즉시 삭제해 저장 비용·PDPA 준수.
  • 메터링: x-ai-usage-tokens로 실제 사용량만 Stripe에 전송해 과금 정확도 유지.

7. 배포·인프라

7.1 폴더 구조 (참조)

Prego/
├── app/ # Cloudflare Pages (Frontend + API Functions)
│ ├── src/ # React UI (온보딩 위저드, AI 채팅)
│ └── functions/ # API (D1, Stripe Webhook, RAG Query 등)
├── workers/ # 전용 Worker 진입점 (또는 app/functions 내 라우팅)
│ ├── rag-ingestion/ # Data Ingestion
│ ├── rag-query/ # RAG Query
│ ├── compliance-checker/ # Compliance Checker
│ └── (공통) pii-filter # 유틸 또는 미들웨어
├── infra/ # Pulumi
├── zuplo/ # Zuplo 설정
├── wrangler.toml # AI, Vectorize, D1, R2 바인딩
└── package.json

7.2 Wrangler 바인딩 (요약)

바인딩용도
AIWorkers AI (임베딩, Llama 등).
VECTORIZEprego-hr-knowledge-base (또는 Pulumi에서 생성한 인덱스).
D1prego_hr_master_db (테넌트·설정·사용량·채팅 메타).
R2_BUCKET임시 업로드·원본 보관(경로 정책에 따라).
varsSTRIPE_WEBHOOK_SECRET, ZUPLO_API_URL 등(비밀은 Secret).

7.3 배포 순서(권장)

  1. 인프라: Pulumi로 D1·Vectorize·R2·API Token 생성 → wrangler.toml 반영.
  2. D1: RAG·테넌트 AI 설정·사용량·채팅 테이블 마이그레이션.
  3. 지식 베이스: 중앙 MOM 데이터를 global-statutory namespace에 Ingestion.
  4. Workers: Ingestion → Query → Compliance Checker → PII 유틸 순 구현·배포.
  5. Zuplo: PII Policy·Metering Policy 활성화, Worker URL 업스트림 등록.
  6. Frontend: Pages 배포, AI 채팅 컴포넌트·스트리밍 연동.

8. 구현 순서·Phase

Phase내용의존
P0Vectorize·D1·R2 프로비저닝, wrangler 바인딩
P1Data Ingestion Worker (PDF → 텍스트 → 청킹 → 임베딩 → Vectorize), R2 임시 저장·파기P0
P2RAG Query Worker (질문 → 임베딩 → Vectorize query + tenant filter → LLM → 응답), sources·토큰 메타P0, P1
P3PII Filter (Inbound/Outbound), NRIC/FIN 체크섬·마스킹, Zero-LogP2
P4Compliance Checker (global-statutory + tenant 규정 교차 분석)P0, P1
P5Zuplo 메터링·PII Outbound Policy, Stripe usage_recordP2, P3
P6UI: AI 채팅 컴포넌트, Context-Aware, 출처 표시, 스트리밍, 이력 D1·7일 파기P2, P5

8.1 Phase별 산출물 요약

Phase산출물·엔드포인트비고
P0Vectorize 인덱스, D1 DB, R2 버킷, wrangler 바인딩Pulumi 또는 대시보드, 인덱스 이름·DB ID 확정
P1POST Ingestion API, R2 temp 경로, Vectorize upsert(tenantId 메타)PDF → 청킹 → 임베딩 → 저장, R2 임시 삭제
P2POST RAG Query API, answer·sources, x-ai-usage-tokensVectorize filter: tenantId, Workers AI LLM
P3PII 마스킹 유틸, Inbound(질문)·Outbound(답변) 적용NRIC/FIN 체크섬·Zero-Log
P4POST Compliance Checker API, analysis (CRITICAL/WARNING/COMPLIANT)global-statutory + tenant 규정 교차 분석
P5Zuplo Quota Inbound, 사용량 Outbound, Stripe usage_recordD1 tenant_ai_usage_daily, PII Outbound Policy
P6AI 채팅 UI, 스트리밍 답변, 출처 표시, chat_history D1·7일 파기Context-Aware, 플랜별 노출

9. 검증 체크리스트

  • Ingestion: PDF 업로드 → R2 임시 저장 → Vectorize 해당 tenant 메타데이터로 벡터 존재 → R2 임시 삭제.
  • Query: x-tenant-id 별로 검색 결과가 해당 테넌트만 포함하는지 확인. filter 미적용 시 타 테넌트 노출 없음.
  • PII: 질문/답변에 NRIC 형식 입력 시 마스킹 토큰으로 치환, 로그에 원문 없음.
  • Compliance: topic·tenantId 입력 시 CRITICAL/WARNING/COMPLIANT 중 하나와 이유 반환.
  • Zuplo: Quota 초과 시 429, 정상 시 토큰 수 집계·Stripe(테스트) usage_record 전송.
  • End-to-end: 온보딩 플로우에서 AI 질의 → 스트리밍 답변 → 출처 표시.

9.1 테스트 전략 요약

수준대상요점
단위청킹 유틸, PII 마스킹 함수경계·공백·NRIC 패턴·체크섬, 오탐 없음.
통합Vectorize query + filtertenantId 필터 시 타 테넌트 벡터 미반환, returnMetadata 검증.
통합Ingestion → Vectorize upsertR2 저장·삭제, 메타데이터(tenantId, source, content) 일치.
E2EIngestion → Query → 답변PDF 업로드 후 동일 tenant로 질의 시 해당 문서 출처 포함.
보안테넌트 격리A tenant로 upsert한 벡터를 B tenant query에서 조회 불가.
보안PII질문/답변에 NRIC 포함 시 마스킹된 값만 로그·AI 입력에 노출.

10. 미결정·후속 검토

항목설명
PDF 라이브러리WASM 호환 PDF 텍스트 추출 라이브러리 선정(예: pdf-parse WASM 포트, Cloudflare 문서 이해 API 등).
대용량 PDF단일 Worker 실행 시간·메모리 제한 내에서 처리할 수 있는 페이지 수 상한, 초과 시 큐·청크 단위 비동기 처리 여부.
Vectorize namespace단일 인덱스 + metadata filter vs namespace(tenant_id) 사용 방식 최종 결정(기존 RAG 기획서와 정합성).
Compliance 인덱스global-statutory 인덱스/네임스페이스 구축 주체(Prego 운영팀 vs 고객별)·업데이트 주기.
채팅 이력 스키마D1 테이블 설계(tenant_id, user_id, message role/content, created_at, ttl 또는 삭제 job).
다국어지원 언어(영어·중국어 등), 다국어 임베딩 모델(bge 다국어 버전 등) 선정 및 Query/Ingestion 동일 모델 유지.

11. API 인터페이스 요약

엔드포인트메서드요청응답·헤더비고
IngestionPOSTMultipart: file(PDF), 헤더 x-tenant-id200: { success, chunks, message } / 400: Missing Tenant ID, No file / 500: Ingestion failedZuplo 인증·Quota 적용
RAG QueryPOSTJSON { question }, 헤더 x-tenant-id200: { answer, sources }, 헤더 x-ai-usage-tokens / 400: Invalid request / 500: AI Processing ErrorZuplo 메터링이 토큰 수 수집
Compliance CheckerPOSTJSON { topic, tenantId }200: { analysis } (CRITICAL/WARNING/COMPLIANT + 이유) / 400, 500관리자 또는 온보딩 플로우
  • 모든 API는 Zuplo 게이트웨이 뒤에 배치하며, 테넌트 식별은 API Key → tenant_id 매핑으로 수행.

12. D1·Vectorize 스키마 요약

12.1 D1 (참조: RAG Phase1·기존 마이그레이션)

테이블용도주요 필드(예)
tenant_ai_settings테넌트별 RAG·Quota 설정tenant_id, vectorize_namespace(또는 filter용 tenantId), quota_daily, quota_monthly, stripe_subscription_item_id
tenant_ai_usage_daily일별 AI 사용량tenant_id, dt, tokens_used (Zuplo Post-proc에서 upsert)
chat_history (미결정)채팅 이력·7일 파기tenant_id, user_id, role(user/assistant), content, created_at. TTL 또는 Cron 삭제 job.

12.2 Vectorize 인덱스

항목내용
Presetcf-baai-bge-small-en-v1.5 (Ingestion·Query 동일).
MetadatatenantId(필수), source(파일명), content(청크 원문), page 또는 chunk_index. Compliance용 global-statutory는 namespace 또는 metadata로 구분.
격리쿼리 시 반드시 filter: { tenantId } 또는 namespace 지정.

13. 제한·에러 처리

구분정책응답
Ingestion파일 크기 상한(예: 10MB), 허용 MIME: application/pdf. 초과·비허용 시 400.400: No file / File too large / Unsupported type
IngestionWorker CPU/메모리·실행 시간 초과 시 500, 클라이언트 재시도 또는 청크 단위 비동기 설계 검토.500: Ingestion failed
QueryZuplo에서 일/월 Quota 초과 시 429.429: Quota exceeded
Queryquestion 누락·tenantId 누락 시 400.400: Invalid request
Compliancetopic·tenantId 누락 시 400.400
공통AI·Vectorize·D1 일시 오류 시 500, 재시도 가능 메시지.500: AI Processing Error 등

13.1 에지 제약·한도 요약

구현 시 Cloudflare 제품 한도를 고려해 설계·폴백을 두는 것이 좋다. (수치는 공식 문서 기준으로 배포 전 재확인.)

구분항목참고
WorkerCPU 시간·메모리(예: 128MB)·실행 시간 상한대용량 PDF는 세그먼트/스트리밍 또는 청크 단위 비동기 처리 검토.
Vectorize인덱스당 벡터 수·차원 수·메타데이터 크기preset bge-small-en-v1.5 차원과 동일한 인덱스 생성.
Workers AI요청당 토큰 한도·동시 호출스트리밍·배치 크기 조절로 초과 방지.
R2업로드 객체 크기·요청 한도Ingestion 파일 크기 상한(§13)과 연동.
D1행 수·쿼리 시간·바인딩 수tenant_ai_usage_daily 등 집계 테이블 주기 정리·인덱스 설계.

13.2 클라이언트 재시도·Ingestion 실패 시 정책

  • 429(Quota) / 503·500(일시 오류): 클라이언트는 exponential backoff로 재시도. 429는 Quota 갱신 전까지 재시도해도 동일 응답 가능.
  • Ingestion 500: Worker 내부에서 예외 발생 시, R2 임시 파일을 유지할지 즉시 삭제할지 정책 결정. 유지 시 같은 키로 재요청 시 재처리 가능; 삭제 시 PDPA·용량 우선. 구현 시 try/finally에서 성공 시에만 삭제하는 패턴 권장.

14. PDF·텍스트 추출 옵션

옵션설명비고
Workers AI 문서 이해Cloudflare Workers AI에 문서 이해 API가 있는 경우, 엣지에서 PDF → 텍스트 호출. 공식 지원 여부·한도 확인 필요.엣지 네이티브, Node 의존 없음.
WASM PDF 라이브러리pdf.js(Mozilla), pdf-parse의 WASM 포트 등 Worker 호환 빌드. Worker 런타임에서 import 가능한지 검증 필요.메모리·실행 시간 제한 내에서 페이지 수 상한 결정.
외부 서비스PDF 추출만 별도 서비스(Lambda·전용 API)로 두고, Worker는 텍스트 수신 후 청킹·임베딩만 수행.엣지 풀 스택에서 벗어남, 보안·지연 고려.
  • 구현 Phase에서 WASM 호환 여부·벤치마크 후 선정 권장.

15. 스트리밍·응답 형식

항목요구사항
프로토콜Workers AI 스트리밍 응답을 클라이언트에 전달할 방식(SSE, ReadableStream 등) 결정. Zuplo가 스트리밍을 그대로 프록시하는지 확인.
토큰 단위답변을 한 글자/토큰 단위로 전송해 UI에서 타이핑 효과 구현. 최종 토큰 수는 스트림 종료 후 헤더 또는 마지막 이벤트로 전달해 메터링에 사용.
에러스트리밍 중 AI/네트워크 오류 시 클라이언트가 부분 응답·에러 구분 가능하도록 이벤트 형식 정의.
출처스트리밍이 끝난 뒤 sources 배열을 한 번에 반환하거나, 스트림 메타 이벤트로 전달.

16. 테넌트·온보딩 연동

항목요구사항
테넌트 프로비저닝신규 테넌트 생성 시 D1 tenant_ai_settings 초기화(quota, stripe_subscription_item_id). Vectorize는 단일 인덱스 + metadata tenantId로 격리하므로 별도 리소스 생성 불필요.
AI 활성화 조건플랜별로 RAG AI 사용 여부·일/월 Quota 차등. 온보딩 완료 또는 첫 로그인 시 AI 채팅 노출 여부는 tenant_ai_settings·플랜 조인으로 판단.
온보딩 플로우마지막 단계에서 Prego AI Assistant 진입. 필요 시 Compliance Checker 결과(CRITICAL/WARNING)는 관리자 화면에서만 노출.
지식 베이스 초기화테넌트별로 사내 규정 PDF를 업로드·Ingestion 호출. 중앙 MOM 데이터(global-statutory)는 운영팀이 사전 Ingestion.

17. 모니터링·운영

항목요구사항
로그Worker 내부 로그는 비식별화(tenant_id는 가능, PII·원문 미포함). Cloudflare Workers Analytics·Logpush 연동 검토.
알림Ingestion 실패율 상승, Quota 임계 도달(예: 80%), Vectorize/D1 오류율 증가 시 알림 채널(Slack·이메일) 연동.
메터링 검증Zuplo → D1 usage 누적·Stripe usage_record 전송이 주기적으로 일치하는지 대시보드 또는 수동 검증.
용량Vectorize 인덱스 크기·R2 버킷 용량·D1 행 수 모니터링, 플랜별 상한과 연동.

18. 용어·약어

용어설명
RAGRetrieval-Augmented Generation. 검색(벡터 유사도)으로 문맥을 가져와 LLM 답변을 보강하는 방식.
VectorizeCloudflare 벡터 인덱스 서비스. 임베딩 벡터 저장·유사도 검색, 메타데이터 필터·namespace 지원.
PDPAPersonal Data Protection Act. 싱가포르 개인정보보호법. 보관 제한·동의·파기 의무 등.
MOMMinistry of Manpower. 싱가포르 노동부. 노동법·법령 지식 베이스(global-statutory)의 출처.
NRIC/FINNational Registration Identity Card / Foreign Identification Number. 싱가포르 개인식별번호. PII 필터 대상.
PIIPersonally Identifiable Information. 개인식별정보.
topK벡터 검색 시 가져올 유사도 상위 K개 문서(청크). 보통 3~5.
namespaceVectorize 내 논리 구분. 단일 인덱스에서 tenant_id 또는 global-statutory 등으로 격리.
Ingestion문서 업로드 → 텍스트 추출 → 청킹 → 임베딩 → Vectorize 저장까지의 파이프라인.
WASMWebAssembly. Worker 런타임에서 Node 전용 라이브러리 대신 사용하는 PDF 등 처리용.

19. 관련 기획서

Help