aws-samples/jp-rag-sample

テスト導入の検討

Closed this issue · 3 comments

背景

  • Amazon Kendra の tokyo-region launch, GenAI ブームを期に、@ysekiy が始動したプロジェクトであるが、当時の限られた開発リソースと時間の見られるいくつかの技術的な負債が見られる
  • sample code (=勉強教材) であり、production を想定したものではないものの、品質を維持向上することには aws user にとって価値がある
  • また PR 数が増えてきており、生成系AI の発展スピードに追従するには、e2e test を導入しレビューの簡素化をしなければ、個社への技術支援を始めとする既存業務もある中で、aws japan member の review が追いつかない可能性がある

やりたいこととこのIssueのスコープ

  • 品質向上なのか、レビューの簡素化なのか、目的を整理する
  • e2e test なのか、オーケストレーター側の unit test なのかスコープを切りだす。
  • スコープを決めた上で、技術選定をし、都度 Issue を立てる

顕在化している技術負債とは?

レビューの簡素化だとすると、今時間がかかるのは、dry-run

  • amplify publish が動く
  • cognito 建つ
  • 有効なメールアドレスであることの確認
  • kendra, llm, rag option を試す

を確認しているわけで、メールの確認とか ses を建ててまで自動でやるとなると too-much 感がある。
となると、
既存環境+lambda製testerを作っておいて、PR作成→webhook →lambda→git-fetch→amplify-publish→test実施→結果をPRに追記?

検討はした。リソースが間に合っていないので、優先度が低いと判断しclose。