add graphrag docs

[shreyaspimpalgaonkar]

Important

Add GraphRAG documentation and update code to support different configurations, improve response handling, and remove global search functionality.

• Documentation:
  • Adds graphrag.mdx to docs/cookbooks with setup and usage instructions for GraphRAG.
  • Updates configurations for R2R Light, R2R Light with Local LLMs, and R2R Full with Docker+Hatchet.
  • Includes CLI and SDK examples for ingestion, graph creation, and enrichment.
• API Changes:
  • Updates KGRouter in kg_router.py to handle different orchestration providers with specific messages.
  • Adds detailed docstrings for create_graph and enrich_graph endpoints.
• Database and Models:
  • Modifies PostgresKGProvider in postgres.py to handle parameter types more accurately.
  • Updates KGCreationEstimationResponse and KGEnrichmentEstimationResponse in responses.py to use Optional types for fields.
• Search Functionality:
  • Removes global search functionality from kg_search_pipe.py.
  • Updates KGSearchSettings in models.tsx and search.py to only support local search.
• Misc:
  • Fixes parameter handling in get_triples() in postgres.py.

^{This description was created by for c4e8855. It will automatically update as commits are pushed.}

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to a97a8c7 in 47 seconds

More details

• Looked at 673 lines of code in 4 files
• Skipped 2 files when reviewing.
• Skipped posting 8 drafted comments based on config settings.

1. py/shared/api/models/kg/responses.py:71

• Draft comment:
  Using Optional[str] with a default of None is a good practice for fields that may not always have a value. This change improves the flexibility and robustness of the data model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from using strings to Optional[str] in the response models is a good practice as it allows for more flexibility and better handling of missing data. However, the default values for these fields should be consistent with the expected data type. In this case, using None as a default for Optional[str] is appropriate.

2. py/shared/api/models/kg/responses.py:76

• Draft comment:
  Using Optional[str] with a default of None is a good practice for fields that may not always have a value. This change improves the flexibility and robustness of the data model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from using strings to Optional[str] in the response models is a good practice as it allows for more flexibility and better handling of missing data. However, the default values for these fields should be consistent with the expected data type. In this case, using None as a default for Optional[str] is appropriate.

3. py/shared/api/models/kg/responses.py:81

• Draft comment:
  Using Optional[str] with a default of None is a good practice for fields that may not always have a value. This change improves the flexibility and robustness of the data model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from using strings to Optional[str] in the response models is a good practice as it allows for more flexibility and better handling of missing data. However, the default values for these fields should be consistent with the expected data type. In this case, using None as a default for Optional[str] is appropriate.

4. py/shared/api/models/kg/responses.py:86

• Draft comment:
  Using Optional[str] with a default of None is a good practice for fields that may not always have a value. This change improves the flexibility and robustness of the data model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from using strings to Optional[str] in the response models is a good practice as it allows for more flexibility and better handling of missing data. However, the default values for these fields should be consistent with the expected data type. In this case, using None as a default for Optional[str] is appropriate.

5. py/shared/api/models/kg/responses.py:91

• Draft comment:
  Using Optional[str] with a default of None is a good practice for fields that may not always have a value. This change improves the flexibility and robustness of the data model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from using strings to Optional[str] in the response models is a good practice as it allows for more flexibility and better handling of missing data. However, the default values for these fields should be consistent with the expected data type. In this case, using None as a default for Optional[str] is appropriate.

6. py/shared/api/models/kg/responses.py:96

• Draft comment:
  Using Optional[str] with a default of None is a good practice for fields that may not always have a value. This change improves the flexibility and robustness of the data model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from using strings to Optional[str] in the response models is a good practice as it allows for more flexibility and better handling of missing data. However, the default values for these fields should be consistent with the expected data type. In this case, using None as a default for Optional[str] is appropriate.

7. py/shared/api/models/kg/responses.py:120

• Draft comment:
  Using Optional[str] with a default of None is a good practice for fields that may not always have a value. This change improves the flexibility and robustness of the data model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from using strings to Optional[str] in the response models is a good practice as it allows for more flexibility and better handling of missing data. However, the default values for these fields should be consistent with the expected data type. In this case, using None as a default for Optional[str] is appropriate.

8. py/shared/api/models/kg/responses.py:125

• Draft comment:
  Using Optional[str] with a default of None is a good practice for fields that may not always have a value. This change improves the flexibility and robustness of the data model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The change from using strings to Optional[str] in the response models is a good practice as it allows for more flexibility and better handling of missing data. However, the default values for these fields should be consistent with the expected data type. In this case, using None as a default for Optional[str] is appropriate.

Workflow ID: wflow_mb9EwKOLUYNvc25G

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
yc_demo	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 8, 2024 11:59pm
yc-demo	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 8, 2024 11:59pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
recommendation_platform	⬜️ Ignored (Inspect)			Oct 8, 2024 11:59pm

[ellipsis-dev]

❌ Changes requested. Incremental review on 4f439a3 in 1 minute and 25 seconds

More details

