vector-graph-rag 0.3.1__tar.gz → 0.4.1__tar.gz

{vector_graph_rag-0.3.1 → vector_graph_rag-0.4.1}/.env.example

@@ -36,7 +36,9 @@ MILVUS_URI=./vector_graph_rag.db
 # Model Configuration (Optional - uses VGRAG_ prefix)
 # ============================================================================
 # LLM model for triplet extraction and reranking
-# VGRAG_LLM_MODEL=gpt-4o-mini
+# GPT-6 uses Responses; other configured models use Chat Completions.
+# VGRAG_LLM_MODEL=gpt-6-luna
+# VGRAG_LLM_REASONING_EFFORT=medium
 
 # Embedding model (HuggingFace model name or OpenAI model name)
 # VGRAG_EMBEDDING_MODEL=facebook/contriever
@@ -101,9 +103,9 @@ MILVUS_URI=./vector_graph_rag.db
 # VGRAG_PASSAGE_COLLECTION=vgrag_passages
 
 # Task-specific models override the shared VGRAG_LLM_MODEL.
-# VGRAG_EXTRACTOR_MODEL=gpt-5-mini
+# VGRAG_EXTRACTOR_MODEL=gpt-6-luna
 # VGRAG_RERANKER_MODEL=jev
-# VGRAG_ANSWER_MODEL=gpt-4o-mini
+# VGRAG_ANSWER_MODEL=gpt-6-luna
 # TYPESAFE_API_KEY=your-key
 
 # VGRAG_JEV_MAX_CONCURRENCY=3

vector_graph_rag-0.4.1/.github/workflows/release.yml

@@ -0,0 +1,69 @@
+# Push a v-prefixed tag only after the release pull request passes validation.
+name: Validate and Publish Python Package
+
+on:
+  pull_request:
+    branches: [main]
+  push:
+    tags: ["v*"]
+
+permissions:
+  contents: read
+
+jobs:
+  validate:
+    name: Validate Python ${{ matrix.python-version }}
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.10", "3.12"]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v6
+      - name: Install test dependencies
+        run: uv sync --locked --python '${{ matrix.python-version }}' --extra dev --extra api
+      - name: Check package and tag versions
+        run: |
+          uv run --no-sync python - <<'PY'
+          import os
+          from importlib.metadata import version
+          from vector_graph_rag import __version__
+
+          package_version = version("vector-graph-rag")
+          assert package_version == __version__, (package_version, __version__)
+          if os.environ["GITHUB_REF_TYPE"] == "tag":
+              assert os.environ["GITHUB_REF_NAME"] == f"v{package_version}"
+          print(f"Validated version {package_version}")
+          PY
+      - name: Run tests
+        run: uv run --no-sync pytest tests -q
+      - name: Build distributions
+        run: uv build
+      - name: Verify wheel installation in isolation
+        run: |
+          uv run --isolated --no-project --python '${{ matrix.python-version }}' \
+            --with ./dist/vector_graph_rag-*.whl python -c \
+            'from importlib.metadata import version; from vector_graph_rag import Settings, VectorGraphRAG, __version__; assert version("vector-graph-rag") == __version__; print(__version__)'
+      - name: Save validated distributions
+        if: matrix.python-version == '3.12'
+        uses: actions/upload-artifact@v4
+        with:
+          name: distributions
+          path: dist/
+
+  publish:
+    name: Publish to PyPI
+    if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v')
+    needs: validate
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          name: distributions
+          path: dist/
+      - name: Publish validated distributions
+        uses: pypa/gh-action-pypi-publish@release/v1

vector_graph_rag-0.4.1/CHANGELOG.md

