playfetch

기타 소스코드

v1.0

다운로드

플레이페치

PlayFetch를 사용하면 앱에 대규모 언어 모델 기능을 빠르고 쉽게 추가할 수 있습니다.

배경

LLM은 제품 팀의 작업 방식을 변경했습니다. 이제 점점 더 많은 애플리케이션이 자연어를 사용하여 구축되고 있습니다. 이 프로세스에는 엔지니어링 팀 구성원이 아닌 경우가 많습니다. 생성된 텍스트의 톤과 전달에 관심을 갖는 콘텐츠 전략가, 생성된 콘텐츠에 고도로 전문화된 지식을 제공하는 도메인 전문가, 그들의 제품 요구 사항. 엔지니어링 팀과 함께 애플리케이션의 중요한 부분을 프로토타입화, 개발 및 유지 관리하는 새로운 팀 구성원과 함께 많은 새로운 상호 작용이 가능해졌습니다.

엔지니어와 나머지 팀원 간의 이러한 새로운 상호 작용에는 새로운 도구가 필요합니다. 엔지니어는 새로운 버전이 실제로 더 좋지 않다는 것을 발견하기 위해 지속적인 업데이트 요청으로 코드 베이스 전체에 일반 텍스트가 배포되는 것을 원하지 않습니다. 프롬프트나 체인의 기여자는 엔지니어가 업데이트를 통합할 때까지 기다렸다가 예상대로 작동하지 않는다는 사실을 발견하기를 원하지 않습니다. PlayFetch는 이러한 방식으로 작업하는 회사에서 관찰한 이러한 문제점과 기타 여러 문제점을 해결합니다.

PlayFetch란 무엇입니까?

댓글, 주석, 라벨, 평가를 통한 협업을 중심으로 구축된 직관적인 프롬프트 플레이그라운드입니다.
모든 팀원이 투명하게 사용할 수 있는 비파괴 버전 관리 시스템입니다.
데이터 가져오기 및 내보내기, 측정 체인, 자동화된 채팅 봇 테스트를 갖춘 테스트 환경입니다.
소스 제어, 프로젝트 관리 및 벡터 저장소용 도구와 원활하게 통합되는 LLM 플랫폼입니다.
간단한 통화, 채팅 및 수동 중단을 지원하는 간단한 통합 API를 갖춘 모델에 구애받지 않는 호스팅 솔루션입니다.
LLM 기능 요구 사항에 초점을 맞춘 분석 및 모니터링 솔루션입니다.

Google Cloud에 PlayFetch 배포

PlayFetch는 Google Cloud Platform에서 실행되도록 최적화되었습니다. 자신만의 인스턴스를 시작하고 실행하려면 아래 지침을 따르세요. https://github.com/yello-xyz/playfetch에서 공식 PlayFetch 저장소를 포크했다고 가정합니다(지속적인 통합을 설정할 수 있도록). 코드를 변경하려는 경우 이러한 지침을 여러 번 실행하여 개발, 스테이징 및 프로덕션을 위한 별도의 인스턴스를 설정할 수 있습니다.

새 프로젝트 구성

https://cloud.google.com/에서 Google Cloud Platform 계정을 설정하세요.
https://console.cloud.google.com에서 Cloud Console에 액세스하세요.
IAM 및 관리자 → 리소스 관리 로 이동하여 프로젝트 생성을 클릭합니다.
고유한 이름(나중에 변경할 수 없음)을 선택하고 CREATE 를 클릭합니다.
결제 로 이동하고 계정 관리 아래에서 새 프로젝트에 대해 결제가 활성화되어 있는지 확인하세요.

API 구성

API 및 서비스 → 활성화된 API 및 서비스 로 이동합니다.
상단의 프로젝트 선택기에서 새로 생성된 프로젝트가 선택되어 있는지 확인하세요.
API 및 서비스 활성화를 클릭합니다.
App Engine Admin API를 검색하고 활성화를 클릭합니다.
Cloud Build API 를 검색하고 활성화를 클릭합니다.
Cloud Datastore API 를 검색하고 활성화를 클릭합니다.
Cloud Scheduler API 를 검색하고 활성화를 클릭합니다.
Google App Engine 가변형 환경을 검색하고 활성화를 클릭합니다.
IAM(Identity and Access Management) API를 검색하고 활성화를 클릭합니다.
Vertex AI API를 검색하고 ENABLE 을 클릭합니다.

App Engine 애플리케이션 구성

