Tune POST /v1/search parameters to match your application's specific latency budgets and recall requirements.

1. Tuning Configurations by Use Case

2. Server-Side Pre-Filtering vs. Client Post-Filtering

Always apply filters (jurisdiction, doc_type, year_from/year_to, status) in the API request rather than filtering results in your application:

{
  "query": "شروط صحة عقد البيع العقاري",
  "top_k": 10,
  "filters": {
    "jurisdiction": "SA",
    "status": ["in_force"],
    "year_from": 2015
  }
}

Why Pre-Filtering Matters

• 100% Budget Utilization: Filters execute directly against search indexes before similarity ranking. The entire top_k budget is spent on valid, in-force candidates.
• Avoids Empty Candidate Sets: Post-filtering a broad query often eliminates 80% of retrieved chunks, starving your downstream application of context.

3. Bandwidth Optimization with include_text: false

When your application only needs to discover document IDs or render a table of titles:

curl -X POST https://api.dike.it.com/v1/search \
  -H "Authorization: Bearer $DIKE_API_KEY" \
  -d '{
    "query": "جرائم تقنية المعلومات",
    "top_k": 20,
    "include_text": false
  }'

• Payload Size: Reduces response size from ~25KB to under ~1.5KB.
• Zero Accuracy Impact: Retrieval scoring and cross-encoder ranking are identical; only the 800-character snippet string is omitted from the JSON payload.

4. Reading Diagnostic fusion Metrics

Every search response contains a fusion string:

• "rrf": Dense semantic vectors and sparse lexical vectors both matched corpus documents and contributed to the fused score.
• "dense": Sparse vector matching produced zero matches (common on conceptual queries with non-statutory phrasing); ranking smoothly defaulted to dense embeddings.

Next Steps

• Learn how to visualize citation relationships in Legal Graph Explorer.
• Explore resilience strategies in Production Best Practices.