@@ -0,0 +1,35 @@
+# Changelog
+
+## Unreleased
+
+## 0.4.1
+
+### Fixes
+
+- Preserve entity/passage links for every chunk that shares a relation, including full rebuilds, incremental source updates and passage creation. Source deletion can now clean up shared entities after every source has been removed.
+- Reject invalid chunk sizes and overlap values before importing documents. Mixed short/long file imports can no longer report success while silently omitting text because of an invalid character-splitting step.
+- Read knowledge-base statistics from strongly consistent Milvus counts across all sources. Counts reflect incremental updates, deletions and reconnects; storage failures raise an error and return HTTP 500 through the REST statistics endpoint.
+
+### Documentation
+
+- Add the Jev 1.14 evaluation report, paired latency calibration and updated quality–latency comparison.
+- Document current knowledge-base statistics, storage failures and concurrent-update behavior.
+
+### Upgrading
+
+The shared-relation fix applies to new writes. Existing missing adjacency links are not repaired automatically. Rebuild affected knowledge bases with `rebuild_documents()` using the complete corpus and its source metadata. A rebuild replaces all data under the selected collection prefix, so include every source that should remain available.
+
+## 0.4.0
+
+### What's changed
+
+- Default generation tasks now use GPT-6 Luna through Responses with medium reasoning: triplet extraction, entity extraction, relationship reranking and answer generation.
+- Cache keys distinguish the Responses interface and reasoning effort. Incomplete, refused or empty Responses outputs are rejected instead of cached as successful answers.
+- Retrieval evaluation now compares Jev with GPT-6 Luna and official DeepSeek V4.1 Flash. The report retains the September/October 2026 evaluation timeline, reproducible Jev evidence and a link to superseded experiments.
+- Publishing now requires passing tests on Python 3.10 and 3.12, matching package/tag versions, and an isolated wheel installation check.
+
+### Upgrading
+
+The default model changed from GPT-4o-mini to GPT-6 Luna. Custom OpenAI-compatible endpoints must support Responses when using GPT-6 models. Explicitly configured non-GPT-6 models retain Chat Completions; set `VGRAG_LLM_MODEL` explicitly to retain your chosen model. The OpenAI SDK minimum is now 1.66.0.
+
+Reasoning defaults to `medium` and can be configured with `VGRAG_LLM_REASONING_EFFORT`. Existing cache files are preserved, but GPT-6 Responses requests use separate cache keys. DeepSeek is an evaluation baseline, not the runtime default. Frozen benchmark results are unchanged by the runtime migration.