App Engine → 대시보드 로 이동하여 애플리케이션 만들기를 클릭합니다.
위치를 선택하세요(나중에 변경할 수 없음).
서비스 계정 옵션을 열어두고(기본값 사용) NEXT 를 클릭합니다.
배포 패널을 무시합니다( I'LL DO THIS LATER 클릭).

데이터스토어 구성

데이터 저장소 로 이동합니다.
(기본) 데이터 저장소가 표시되지 않으면 잠시 기다렸다가 새로 고치십시오.
(기본) 데이터 저장소를 선택합니다.
사이드바에서 TTL(Time-to-Live)을 선택하고 정책 생성을 클릭합니다.
Kind를 _nextauth_token 으로 설정하고 Timestamp 속성을 만료 되도록 설정하고 CREATE를 클릭합니다.
종류 캐시 및 ExpiresAt 속성을 사용하여 다른 정책을 만듭니다.

스토리지 버킷 구성

Cloud Storage → 버킷 으로 이동하여 버킷 [project-name] .appspot.com 을 선택합니다.
권한 아래에서 액세스 권한 부여를 클릭합니다.
주체 allUsers를 추가하고 Storage Object Viewer 역할을 할당합니다.
저장을 클릭하고 공개 액세스 허용을 클릭합니다(이 버킷은 아바타를 저장하는 데 사용됩니다).

빌드 서비스 계정 만들기

IAM 및 관리자 → 서비스 계정 으로 이동하여 서비스 계정 만들기를 클릭합니다.
고유한 이름을 선택하고 CREATE AND CONTINUE 를 클릭하세요.
서비스 계정 사용자 역할을 선택합니다.
다른 역할 추가를 클릭하고 App Engine Deployer를 선택합니다.
다른 역할 추가를 클릭하고 App Engine 가변형 환경 서비스 에이전트를 선택합니다.
다른 역할 추가를 클릭하고 App Engine 서비스 관리자를 선택합니다.
다른 역할 추가를 클릭하고 Cloud Build 서비스 계정을 선택합니다.
다른 역할 추가를 클릭하고 Cloud Datastore Index Admin을 선택합니다.
다른 역할 추가를 클릭하고 Cloud Scheduler 관리자를 선택합니다.
계속 및 완료를 클릭합니다.

[선택사항] 맞춤 도메인 구성

App Engine → 설정 으로 이동합니다.
맞춤 도메인 아래에서 맞춤 도메인 추가를 클릭하세요.
사용하려는 맞춤 도메인과 하위 도메인을 입력합니다(소유권 확인 지침에 따라).
계속 및 완료를 클릭합니다.
사용자 지정 도메인 공급자의 DNS 구성에 표시된 레코드를 추가합니다.

[선택사항이지만 권장됨] Google OAuth 사용자 인증 구성

API 및 서비스 → OAuth 동의 화면 으로 이동합니다.
사용 사례에 따라 내부 또는 외부 사용자 유형을 선택하고 생성을 클릭합니다.
필수 필드를 입력하고 저장 및 계속을 클릭한 다음 범위 추가 또는 제거를 클릭합니다.
범위 .../auth/userinfo.profile 및 .../auth/userinfo.email 을 확인한 다음 UPDATE 및 SAVE AND CONTINUE 를 클릭하세요.
위에서 외부 사용자 유형을 선택한 경우 일부 테스트 계정을 추가할 수 있습니다(앱을 프로덕션에 게시하기 전). 첫 번째 관리 사용자에게 사용하려는 이메일 주소를 포함했는지 확인하세요. PlayFetch에서도 이러한 사용자에게 액세스 권한을 부여해야 합니다.
저장하고 계속하기를 클릭하고 대시보드로 돌아가기 를 클릭하세요.
사이드바에서 자격 증명을 선택한 다음 자격 증명 만들기 및 OAuth 클라이언트 ID를 클릭합니다.
애플리케이션 유형 으로 웹 애플리케이션을 선택하고 이름을 선택합니다.
승인된 JavaScript 원본 아래에 https:// [project-name] .appspot.com (및 사용자 정의 도메인이 있는 경우)을 추가합니다. 앱을 로컬에서 실행할 때 Google 인증도 사용하려면 http://localhost:3000 도 추가하세요.
승인된 리디렉션 URI 아래에 https:// [project-name] .appspot.com/api/auth/callback/google (및 모든 맞춤 도메인에 대한 유사한 URL)을 추가합니다. 앱을 로컬에서 실행할 때 Google 인증도 사용하려면 http://localhost:3000/api/auth/callback/google 도 추가하세요.
생성을 클릭하고 생성된 클라이언트 ID와 클라이언트 비밀번호를 복사하여 아래 빌드 트리거 설정에 사용하세요.

빌드 구성

Cloud Build → 트리거 로 이동하여 저장소 연결을 클릭합니다.
소스 GitHub(Cloud Build GitHub 앱)를 선택하고 계속을 클릭하여 저장소를 포크한 GitHub 계정을 인증합니다(팝업 창에서).
포크된 저장소를 선택하고 아래 상자를 선택한 후 CONNECT 를 클릭하세요.
트리거 생성을 클릭하세요.
빌드 이름을 선택하세요.
구성 아래에서 Cloud Build 구성 파일(yaml 또는 json)을 선택합니다.
최소 설정의 경우 ADD VARIABLE을 클릭하여 빌드 트리거( 고급 섹션)에 다음 대체 변수를 추가해야 합니다.
- _ENCRYPTION_KEY : 64 자리 16 진수로 구성된 임의의 문자열입니다.
- _NEXTAUTH_SECRET : 최소 32자의 임의 문자열입니다.
- _NEXTAUTH_URL : 인스턴스의 공개 URL입니다. 사용자 정의 도메인이 있는 경우 또는 https:// [project-name] .appspot.com 입니다 .
- _GCLOUD_STORAGE_BUCKET : 공개 액세스를 허용한 Cloud Storage 버킷의 이름(예: [project-name] .appspot.com )
- _NOREPLY_EMAIL_USER 및 _NOREPLY_EMAIL_PASSWORD : 발신 거래 이메일에 사용되는 Gmail 계정입니다. Google Workspace의 전용 계정(일반 비밀번호 사용)이거나 별도의 Gmail 계정(앱 비밀번호 사용)일 수 있습니다. 다른 이메일 제공업체를 사용해야 하는 경우 아래 지침을 참조하세요.
위에서 Google 인증을 구성한 경우 다음 변수도 추가해야 합니다.
- _GOOGLE_CLIENT_ID 및 _GOOGLE_CLIENT_SECRET : OAuth 자격 증명을 생성한 후 위에서 복사한 값입니다.
서비스 계정 아래에서 위에서 만든 서비스 계정을 선택합니다.
만들기 를 클릭하세요.
새로 생성된 트리거 옆에 있는 RUN을 클릭한 다음 RUN TRIGGER를 클릭합니다.
사이드바에서 기록을 선택하고 빌드가 성공적으로 완료되었는지 확인할 때까지 기다립니다(10~15분 정도 소요될 수 있음).

PlayFetch 환경 초기화

초기 관리자의 로그인으로 사용될 이메일 주소를 선택하세요.
브라우저를 열고 https:// [project-name] .appspot.com/api/admin/init?admin= [[email protected]] 으로 이동합니다(쿼리에서 올바른 이메일 주소를 지정해야 합니다).
이 끝점은 데이터 저장소를 초기화하는 스크립트를 실행하지만(1분 정도 걸릴 수 있음) 데이터 저장소를 다시 생성하지 않는 한 한 번만 실행할 수 있습니다.
스크립트가 완료되면 응답에 표시된 _PLAYFETCH_API_KEY 및 _PLAYFETCH_ENDPOINT_URL 값을 복사합니다.
Cloud Build → Triggers 로 이동하여 생성한 트리거를 클릭하고 위 단계에서 대체 변수 2개를 추가한 후 SAVE 를 클릭합니다.
추가된 변수를 사용하여 빌드 트리거를 다시 실행하세요. 이 빌드에서는 누락된 데이터 저장소 색인을 생성해야 할 수 있으므로 다시 완료될 때까지 기다리는 것이 가장 좋습니다.

이제 https:// [project-name] .appspot.com 으로 이동하여 첫 번째 관리자에 대해 지정한 이메일 주소로 로그인할 수 있습니다. Google 인증(구성된 경우) 또는 이메일 링크( _NOREPLY_EMAIL 변수가 올바르게 설정된 경우)를 사용할 수 있습니다. 추가 사용자에게 관리자 패널에서 액세스 권한을 부여할 수 있습니다.

PlayFetch를 로컬에서 실행

PlayFetch에 기여하거나 문제를 디버그하려면 아래 지침에 따라 로컬 컴퓨터에서 실행할 수 있습니다.

노드 및 npm 설치

최신 버전의 node 및 npm을 설치하는 가장 쉬운 방법은 최신 설치 프로그램을 실행하는 것입니다.

저장소 복제

GitHub Desktop으로 열고 로컬 디렉터리에 복제하거나 SSH를 사용하여 GitHub에 연결하고 git clone [email protected]:yello-xyz/playfetch.git 실행하세요. 이미 리포지토리를 포크한 경우 대신 해당 리포지토리를 복제할 수 있습니다.

환경 구성

앱을 로컬에서 실행하려면 로컬 .env.local 파일에 동일한 변수를 추가해야 합니다. 이 파일은 키 유출을 방지하기 위해 소스 제어에서 무시됩니다. 이는 개발 인스턴스에 대해 Google Cloud 빌드 트리거에 지정한 값과 동일할 수 있습니다(해당 키 유출 위험을 방지하기 위해 프로덕션용으로 별도의 인스턴스를 실행한다고 가정). 단, _NEXTAUTH_URL을 지정해야 합니다. 값은 http://localhost:3000입니다.

Google Cloud CLI를 설치하고 여기에 설명된 대로 초기화하면 로컬 머신에서 Google Cloud의 데이터 저장소에 액세스할 수 있습니다(다시 한번 별도의 개발 인스턴스를 실행하여 실수로 프로덕션 데이터를 손상시키거나 유출하지 않도록 가정). 다른 단계). Google 계정으로 로그인하려면 다음 명령을 실행하세요.

