Repository navigation
Feature request: pluggable / multilingual embedding model for semantic search #1112
Description
The bundled Nomic embeddings work well for English-named codebases, but many real-world codebases name their domain in another language. Ours is a Colombian accounting/POS platform: business identifiers are Spanish (procesar_retenciones_batch, comprobante, lote, proveedor), infrastructure is English.
Observed: semantic queries phrased in Spanish (e.g. "match comprobante bancario con lote de pagos") return unrelated Makefile targets with min-cosine scores around 0.12:
cli search_graph --project P --semantic-query '["match comprobante bancario con lote de pagos", "monto tolerancia fecha"]' --limit 5
# → semantic_results: deploy-everything (0.132), setup-iam (0.121), deploy-api (0.121), ... (all Makefile targets)
BM25 works fine on the same index (identifier tokens are language-agnostic), so this is specifically the embedding model.
Ask: a config option to point at an alternative local embedding model (e.g. a multilingual ONNX model such as multilingual-e5-small), or a multilingual variant of the bundled model as an install option. Even a documented "semantic search is English-only" caveat in the tool description would help agents route around it.
Activity
hiSandog commentedon Jul 16, 2026
Pluggability will need more than a model path: embedding dimension, tokenizer/pooling, normalization, query/document prefixes, and model revision all affect index compatibility. The project should store that metadata with the index and require an explicit reindex when it changes. A bilingual retrieval benchmark comparing the default and one multilingual model on both Spanish and English queries would verify the improvement without regressing existing codebases.
DeusData commentedon Jul 16, 2026
Thanks for the concrete multilingual example and the BM25 control. I have classified this as a 0.9.2-rc enhancement rather than a parsing defect: the current bundled embedding model has a capability gap, while lexical search remains available. A pluggable model path would add model-format, dimension, tokenizer, compatibility, installation-size, and local-file trust contracts, so the first step should characterize one permissively licensed multilingual candidate against the existing English benchmark and document the current limitation. No hosted embedding API or external service is in scope.
A-K-6 commentedon Oct 8, 2026
AI-assisted comment, posted by Codex on behalf of A-K-6.
I am evaluating an independent, optional local companion for the multilingual discovery use case in this issue. It uses EmbeddingGemma 2 (Apache-2.0, pinned model revision), native Rust/Candle CPU inference, and Python-standard-library CLI/MCP orchestration alongside released CBM. No modified CBM binary is needed. Graph coverage, call traces, and current source remain the verification authority; embeddings return candidate functions only.
Would you consider a documentation-only external-companion workflow first, using CBM's existing read-only CLI/MCP outputs? A small optional C adapter to a local external worker could be a later, separately agreed step, but I am not proposing Rust/Python code or new dependencies in the CBM core, a hosted API, or a change to normal installation. I read the prior discussion, C-only policy, prior-design requirement, AI disclosure, and human DCO requirement. I will not open an integration PR without your agreement.
The current development evidence is deliberately narrow: 24 self-authored English/Persian behavior questions over 48 public C functions, intended target top-five 24/24, top-one 13/24 (Persian 4/12), approximately 74 ms warmed median search wall time on one x86-64 Linux host, and approximately eight seconds for an unchanged refresh. This is not a blind benchmark, a Spanish result, superiority over an optimized CBM workflow, or evidence of coding-agent task success. It exposed Persian ranking and acquisition/refresh costs that need investigation.
I am freezing a stronger test before running retrieval: pinned public Click, Requests and hiredis revisions, independently prepared source-grounded questions/labels in English and Persian, whole-package candidate scopes, competent predeclared lexical/structural workflows and CBM's native semantic mode in full indexing mode. I will retain failures, coverage gaps, cold/warm latency, indexing/unchanged-refresh cost, cache size, and worker memory on ARM64 macOS and x86-64 Linux. I can add Spanish labels relevant to the original request, without conflating those with Persian.
The companion forbids unsafe code in its own Rust crate and bounds inputs, allocation arithmetic, inference deadlines and source reads; it serializes a shared worker, unloads it when idle, checks model/runtime identity, isolates checkout caches, and excludes stale source. Numerical dependencies and upstream C are outside that crate-level guarantee. Model weights and source caches will not be attached to the discussion. I will follow up here with frozen inputs, reproducible commands and measured results, including regressions.
Is the documentation-only boundary useful to this project, or would you prefer this remain entirely independent? I will continue evaluation while awaiting feedback. Only your maintainer response will determine the upstream scope.