{vector_graph_rag-0.3.1 → vector_graph_rag-0.4.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: vector-graph-rag
-Version: 0.3.1
+Version: 0.4.1
 Summary: A Graph RAG implementation using pure vector search with Milvus
 Project-URL: Homepage, https://github.com/zilliztech/vector-graph-rag
 Project-URL: Documentation, https://zilliztech.github.io/vector-graph-rag/
@@ -23,7 +23,7 @@ Requires-Dist: httpx>=0.27
 Requires-Dist: langchain-core>=0.3.0
 Requires-Dist: milvus-lite<3,>=2.4.0
 Requires-Dist: numpy>=1.24.0
-Requires-Dist: openai>=1.0.0
+Requires-Dist: openai>=1.66.0
 Requires-Dist: pydantic-settings>=2.0.0
 Requires-Dist: pydantic>=2.0.0
 Requires-Dist: pymilvus<2.6.10,>=2.4.0
@@ -398,7 +398,7 @@ Before introducing Jev, we evaluated Vector Graph RAG on three multi-hop QA benc
 
 **Two-stage Jev reaches the quality–latency Pareto frontier.**
 
-**86.07% average Recall@5**, the highest among the compared methods, with **3.13 seconds of additional model-call latency**. On MuSiQue and 2Wiki (1,000 questions each), two-stage Jev reaches the Pareto frontier under the reference latency estimates. This two-dataset result is separate from the historical three-dataset average above.
+**Jev 1.14 achieves 86.61% average Recall@5**, the highest among the compared methods, with **approximately 4.9 seconds of estimated direct API latency**. On MuSiQue and 2Wiki (1,000 questions each), two-stage Jev reaches the Pareto frontier using the displayed timings. This two-dataset result is separate from the historical three-dataset average above.
 
 ![Quality and additional model latency](docs/assets/evaluation/quality-latency.png)
 

{vector_graph_rag-0.3.1 → vector_graph_rag-0.4.1}/README.md

@@ -290,7 +290,7 @@ Before introducing Jev, we evaluated Vector Graph RAG on three multi-hop QA benc
 
 **Two-stage Jev reaches the quality–latency Pareto frontier.**
 
-**86.07% average Recall@5**, the highest among the compared methods, with **3.13 seconds of additional model-call latency**. On MuSiQue and 2Wiki (1,000 questions each), two-stage Jev reaches the Pareto frontier under the reference latency estimates. This two-dataset result is separate from the historical three-dataset average above.
+**Jev 1.14 achieves 86.61% average Recall@5**, the highest among the compared methods, with **approximately 4.9 seconds of estimated direct API latency**. On MuSiQue and 2Wiki (1,000 questions each), two-stage Jev reaches the Pareto frontier using the displayed timings. This two-dataset result is separate from the historical three-dataset average above.
 
 ![Quality and additional model latency](docs/assets/evaluation/quality-latency.png)
 

{vector_graph_rag-0.3.1 → vector_graph_rag-0.4.1}/docs/architecture/design-philosophy.md

@@ -119,15 +119,11 @@ The key insight is that **vector search combined with subgraph expansion already
 
 With these three mechanisms working together, the candidate set is already rich and relevant. A single LLM reranking pass is sufficient to select the best relations from this high-quality pool.
 
-### The Cost Advantage
+### Model Calls and Cost
 
-Each LLM call adds latency (typically 1–3 seconds) and cost. For a system processing thousands of queries per day, the difference between 2 and 5 LLM calls per query is substantial:
+Avoiding an iterative retrieval loop reduces the number of dependent model calls. Actual latency and cost also depend on prompt size, output length, reasoning settings, provider queueing and request concurrency; call counts alone do not establish a speedup or cost reduction.
 
-| Metric | Iterative (5 calls) | Single-Pass (2 calls) | Savings |
-|--------|---------------------|----------------------|---------|
-| **Latency** | ~5–15s | ~2–6s | 2–3x faster |
-| **Cost** (GPT-4o-mini) | ~5x base | ~2x base | 60% cheaper |
-| **Cost** (GPT-4o) | ~5x base | ~2x base | 60% cheaper |
+See the [retrieval evaluation](../evaluation.md#jev-reranker-evaluation) for measured Jev, GPT-6 Luna and DeepSeek V4.1 Flash quality and model-call latency. Those retrieval measurements do not benchmark extraction or answer generation.
 
 > [!TIP]
 > For applications where latency and cost are secondary to accuracy on extremely complex queries (5+ hop chains, ambiguous entity resolution), iterative approaches may still be worth the overhead. See [When to Consider Alternatives](#7-when-to-consider-alternatives).
@@ -242,7 +238,7 @@ flowchart TB
 | **Local-first** | Yes | Yes | Partial | No | No | **Yes (Milvus Lite)** |
 | **Setup complexity** | Minimal | Moderate | Moderate | High | High | **Minimal** |
 
-### Performance on Multi-Hop QA Benchmarks
+### Historical Performance on Multi-Hop QA Benchmarks
 
 | Method | MuSiQue | HotpotQA | 2WikiMultiHopQA | Average |
 |--------|---------|----------|-----------------|---------|
@@ -252,7 +248,7 @@ flowchart TB
 | **Vector Graph RAG** | 73.0% | **96.3%** | **94.1%** | **87.8%** |
 
 > [!INFO]
-> Recall@5 on standard multi-hop QA benchmarks. Vector Graph RAG achieves the highest average score while using fewer LLM calls and no graph database. See [Evaluation](../evaluation.md) for methodology details.
+> Historical three-dataset Recall@5 comparison. The October 16, 2026 two-stage Jev 1.14 evaluation reaches 77.73% on MuSiQue and 95.50% on 2Wiki (86.61% average), the highest-quality point on the observed quality–latency Pareto frontier. Its two-dataset scope is separate from this table. See [Evaluation](../evaluation.md#jev-reranker-evaluation) for methodology and paired comparison with Jev 1.13.
 
 ### Key Differentiators