gcloud auth login
gcloud init
gcloud auth application-default login
gcloud init

빌드 및 실행

이제 다음 명령을 실행할 수 있습니다.

npm install
npm run build
npm run start

또는 개발 중에 다음 명령을 실행하여 빠른 새로 고침으로 디버그 빌드를 실행할 수 있습니다.

npm run dev

모든 테스트를 한 번 실행하려면 다음 안내를 따르세요.

npm run test

변경 사항을 관찰하고 관련 테스트 모음을 자동으로 다시 실행하려면 다음을 수행하세요.

npm run watch

선택적 기능

최소 설정을 확장하려면 다음 환경 변수(GCP 빌드 트리거 또는 로컬 .env.local 파일)를 구성하여 몇 가지 추가 기능을 활성화할 수 있습니다.

통합

_GITHUB_CLIENT_ID , _GITHUB_CLIENT_SECRET : GitHub OAuth 인증을 구성하는 데 사용할 수 있습니다(Google과 유사). GitHub OAuth 앱을 설정해야 합니다.
_GITHUB_APP_CLIENT_ID , _GITHUB_APP_CLIENT_SECRET , _GITHUB_APP_ID , _GITHUB_APP_PRIVATE_KEY , _NEXT_PUBLIC_GITHUB_APP_INSTALL_LINK : 소스 제어 통합을 구성하는 데 사용할 수 있습니다. GitHub 앱을 설정해야 합니다.
_LINEAR_APP_CLIENT_ID , _LINEAR_APP_CLIENT_SECRET , _LINEAR_APP_WEBHOOK_SECRET : 작업 관리 통합을 구성하는 데 사용할 수 있습니다. Linear 앱도 설정해야 합니다.
_NOTION_TOKEN, _NOTION_ONBOARDING_PAGE_ID, _NOTION_WAITLIST_PAGE_ID : 대기자 명단 등록 및 온보딩 설문조사 응답을 Notion에 자동으로 동기화하는 데 사용할 수 있습니다. Notion 앱을 설정해야 합니다.

