[Bug]: Replacing BAAI/bge-large-zh-v1.5 with SiliconFlow failed

[OneKe]

Self Checks

• [x] I have searched for existing issues search for existing issues, including closed ones.
• [x] I confirm that I am using English to submit this report (Language Policy).
• [x] Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• [x] Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

1

RAGFlow image version

v0.22.1

Other environment information

Actual behavior

Expected behavior

No response

Steps to reproduce

1

Additional information

No response

[dosubot[bot]]

The failure to switch to BAAI/bge-large-zh-v1.5@SILICONFLOW is caused by two main issues:

1. Authorization error: The model must be registered in your tenant's LLM configuration with a valid API key and the factory set to SILICONFLOW. If this registration is missing or the API key is invalid, RAGFlow will reject the model as "not authorized" during binding. You can check your tenant's model list and ensure the SiliconFlow entry is present and correctly configured with the required credentials. The code enforces this check and will raise a "Model not authorized" error if the setup is incomplete or mismatched (source).

2. Vector space incompatibility: When switching embedding models, RAGFlow samples document chunks, re-embeds them with the new model, and compares the cosine similarity between old and new vectors. If the average similarity is below 0.9, the switch fails with a "vector space incompatible" error (source). Zero similarity usually means the new model is producing vectors of a different dimension or format, or the encoding failed (often due to authorization or configuration issues). For SiliconFlow, the BAAI/bge-large-zh-v1.5 model truncates input texts to 256 tokens, which can also affect compatibility (source).

Next steps:

• Double-check that BAAI/bge-large-zh-v1.5@SILICONFLOW is registered in your tenant's LLM config with a valid SiliconFlow API key.
• Make sure the model name and factory match exactly what RAGFlow expects.
• If you fix the authorization, but still see zero similarity, confirm that the new model produces vectors of the same dimension as your previous model.

If you need to diagnose further, try enabling more detailed logs during the binding and embedding check process to catch any encoding or API errors.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[OneKe]

@yingfeng @KevinHuSh It's urgent.

[OneKe]

ERROR 38 Fail to bind embedding model: Model(BAAI/bge-large-zh-v1.5@BAAI@None) not authorized Traceback (most recent call last): File "/ragflow/rag/svr/task_executor.py", line 790, in do_handle_task embedding_model = LLMBundle(task_tenant_id, LLMType.EMBEDDING, llm_name=task_embedding_id, lang=task_language) File "/ragflow/api/db/services/llm_service.py", line 82, in init super().init(tenant_id, llm_type, llm_name, lang, **kwargs) File "/ragflow/api/db/services/tenant_llm_service.py", line 252, in init self.mdl = TenantLLMService.model_instance(tenant_id, llm_type, llm_name, lang=lang, **kwargs) File "/ragflow/.venv/lib/python3.10/site-packages/peewee.py", line 3128, in inner return fn(*args, **kwargs) File "/ragflow/api/db/services/tenant_llm_service.py", line 132, in model_instance model_config = TenantLLMService.get_model_config(tenant_id, llm_type, llm_name) File "/ragflow/.venv/lib/python3.10/site-packages/peewee.py", line 3128, in inner return fn(*args, **kwargs) File "/ragflow/api/db/services/tenant_llm_service.py", line 120, in get_model_config raise LookupError(f"Model({mdlnm}@{fid}) not authorized") LookupError: Model(BAAI/bge-large-zh-v1.5@BAAI@None) not authorized

[KevinHuSh]

The switching of embedding model faild since the simmilarity score between those 2 models is below threashold. My suggestion is to add the siliconflow API key again. My guess is that the API key is not valid.

[OneKe]

@KevinHuSh I once doubted this issue too, but tests have confirmed that the key is valid.

[yongtenglei]

Hi, @OneKe

Did you make any modification by own? A valid model form is model_name + @ + factory_name, but your model is something like model_name@factory_name@None, that is malformed. Could you please have a check of it? Let me know.

Cheers.

[OneKe]

