Closed JoedNgangmeni closed 1 week ago
Try setting request_timeout: 180.0 higher, try 210.0 or 1800.0
Try setting request_timeout: 180.0 higher, try 210.0 or 1800.0
I will try it but am confused how that will help the KeyError because I don't understand the keyError to be dependent on some timeout, but on a value pairing.
I've also encountered the same problem since I upgraded to version 0.4.0.
I've also encountered the same problem since I upgraded to version 0.4.0.
If you are using a local model, you can use FastChat to encapsulate the embedding model as GPT-4, so that it can run normally.
I've also encountered the same problem since I upgraded to version 0.4.0.
If you are using a local model, you can use FastChat to encapsulate the embedding model as GPT-4, so that it can run normally.
Can only use GPT-4? This is really bad news. I am using the LLM model glm-4-flash and the embedding model bge-m3, both of which are local models, and I am getting the same error.
I've also encountered the same problem since I upgraded to version 0.4.0.
If you are using a local model, you can use FastChat to encapsulate the embedding model as GPT-4, so that it can run normally.
Can only use GPT-4? This is really bad news. I am using the LLM model glm-4-flash and the embedding model bge-m3, both of which are local models, and I am getting the same error.
"No, that's not what I mean. You can use bge-large-zh-v1.5 as your vector model for local deployment. At the same time, you need to write a script file to name your local vector model as gpt-4. In this way, it will be confused with OpenAI's interface in graphrag, so that graphrag can run normally."
Below is my sh file configuration.
MODEL_WORKER_CUDA_VISIBLE_DEVICES="0" MODEL_WORKER_MODEL_PATH="/root/autodl-tmp/bge-large-zh-v1.5" MODEL_WORKER_MODEL_NAMES="gpt-4" MODEL_WORKER_NUM_GPUS="1" MODEL_WORKER_CONTROLLER_ADDRESS="http://$CONTROLLER_HOST:$CONTROLLER_PORT"
Then is my settings.yaml
embeddings: async_mode: threaded # or asyncio vector_store: type: lancedb db_uri: 'output/lancedb' container_name: default # A prefix for the vector store to create embedding containers. Default: 'default'. overwrite: true llm: api_key: ${GRAPHRAG_API_KEY} type: openai_embedding # or azure_openai_embedding model: gpt-4 api_base: http://127.0.0.1:8200/v1
I am currently using FastChat version 0.23.5
I updated to GraphRAG 0.4.1 and it seems this error is fixed
Do you need to file an issue?
Describe the bug
Every time i run the indexer
python -m graphrag index --root ./mydirectory --verbose
I get the same error.I know this is a bug because i have tried it with different initializations and different data.
I have tracked it down to have something to do with the way "name_description" is generated.
I am unsure if it is done in graphrag > index > flows > generate_text_embeddings.py > generate_text_embeddings > entity_description_embedding OR graphrag > index > update > entities.py > _run_entity_description_embedding.
Both of these files create name_description by putting together the name and the description of an entity. This causes problems later in the _text_embed_with_vector_store function in (graphrag > index > operations > embed_text > embed_text.py > _text_embed_with_vector_store).
My understanding is that this happens because instead of finding the column title (which should be something like "title", "name", "description", or even "name_description") it is now finding something like "name:description_paragraph". This does not exist as a standalone column.
Other question: Is the generate_text_embeddings process necessary for optimal performance? I'm not actually sure what it even does or why it's needed.
Steps to reproduce
Follow instructions on the graphrag quick start page
Expected Behavior
All verbs and workflows to run smoothly with no errors.
GraphRAG Config Used
Logs and screenshots
I've added log lines in the code at (graphrag > index > operations > embed_text > embed_text.py > _text_embed_with_vector_store) to understand what is happening. I will provide the full logs as well but those are couple tens or thousands of lines long so first i am providing the relevant exceprts.
Here is the code so you can understand the logs:
Attached the logs: indexing-engine.log
Additional Information