해석학

_GOOGLE_ANALYTICS_API_SECRET , _GOOGLE_ANALYTICS_MEASUREMENT_ID : 서버 측 분석(GA4)을 구성하는 데 사용할 수 있습니다.
_NEXT_PUBLIC_GOOGLE_TAG_MANAGER_ID , _NEXT_PUBLIC_COOKIE_DOMAIN , _NEXT_PUBLIC_COOKIE_NAME : 쿠키 및 클라이언트 측 분석(Google 태그 관리자)을 구성하는 데 사용할 수 있습니다.

환경

_GOOGLE_ANALYTICS_DASHBOARD_URL , _GOOGLE_ANALYTICS_REPORTS_URL , _GOOGLE_SEARCH_CONSOLE_URL , _INTEGRATION_TEST_URL , _SERVER_LOGS_URL : 관리자 패널에 다양한 진단 링크를 추가하는 데 사용할 수 있습니다.
_NEXT_PUBLIC_DOCS_URL , _NEXT_PUBLIC_SUPPORT_EMAIL : 작업공간 및 프로젝트 사이드바에서 문서 및 지원에 대한 링크를 생성하는 데 사용할 수 있습니다.
_NOREPLY_EMAIL_HOST , _NOREPLY_EMAIL_PORT : 발신 거래 이메일에 대한 대체 이메일 공급자를 구성하는 데 사용할 수 있습니다.
_API_URL : 웹사이트와 API 간에 트래픽을 분할하는 데 사용할 수 있습니다(예: 인스턴스를 가리키는 별도의 하위 도메인이 있는 경우).