@yongtenglei It was deployed directly using the mirror image, not via the source code, and no modifications were made.

[yongtenglei]

Hi, @OneKe

I can configure and use this model correctly.

I suspect there might be an issue with your database, it was corrupt maybe, but I can't investigate further without more details because I cannot reproduce the problem. This is a bit unusual.

I am here and please send me more details so that I can figure this issue out.

Cheers.

[OneKe]

@yongtenglei operation process: Before replacing the embedding model, I first selected all files, clicked "Re-parse", then quickly clicked "Cancel". I thought this would delete all existing data, so I went on to replace the model. However, an error occurred, and I suspect there is a bug related to this specific scenario.

[buua436]

@OneKe Could you please confirm whether you have tried creating a new dataset/KB using the new embedding model? We’d like to verify that the new embedding model itself is working (i.e., dataset creation and embedding/indexing succeed), and that the issue only occurs in check_embedding (where it reports unavailable).

[OneKe]

@buua436 Yes, I confirm that it can be used.

[OneKe]

@KevinHuSh @yingfeng @buua436 @yongtenglei
I have an extreme idea: what if we delete this user's index in Elasticsearch—would that allow switching to any embedding model?

[yongtenglei]

Hi, different embedding model have different vector space, mix them may result in unstable or unexpected retrieval result. Officially, we cannot do this.

[OneKe]

@yongtenglei Then please tell me what to do. I have a large number of files that all use the vectors from BAAI/bge-large-zh-v1.5. If this issue isn’t resolved today, I’ll have no choice but to roll back the version.

[yongtenglei]

Hi, could you update the knowledgebase table in MySQL? Please find the specific entry by its id and change its embd_id field to BAAI/bge-large-zh-v1.5@SILICONFLOW.

[OneKe]

This is a screenshot taken after forcibly updating MySQL according to your steps. Can we consider this a success? @yongtenglei

[OneKe]

@KevinHuSh @yongtenglei @yingfeng @buua436 It seems that modifying the database directly is feasible, but could this forced modification method lead to other issues?

[yongtenglei]

Hi @OneKe

It's free to some extent if you don't care too much about retrieval quality, since​ different models map to different vector spaces. Another point to consider is that the vector length must match that of the newer model. If they are same, then retrieval quality is the only drawback.

[OneKe]

@yongtenglei Then how can I switch to a better embedding model, such as Qianwen-3?

[yongtenglei]

Hi, change embd_id to qwen-3, and re-parse or document. It is an equivalent to create a dataset with qwen3-embedding -> upload documents -> parse documents.

[OneKe]

@yongtenglei Do you mean that as long as we directly replace the embedding model in the MySQL database, we can change it to any model, and all we need to do afterward is re-parse?

[yongtenglei]

Yes and no. You have to make sure the original vector length must match that of the newer model.

[OneKe]

@yongtenglei I don’t understand: if we’ve chosen to re-parse, why do we need to consider aligning with the length of the old embedding model? It should have nothing to do with the old model, right?

[buua436]

@OneKe When replacing the embedding model, everything works normally as long as you re-parse the documents. However, if you choose not to re-parse, then the new embedding model must have the exact same vector dimension as the previous one; otherwise, retrieval and all subsequent operations will fail, making the model replacement meaningless.

In addition, the cosine similarity between the old and new model’s embeddings for the same chunk must reach at least 0.99. If the similarity is lower, retrieval accuracy will drop significantly. This is why we strongly recommend replacing the previous local embedding model with BAAI/bge-large-zh-v1.5@SILICONFLOW, whose weights have been tested to be highly aligned with the original model and can produce consistent embeddings. Randomly switching to other models usually results in incompatible embeddings, causing retrieval results to become unreliable.

Our check_embedding mechanism follows the same principle.

We’re very sorry that an unexpected issue prevented you from switching embedding models smoothly.

[yongtenglei]

Hi @OneKe

if we’ve chosen to re-parse. It should have nothing to do with the old model, right?

Yes, that is exactly what I mean. Sorry for any confusion.