Skip to content

PROMPTS_HISTORY.md

Latest commit

 

History

History
47 lines (25 loc) · 2.46 KB

PROMPTS_HISTORY.md

File metadata and controls

47 lines (25 loc) · 2.46 KB

Prompt History

This file contains all user prompts (as recorded during this session), in chronological order, followed by brief suggestions for making the workflow more efficient.

  1. "use IMG_8538.jpeg as input, and get the top 5 similar images in the index, and rerank based on 0.6 threshold using the reranker."

  2. "write a script that runs end to end. It takes in an image, finds the most similar images and reranks based on threshold of 0.6. You can reuse the scripts you already wrote."

  3. "run the unit tests you generated"

  4. "can you make web front end that would call the end to end script and output the result on the site"

  5. "run the web app here to demonstrate"

  6. "stop the server"

  7. "add all my prompts to a file, and at the end suggest how I could have made this more efficient."

Suggestions to make the workflow more efficient

  • Provide a single high-level acceptance test up front: specify input image(s), expected top-k results, and which metrics to report. This lets me target implementation and tests precisely.

  • Share or pin the dataset/index location and formats early (paths, expected JSON schema). Avoids format-adaptation steps.

  • Provide a small requirements list (or requirements.txt) before running model-heavy tasks so dependencies can be installed in advance.

  • For iterative development, prefer using mock modes (mock embedding service, small FAISS index) for quick local feedback and unit tests; enable real-model runs only for final verification.

  • When requesting long-running tasks (model downloads, large tests), ask to run them asynchronously or provide permission to use cached/offline model — I used HF_HUB_OFFLINE=1 to reuse the cached CLIP model.

  • If you expect a web demo, specify whether you want a local dev server (Flask) or a containerized deployment; I can produce a minimal Dockerfile and requirements.txt to speed reproducible runs.

  • Consolidate multi-step requests into a short list of concrete deliverables (e.g., "(1) end-to-end script, (2) web UI, (3) tests run"), and indicate which component to prioritize.

  • Provide CI targets (which tests to run on each push) to avoid repeatedly running the entire test suite during early development.

If you'd like, I can:

  • Add a requirements.txt and README.md describing how to run the webapp and scripts, or
  • Create a small Dockerfile to package the app and model dependencies for reproducible demos.

Tell me which next step you prefer and I'll implement it.