Improvement: Replace dummy embedding with actual OpenAI embedding call in api-service

[pragnyanramtha]

Description

The /api/v1/query endpoint uses a dummy embedding function instead of actual embeddings, making semantic search non-functional.

Location

File: backend/api-service/internal/handlers/handlers.go
Lines: 86-93, 202-219

Current Implementation

// For MVP: Placeholder for actual embedding generation
// In production, call embedding API or use local embeddings
embedding, err := qh.generateDummyEmbedding(req.Query)

The generateDummyEmbedding() function generates a deterministic but meaningless embedding based on a simple hash.

Problem

• Search results are not truly semantic
• Map iteration (for knowledgeID := range scores) doesn't preserve similarity order
• Results returned in arbitrary order despite having similarity scores

Suggested Fix

1. Call OpenAI embedding API (like ai-service does) or use local embedding model
2. Add embedding config (API key, model) to config/config.go
3. Return sorted slice from SearchSimilar() instead of map to preserve order
4. Update SearchByIDs() to maintain similarity ranking

Related Issues

• Issue Improve semantic search in /api/v1/query by using real embeddings and proper ranking #6 (already exists but closed) - this is a re-statement with more detail

Labels

enhancement, embeddings, backend, priority-high

[itsmessc]

Hi! I'd like to work on this issue.

After looking at the code, here's what I plan to do:

Replace generateDummyEmbedding() in handlers.go (lines 203–219) with a real OpenAI text-embedding-3-small call — the same model already used by the ai-service (app/llm/processor.py)
Add OpenAIAPIKey and OpenAIEmbeddingModel fields to config/config.go (currently missing entirely) so the API key and model are config-driven
Fix the map iteration ordering issue (line 105) — convert SearchSimilar() to return a sorted slice of (id, score) pairs so results respect similarity ranking
Could you please assign this to me?