평가 목표를 한 문장으로 제한
예: “내부 문서검색”이 아니라 “채팅 UI와 Agent 기본 응답 흐름을 본다”라고 적습니다.
주의: 목표가 넓으면 Lite PASS가 Standard 운영 승인처럼 오해됩니다.
작게 띄워 채팅·Agent 중심 기능만 먼저 확인하고, RAG/Connector 검증으로 과장하지 않는 평가 절차입니다.
작게 띄워 채팅·Agent 중심 기능만 먼저 확인하고, RAG/Connector 검증으로 과장하지 않는 평가 절차입니다.
예: “내부 문서검색”이 아니라 “채팅 UI와 Agent 기본 응답 흐름을 본다”라고 적습니다.
주의: 목표가 넓으면 Lite PASS가 Standard 운영 승인처럼 오해됩니다.
`git clone --depth 1 https://github.com/onyx-dot-app/onyx.git` 후 `onyx/deployment/docker_compose` 위치에서 작업합니다.
주의: 다른 디렉터리에서 compose를 실행하면 override 파일을 못 찾거나 전혀 다른 stack을 띄울 수 있습니다.
`docker compose -f docker-compose.yml -f docker-compose.onyx-lite.yml up -d`를 사용합니다.
주의: 기본 `docker compose up -d`는 Lite 평가가 아니라 Standard 계열 구성을 띄울 수 있습니다.
컨테이너가 떠도 초기화가 끝나야 `localhost:3000` 접근이 의미 있습니다.
주의: 컨테이너 Up 상태만 보고 “Onyx 사용 가능”이라고 기록하지 않습니다.
Connectors, RAG, vector DB, Redis, Celery, S3/MinIO가 검증 범위 밖인지 회의록에 적습니다.
주의: 없는 기능을 “나중에 확인”으로만 두면 PoC 결과가 과장됩니다.
채팅 UI에서 응답 생성, 파일 업로드/프로젝트/Agent knowledge 같은 Lite 포함 기능만 확인합니다.
주의: 문서 색인 품질이나 조직 권한 보존을 이 단계에서 결론내리지 않습니다.
RAG, Connector, 권한 기반 검색, 운영 안정성이 필요하면 Standard 평가로 이동한다고 결정합니다.
주의: Lite를 계속 보완해 Standard 대체물로 만들려 하지 않습니다.
아래 문서는 이 정적 lesson의 작성 근거입니다. 실제 화면 라벨이나 배포 성공은 별도 현장 검증이 필요합니다.
이 페이지는 Lite 평가 절차입니다. 실제 Onyx 인스턴스 기동 성공, 브라우저 UI 라벨, 조직별 보안 설정은 현장 환경에서 다시 확인해야 합니다.