一键在 Manus 中运行任何 Skill

debug-verify-benchmark

星标4

分支0

更新时间2026年1月31日 04:37

Debug, verify, and compare elix-db to industry after each plan step. Use after implementing any plan step or changing vector/store/API logic; run tests, IEx checks, and document efficiency vs Qdrant/Milvus/pgvector.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

8dazo

8dazo/elix-db

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Debug, Verify, and Benchmark

Apply after every plan step or change to vector store, search, or API.

When to Use

After implementing a step in plan/README.md
After changing ElixDb vector/store/API logic
Before marking a step "Done" in the plan

Debug

Run tests: mix test
Start IEx: iex -S mix and exercise the new APIs (create collection, upsert, search, get, delete as applicable).
Add traces if needed: Logger.debug/2 or :sys.trace for GenServer; fix failures before proceeding.

Verify

All tests pass; no new compiler warnings.
For search: add or run tests that check known vectors produce known ordering (e.g. cosine similarity order).
Acceptance criteria in the step file are checked off.

Industry Comparison

For each step, fill in the Industry comparison table in the step file:

Correctness: Behavior matches Qdrant/Milvus (collections, points, upsert, search, get, delete).
Latency: Note expected vs actual; compare to typical Qdrant/Milvus/pgvector numbers (e.g. p99 ms) when metrics exist.
Throughput: QPS if measured; document concurrency level.
Recall: For search, recall@k = 1.0 for exact k-NN; document when approximate index is added later.

Document efficiency notes at the bottom of the step: gaps, improvement ideas, and follow-up tasks.

Metrics to Capture

When implementing step 8 or ad-hoc benchmarking:

Metric	How	Use
Latency	Per-operation timing; compute mean, p50, p99	Compare to industry; track over time
QPS	Queries per second under fixed concurrency	Throughput vs Qdrant/Milvus
Recall@k	True k-NN vs returned k; fraction overlap	Search quality when ground truth exists
Memory/CPU	BEAM process stats	Resource efficiency

Store results in a simple format (e.g. JSON struct or Markdown table) under docs/benchmarks.md or script output for future comparison.

同仓库更多 Skills

同仓库

versioned-sample-uses

8dazo/elix-db

When publishing a new elix-db version or making version changes, run versioned sample use cases, collect memory/time/latency, compare to the previous version report, and update reports. Remember this workflow for releases.

2026-01-314

elixir-vector-patterns

8dazo/elix-db

Elixir patterns for vector storage and similarity search. Use when implementing GenServer-based vector store, ETS index, Nx/Scholar distance math, or supervision for a vector DB in Elixir.

2026-01-314

vector-db-elixir

8dazo/elix-db

Design and implement a vector database in Elixir. Use when building embedding storage, similarity search, k-NN retrieval, or when the user mentions vector DB, embeddings, or semantic search in Elixir.

2026-01-314

vector-db-storage

8dazo/elix-db

Storage backends and indexing for vector databases in Elixir. Use when choosing persistence, implementing exact vs approximate k-NN, or integrating pgvector, file, or ETS for vector storage.

2026-01-314

name	debug-verify-benchmark
description	Debug, verify, and compare elix-db to industry after each plan step. Use after implementing any plan step or changing vector/store/API logic; run tests, IEx checks, and document efficiency vs Qdrant/Milvus/pgvector.

Debug, Verify, and Benchmark

Apply after every plan step or change to vector store, search, or API.

When to Use

After implementing a step in plan/README.md
After changing ElixDb vector/store/API logic
Before marking a step "Done" in the plan

Debug

Run tests: mix test
Start IEx: iex -S mix and exercise the new APIs (create collection, upsert, search, get, delete as applicable).
Add traces if needed: Logger.debug/2 or :sys.trace for GenServer; fix failures before proceeding.

Verify

All tests pass; no new compiler warnings.
For search: add or run tests that check known vectors produce known ordering (e.g. cosine similarity order).
Acceptance criteria in the step file are checked off.

Industry Comparison

For each step, fill in the Industry comparison table in the step file:

Correctness: Behavior matches Qdrant/Milvus (collections, points, upsert, search, get, delete).
Latency: Note expected vs actual; compare to typical Qdrant/Milvus/pgvector numbers (e.g. p99 ms) when metrics exist.
Throughput: QPS if measured; document concurrency level.
Recall: For search, recall@k = 1.0 for exact k-NN; document when approximate index is added later.

Document efficiency notes at the bottom of the step: gaps, improvement ideas, and follow-up tasks.

Metrics to Capture

When implementing step 8 or ad-hoc benchmarking:

Metric	How	Use
Latency	Per-operation timing; compute mean, p50, p99	Compare to industry; track over time
QPS	Queries per second under fixed concurrency	Throughput vs Qdrant/Milvus
Recall@k	True k-NN vs returned k; fraction overlap	Search quality when ground truth exists
Memory/CPU	BEAM process stats	Resource efficiency

Store results in a simple format (e.g. JSON struct or Markdown table) under docs/benchmarks.md or script output for future comparison.