• Looked at 295 lines of code in 8 files
• Skipped 0 files when reviewing.
• Skipped posting 3 drafted comments based on config settings.

1. docs/documentation/python-sdk/retrieval.mdx:125

• Draft comment:
  The kg_search_type should only support "local" as per the code changes. Update the documentation to reflect this.

    Type of knowledge graph search. Supported value: "local".

• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The comment suggests a change that is not clearly supported by the diff. The documentation still lists both 'global' and 'local' as options, and the change in default does not imply that 'global' is no longer supported. Without evidence that 'global' is unsupported, the comment seems speculative.
  I might be missing additional context from other parts of the codebase that could indicate 'global' is no longer supported. However, based on the diff alone, this is not evident.
  The diff should provide clear evidence of any changes in functionality. Since it does not, the comment appears speculative and should be removed.
  Remove the comment as it is speculative and not clearly supported by the diff.

2. docs/documentation/js-sdk/retrieval.mdx:326

• Draft comment:
  The kg_search_type should only support "local" as per the code changes. Update the documentation to reflect this.

    Type of knowledge graph search. Supported value: "local".

• Reason this comment was not posted:
  Marked as duplicate.

3. docs/documentation/configuration/rag.mdx:45

• Draft comment:
  The kg_search_type should only support "local" as per the code changes. Update the documentation to reflect this.

    "kg_search_type": "local",

• Reason this comment was not posted:
  Marked as duplicate.

Workflow ID: wflow_FjVxfgdHWXUoidiK

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 6e8d62d in 1 minute and 10 seconds

More details

• Looked at 3073 lines of code in 37 files
• Skipped 0 files when reviewing.
• Skipped posting 8 drafted comments based on config settings.

1. py/tests/integration/harness_sdk.py:572

• Draft comment:
  The test function name test_user_overview suggests it is testing user overview, but the print statement says 'Testing: User profile management'. Consider updating the print statement to reflect the correct test being performed.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test function test_user_overview is incorrectly labeled as testing user profile management. It should be testing user overview instead.

2. py/tests/integration/harness_sdk.py:1212

• Draft comment:
  The print statement print("add_user_result = ", add_user_result) is unnecessary for the test and can be removed to keep the test output clean.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test function test_user_adds_user_to_collection has a print statement that outputs the result of adding a user to a collection. This print statement is unnecessary for the test and can be removed to keep the test output clean.

3. py/tests/integration/harness_sdk.py:1214

• Draft comment:
  The condition if add_user_result["results"] != None: should be updated to if add_user_result["results"] is not None: to correctly check for a successful operation.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test function test_user_adds_user_to_collection checks if the result of adding a user to a collection is not None. However, the expected result should be None if the operation is successful, as indicated by the comment. The condition should be updated to check for None.

4. py/tests/integration/harness_sdk.py:1251

• Draft comment:
  The condition if remove_user_result["results"] != None: should be updated to if remove_user_result["results"] is not None: to correctly check for a successful operation.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test function test_user_removes_user_from_collection checks if the result of removing a user from a collection is not None. However, the expected result should be None if the operation is successful, as indicated by the comment. The condition should be updated to check for None.

5. py/tests/integration/harness_sdk.py:1252

• Draft comment:
  The print statement print("Remove user from collection test failed: User not removed from the collection") is unnecessary for the test and can be removed to keep the test output clean.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test function test_user_removes_user_from_collection has a print statement that outputs the result of removing a user from a collection. This print statement is unnecessary for the test and can be removed to keep the test output clean.

6. py/tests/integration/harness_sdk.py:961

• Draft comment:
  The condition if not remove_doc_result["results"] == None: should be updated to if remove_doc_result["results"] is not None: to correctly check for a successful operation.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test function test_user_removes_document_from_collection checks if the result of removing a document from a collection is not None. However, the expected result should be None if the operation is successful, as indicated by the comment. The condition should be updated to check for None.

7. py/tests/integration/harness_sdk.py:962

• Draft comment:
  The print statement print("User removes document from collection test failed: Document not removed from the collection") is unnecessary for the test and can be removed to keep the test output clean.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test function test_user_removes_document_from_collection has a print statement that outputs the result of removing a document from a collection. This print statement is unnecessary for the test and can be removed to keep the test output clean.

8. py/tests/integration/harness_sdk.py:901

• Draft comment:
  The condition if not remove_doc_result["results"] == None: should be updated to if remove_doc_result["results"] is not None: to correctly check for a successful operation.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test function test_user_collection_document_management checks if the result of removing a document from a collection is not None. However, the expected result should be None if the operation is successful, as indicated by the comment. The condition should be updated to check for None.

Workflow ID: wflow_hA1Ht12evJYjtPUb

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on c4e8855 in 29 seconds

More details

• Looked at 12 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. py/tests/integration/harness_sdk.py:704

• Draft comment:
  Remove the unnecessary newline for consistency with the rest of the file.
• Reason this comment was not posted:
  Confidence changes required: 10%
  The extra newline is unnecessary and does not follow the style of the rest of the file.

Workflow ID: wflow_roBRVwwYbIfin8TZ

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.