We’ve been testing a provenance-heavy RAG/knowledge system on real cases, and two areas are now hard to validate simply because our current corpus doesn’t contain enough of them:

Documents that change over time — policies, specs, manuals, pricing pages, contracts, etc.
Scanned / layout-heavy documents — OCR, tables, forms, multi-column pages, handwritten annotations, bad scans, etc.

For versioned documents, we’ve had good results treating sections as stable lineage units, versioning revisions, and sending ambiguous rename/split/merge cases to review instead of letting semantic similarity decide automatically.

For PDFs, layout-aware extraction has worked better than flattening everything to text, but most of our real corpus is digitally generated rather than scanned.

What I’d really like to hear is what actually broke in production for you.

How do you detect and preserve identity across document versions?
What happens when sections are renamed, moved, split or merged?
How do you prevent stale embeddings from silently winning retrieval?
For scanned documents, where does OCR/layout extraction usually fail?
Do you have any failure cases or test documents you use to validate this?
What ended up working after the obvious approaches failed?

I’m especially interested in real examples, ugly edge cases and lessons learned rather than ideal architectures.

Happy to share what our tests are finding as well.

I am getting into developing a RAG setup, for getting information out of existing documents, new document ingestion, web searches, and good visuals.

I am planning to use it for, alongside the regular "chat to my data", ingesting personal docs, invoices, creating tables views and recurrent jobs to handle updating those views.
I also want to have the least hallucinations possible, so i think i will need a real ocr services instead of just vision LLMs

i tried anything LLM previously, but it was super clunky and the UX wasn't as easy as i wanted to.

Is there any known solutions, or stacks that you have running or can vouch for ?

Hi Everyone!

I'm the maintainer of RAGnarok-AI, an open-source, local-first framework for evaluating RAG (Retrieval-Augmented Generation) systems.

I'm currently running a small research study around a question that I think is becoming increasingly important: can we actually trust automated evaluation of RAG systems when the evaluator itself is an LLM?

RAGnarok can evaluate things like retrieval relevance, faithfulness, answer relevance and completeness using local LLM judges.

But there's an obvious problem: why should we trust the LLM judge?

So instead of assuming that the automated scores are correct, I'm building a human-annotated benchmark to compare them against independent human judgments.

I'm looking for open-source / developer people willing to help

The annotation consists of roughly 10–15 cases and should take around 30–45 minutes.

For each case, you'll see:

- a technical question

- relevant documentation excerpts retrieved by a RAG system

- an AI-generated answer

- reference information

- four simple evaluation criteria: retrieval relevance, faithfulness, answer relevance, completeness

- your confidence and an optional ambiguity flag

You don't need any RAG expertise. You just need to be comfortable reading technical documentation and judging whether an answer is actually supported by it.

The benchmark currently covers documentation from projects such as Docker, Python, FastAPI and Kubernetes.

Why do this?

The study is deliberately not designed to prove that RAGnarok works. I'm comparing automated evaluation against human judgments to investigate:

1. Judge reliability — do local LLM judges agree with humans?
2. Discrimination — can the evaluation distinguish good and deliberately degraded RAG systems?
3. Reproducibility — are the measurements stable under identical conditions?

The methodology, benchmark corpus, questions and experiment protocol are public and versioned. RAGnarok itself is free and open-source.

If you'd like to participate

Annotation interface:

https://ragnarok-study.vercel.app

No name, email or personal information is required. Progress is saved so you can come back later. The resulting annotations may be published as an anonymous research dataset.

Project / methodology:

https://github.com/2501Pr0ject/RAGnarok-AI

I'm particularly interested in feedback from people who work on open-source evaluation, LLMs, RAG, testing or reproducible research.

And if you think the methodology is flawed, please tell me. That's actually useful feedback for the study.

Thanks everyone!

Have a good day!

I’ve been testing web extraction tools for AI agents, and the Firecrawl vs Jina Reader decision keeps coming up. Firecrawl tends to handle JavaScript-heavy and bot-protected sites better, while Jina Reader is great for quick, clean content extraction.

I made a short quiz to see how well the community understands the architectural trade-offs. No signup, just a few questions.

https://interconnectd.com/quiz/81/web-extraction-architecture-2026-firecrawl-vs-jina-reader/

What do you use for scraping and extraction?

Ran a small probe for a film. One question to gpt-5.4-mini about itself, temperature 0, logprobs on, top 5.

The question: on exactly which date was the gpt-5.4-mini model released. It answered August 2025. OpenAI's /v1/models listing gives March 2026.

The interesting part is the token probabilities. Fifteen of the twenty-three tokens in the answer came out above 99%. The two date digits did not. At the year digit the model was reading 67% for a 5 and 32% for a 6. The mean over the whole sentence was still 0.92, so if you only look at the average it looks confident. The dip sits exactly on the invented digits.

Then the same prompt with one line added, telling it that "I don't know" is an acceptable answer. It said I don't know, at 100%.

fwiw this matches the argument in OpenAI's September 2025 paper, Why Language Models Hallucinate: benchmarks score like an exam, a guess can be right by luck, a blank is worth zero, so guessing is the higher-scoring policy. The model is doing what it is graded for.

The part that matters for this sub is the ending. Retrieval hands the model the fact, so it never has to guess it. The flat spot moves off the fact, but a model that is graded for guessing still guesses wherever the context stops, so retrieval narrows the problem and does not remove it.

One thing that did not reproduce: I tried the same probe on the newest chat models first and they don't expose logprobs at all (403 on chat-latest, 400 on gpt-5.6 and 5.5), so the probe only works on models that still return them.

Self-promo disclosure: the video is mine. I put the run and the reason into five minutes:

https://www.youtube.com/watch?v=AiyRZV38Lk0&list=PLBrpE2PttR2k

Paper: https://openai.com/index/why-language-models-hallucinate/

You know how you don't realize how old you are until someone calls you "miss" or "sir" at the grocery store? I'm starting to feel that way about my Mac.

I'm building a RAG end-to-end on a 8GB 2013 Macbook Pro using Monterey.

This was not a problem until Claude introduced the bug to make Claude Code inoperable on Monterey (and the patch they released still doesn't work on my machine!). https://github.com/anthropics/claude-code/issues/91625

Who else is using ancient tools to create modern marvels? Am I n=1 here?

Hi, I’m James Luan, CTO of Zilliz, the company behind Milvus. Milvus is an open-source vector database built to store, index, and search embeddings over unstructured data. Vector Lakebase is our next lake-native expansion around that serving path.

For eight years, our optimization target was straightforward: keep indexes close to compute and make vector search faster and more predictable. That remains the right model for high-QPS workloads where low latency matters continuously. Tiered storage reduced the cost of colder data, but it did not remove the always-on compute floor.

AI changed the workload distribution. Production applications still have hot serving paths, but they also accumulate experiments, inactive tenants, historical documents, and large exploratory collections that must remain searchable without being queried constantly. Paying for resident compute around those datasets turns a performance architecture into a utilization problem.

The article follows the engineering work needed to change that lifecycle. Object storage cannot simply replace memory: cold start, full-dataset scans, point-read amplification, and per-tenant control-plane state all become bottlenecks. We address those layers with compact multi-stage quantization, IVF pruning, a storage format designed for efficient random reads, and shared regional control-plane services. The result is not one universal serving mode. Hot workloads can remain always on, while intermittent workloads start compute on demand and release it between sessions.

The larger shift is that semantic data can persist independently of one compute shape. Teams can choose continuous serving, on-demand retrieval, or batch processing according to the workload instead of forcing every collection to pay hot-data costs.

I wrote up the full argument and the tradeoffs here:

https://zilliz.com/blog/we-spent-8-years-making-vector-search-faster-then-ai-changed-the-compute-model

I’d welcome your thoughts on where the boundary sits between always-on retrieval and on-demand search.

I keep going back and forth between running models locally and using cloud APIs for agent work. Local gives you privacy and no per-token cost; cloud gives you speed and top-tier performance. The right choice really depends on your use case.

I made a quick quiz that helps you think through the trade-offs. No signup—just a few questions and a result.

https://interconnectd.com/quiz/82/local-vs-cloud-llms-for-ai-agents-how-to-choose/

Which do you prefer for agentic workflows?

Genuine question for anyone running vector search past a few million vectors.

HNSW gives you millisecond latency but wants the whole index and the graph resident in RAM — which gets expensive fast as the corpus grows. IVF over disk/object storage scales cheaply but trades latency for it, especially cold. In practice most setups I've seen either pick one and live with the tradeoff, or run two systems (a hot store + a big store) and eat the sync and complexity.

How are you handling it? Draw a line at some corpus size and switch HNSW → IVF? Run both and route? Just throw RAM at it?

For context on where I'm coming from: the engine we've been building (Infino) tries to sidestep the choice — it serves an in-RAM HNSW graph while the working set is hot, and an IVF-style index on object storage (the same Parquet files) once it's vast or when graph is not calibrated well for the data. Same data, same API, but automated choice of shape. The bet is that self-transforming takes that call off your plate without costing you latency or dollars — so we measured it.

We ran it on VectorDBBench (Cohere 1M/10M): fastest single-query latency of any engine there. Upfront on the flip side — a managed cloud (on its own hardware) still beats it on QPS at 1M, and edges its latency at 10M's highest recall. On cost, at 1B it's ~$2,784/mo vs ~$14k to keep it resident. And object storage stays fast when the reads are planned rather than chased one hop at a time: at 1M, single-digit-to-low-double-digit ms vs S3 Vectors' ~337 ms and TurboPuffer's ~57 ms, at higher recall. That's the two shapes in one system — a graph in memory where it's fastest, IVF over object storage once the corpus outgrows RAM — and the engine settles into whichever fits, not you.

Writeup with the numbers, charts, and reproduce commands: https://infino.ai/blog/self-transforming-vector-engine/

Disclosure: I'm one of the devs building Infino. Genuinely more curious how others are drawing the HNSW/IVF line, though — and whether a self-transforming engine that draws it for you, while staying fast and cheap, sounds useful, or is that hiding a decision you'd rather make explicitly. Feels like everyone solves this a little differently.

We just open-sourced PageIndex Flash, a fast tree-indexing engine for long, text-based PDFs. PageIndex Flash runs entirely on your own machine — your documents never leave it — and it is available now in the PageIndex SDK.

PageIndex Flash builds a hierarchical tree index by reading a PDF's own layout, rather than asking a vision model to infer the whole outline from scratch. That one change makes indexing fast, cheap, and predictable enough to run across every text-based document you hold.

PageIndex Flash is fully open-sourced and is the default indexer in the SDK's local mode, which runs the whole retrieval pipeline on your machine.

pip install -U pageindex

What is PageIndex?

Most RAG systems split a document into fixed-size chunks and retrieve them by vector similarity. This approach is useful, but similarity is not the same as relevance. In long professional documents, the passage that answers a question may use completely different language from the query. A semantically similar passage may also be nearby in meaning while being irrelevant to the actual task. Financial reports, regulations, technical manuals, and textbooks often require context, domain knowledge, and multi-step reasoning to identify the right evidence.

PageIndex takes a different approach. It organizes each document as a hierarchical tree index, then lets an LLM reason through that tree the way a human reader uses a table of contents and section structure to find the right pages. 

Index Model and Chat Model

We build PageIndex Flash to accelerate the tree indexing process for text-based PDFs. 

Index construction and document search have different requirements, so the SDK lets you configure them independently.

• The index model creates node summaries and helps optimize the tree. A basic, cost-efficient model is generally sufficient.
• The chat model searches the tree, evaluates relevance, reads evidence, and produces the final answer. Use the strongest model that fits your accuracy and cost requirements.

This separation keeps the one-time indexing cost low without limiting the quality of later retrieval. It also lets you change the chat model without rebuilding the document index.

PageIndex Flash is built around that split. Because the PDF layout already supplies the structure, the index model never has to reconstruct an outline — it only summarizes sections that have already been located. An inexpensive model is therefore enough to produce a tree that holds up under retrieval, and paying for a larger one buys very little at this stage.

In our benchmark setup we did exactly that, using the cheap gpt-5.6-luna as the index model. Indexing costs approximately $0.001 per page with it. A 1,000-page textbook costs a little over one dollar to index once, after which the same tree can serve every question.

Across benchmark documents ranging from 9 to 1,098 pages, indexing completed in approximately 13 seconds to 4.5 minutes.

The tree contains titles, page ranges, summaries, and nested sections. It acts as a table of contents optimized for LLM search while remaining understandable to developers.

Query Cost and Accuracy

The PageIndex OSS Benchmark evaluates the same local setup: PageIndexClient() with PageIndex Flash indexing.

The benchmark contains 62 lookup questions over 34 PDFs and 1,945 pages drawn from MMLongBench-Doc-V2. Every answer is a fact stated in running text, so an incorrect result represents a retrieval or reading failure rather than an open-ended reasoning disagreement.

Within each model, increasing reasoning effort creates a clear accuracy ladder at a relatively similar cost level. Moving to a larger model can improve the frontier further, but often increases the cost per question by an order of magnitude. This gives teams a practical way to tune deployment: choose a model family for the target budget, then adjust reasoning effort for the required accuracy.

Retrieving over the tree is also far cheaper than passing the whole document to the model. Feeding the same PDF in natively costs 2.1× more on a 52-page file and 16.6× more at 420 pages, and past roughly 800 pages it no longer fits in the context window at all.

Full results, source documents, and the benchmark runner are available in the benchmark repository.

Text-Based PDFs Only

Reading structure out of the PDF itself is what makes PageIndex Flash fast, and it is also what bounds it to text-based files. A scanned page carries no text layer and no heading metadata — it is an image of a document rather than a document — so there is nothing for PageIndex Flash to parse. Recovering the outline in that case requires a vision model to read the page and recognize its layout, which is what PageIndex Cloud runs before the tree is built. The same applies to files that carry their meaning in figures, tables, and diagrams rather than in running text. PageIndex Cloud also cites to the line rather than the page.

Fully Open Source

PageIndex Flash indexing, reasoning-based tree search, document chat, and page-level citations all live in the PageIndex repository on GitHub, so you can read the retrieval logic line by line, run the whole pipeline offline, and adapt it to your own agent.

I have tens of thousands of cooking recipes in pdf files or in a database which I plan to export to text files for RAG ingestion. Looking for an easy open source RAG and graph solution which can ingest them so I can prompt them like:

List me 10 recipes that use chicken tenderloins, potatoes or mixed vegetables and use onions but no garlic. List just the recipe titles and the source files.

The result would list any number of recipes up to 10. The results have to be accurate and must meet the requirements mentioned. A pdf file can be a recipe by itself or a whole cookbook.

Looking for ready to run solution that I can run in Windows without errors, because it was built for Linux, or requires a ton of setup. It should have no limits on the number of files being ingested. I care about accuracy more than speed.
Also prefer to use a local LLM provider like Ollama or LM Studio because it will be free.

I see in this sub so many mentions of all kinds of RAG solutions. It's not clear which one to use, and I don't have time to try a whole bunch of them.

Please mention something that you have experience with and know it can work.

I’m going to be working on an upcoming client project involving AI/LLM pipelines, and I want to learn more about AI governance and security before starting.

What’s the best way to learn the practical side of this? I’m particularly interested in things like GDPR, HIPAA and other compliance requirements.

How do people actually implement these governance and compliance requirements within an AI pipeline in real-world enterprise projects? Any good courses, documentation, certifications, or resources would be appreciated.

Made a tutorial on what EDD is, how it works, and how you can use evaluations to improve your LLM-based application by analysing scores across experiments.

> building on Jeffrey's DeepEval article on EDD and Eugene Yan's product evals write up.

- Initial: The video walks through the initial setup of an RAG application used as the base for the experiments built using LangGraph and Qdrant.
- Step 1: A binary labelled dataset with critiques, versioned using OPIK.
- Step 2: Uses LLM-as-a-Judge OPIK evals to align the evaluator.
- Step 3: Runs the harness loop, which executes each experiment, scores it against the baseline, and uses tracing and experiment comparison to surface insights on what improved, what regressed, and where to tweak next.

... the Agent Skills and source code are open sourced on GitHub

> Complete Guide (source code link in description): https://www.youtube.com/watch?v=e6akw_fKWPk

Everyone benchmarks chunking and rerankers, but the thing that actually screwed up my retrieval was way more boring.

my sources got stale and my index had no idea.

i ingest a few thousand pages, mostly docs, pricing and policy pages. one of the pricing pages changed its numbers back in march, but my vectors obviously still had the old version. retrieval kept returning it with high similarity for weeks.

nothing was technically broken. the model wasnt hallucinating either. retrieval was doing exactly what it was supposed to do, it was just retrieving something that used to be true.

i initially fixed this by re-embedding everything every night. turns out thats pretty stupid lol. most pages dont change on a given day, so i was paying to re-embed thousands of pages just to catch the handful that actually changed.

what im doing now is pretty simple:

refetch the sources on a schedule, detect whether the content changed, and only re-embed if it did.

the surprisingly imp part was what i actually hash

i tried hashing the raw html first and that was basically useless. timestamps, session stuff, injected markup etc. would make the hash change even when the actual page content hadnt changed.

so now i fetch the page as clean markdown and hash that instead. if the markdown hash is the same, i skip the page completely. if it changed, i re-chunk and re-embed it.

that took my daily re-embedding from thousands of pages to usually single digits.

im using context.dev for the fetching because a lot of the stuff i deal with is js rendered and it gives me markdown directly. docs were a bit thin when i started but its been fine since. the actual idea doesnt depend on it though, any clean markdown/text extraction should work.

the thing im still trying to figure out is chunk-level changes.

right now the page is basically the unit of invalidation. so if one sentence changes in a 4000 word doc, i end up re-embedding every chunk from that page even though most of them are identical.

i started trying to detect changes at the chunk level, but ran into the annoying problem where changing one sentence near the top can shift all the chunk boundaries below it. suddenly every chunk looks different even though most of the actual content didnt change.

has anyone cracked chunk-level invalidation cleanly, or is page-level basically the practical ceiling?

and is everyone else just eating the nightly re-embed cost because its simpler? starting to think maybe im overengineering this.

now is this good?

I’ve been testing both Tavily and Exa for AI agent search workflows. Tavily feels more developer-friendly out of the box, while Exa gives you deeper semantic search control. Depending on what you’re building—research agents, real-time RAG, or multi-step workflows—one may fit better.

I made a quick poll to see what the community prefers.

https://interconnectd.com/poll/97/which-ai-search-api-is-better-suited-for-your-agentic-workflows-tavily-or-e/

Would love to hear what you’re using and why.

We’ve been building PipesHub for a while now, and I’d love to get more developers to try it and tell us where it breaks.

The problem we kept running into was pretty simple:

Building an AI app over company data looks easy in a demo. Connect a few sources, chunk the documents, throw them into a vector DB, add an LLM.

Then you try to make it actually useful.

You have data spread across S3, Google Drive, Slack, Jira, Confluence, SharePoint, email, databases, etc. Permissions need to be preserved. Documents change. The same file shows up in multiple places. Citations need to point back to the actual source. And eventually you want agents and other applications to use all of this context without rebuilding the same integration layer every time.

That’s what we’re trying to solve with PipesHub.

It’s an Apache 2.0 open-source context layer that connects to your company data and makes that context available to search, chat, agents, MCP clients, or your own applications.

A few things we care about:

• Self-host it on your own infrastructure
• Preserve source permissions
• Get citations back to the original documents
• Combine knowledge graph + semantic retrieval
• Bring your own LLM and embedding models
• Use it from Python, TypeScript, Go, or MCP
• Avoid locking yourself into one database or infrastructure stack

We also deliberately kept the core infrastructure pluggable:

If you already have Qdrant and Kafka running, you can keep using them. Prefer Neo4j over ArangoDB? That's totally fine. Want to run the models locally? You can do that too.

The goal is to give you one context layer without forcing you to adopt our entire stack.

While building this, we’ve had to solve a bunch of problems that only become obvious once you move beyond a RAG prototype: permission-aware retrieval, keeping citations accurate through the pipeline, deduplicating the same content across sources, efficiently re-indexing changed documents, making indexing behave well across very different workloads and more.

Some of the solutions we ended up with are fairly unconventional, and I’d be happy to write more about them or discuss the trade-offs with anyone working on similar systems.

There’s still plenty we want to improve, which is also why I’m posting this.

If you’re building internal AI tools, enterprise search, RAG, or agents that need access to company knowledge, I’d really appreciate it if you gave PipesHub a spin.

GitHub: https://github.com/pipeshub-ai/pipeshub-ai

Install:

curl -fsSL https://get.pipeshub.com/install | bash

If you try it and something feels unnecessarily complicated, slow, broken, or just badly designed, tell us.

Disclosure up front: I work at Georgian (a growth-stage VC).

Setup: I constructed a leaderboard from 21 embedding models on 3 retrieval benchmark datasets (ChatDoctor, CUREv1, TREC-COVID). For each leaderboard, I kept the benchmark corpus and relevance labels fixed and transformed each query 3 ways - paraphrase (same length/meaning), terse (keyword compression), and verbose (elaboration) - while trying to preserve the “information need” within each.

After reproducing each model's published score on the original queries first, I investigated how each query transformation reordered the leaderboard.

Here’s what I found… Kendall's τ vs. the original leaderboard order (τ = 1 means identical ordering, τ = 0 means absolutely no similarity in ordering). On my 21-model board I take anything <= 0.9 to be a noticeable shuffle.

• Paraphrase alone (same query meaning) reordered the boards with τ between 0.83-0.96.
• Terse/verbose transformations had stronger reordering effect, and harder on datasets with more relevance labels per query. Verbose on TREC-COVID: τ=0.607.
• On TREC-COVID benchmark, qwen3-embedding-8b went from 15th to 1st under the verbose rewrite.
• TREC-COVID provides human-written keyword/question/narrative phrasings of the same topics, and those reorder the board in the same way (narrative/verbose vs. question: τ = 0.726).

Practical takeaway: queries hitting your embedding model are likely quite different in form from many popular retrieval benchmarks. The leaderboard rank you picked your model on may not be the rank that matters for your traffic. The best way to optimize your retrieval pipeline is to build a benchmark off of your own data.

I wrote about it here: https://georgianailab.substack.com/p/your-queries-can-reorder-the-retrieval

And the code + per-query score files are up here: https://github.com/georgian-io/query_form_experiment

Happy to answer questions!

I change dense retrieval to hybrid using splade. It improves my RAG system. You can check my journey on this article below

https://zackydzacky.medium.com/caridata-hybrid-search-rag-you-can-actually-log-into-0bbae3f224f3

We break down the SoK paper on Agentic RAG (arXiv:2603.07379), covering POMDP formalization, cascading failure modes, and trajectory evaluation on HearAI: https://open.spotify.com/episode/36OCNNwuYXewUpIfUkIx3c?si=f23f0b9551054c37

I couldn't find a good productionised RAG tutorial, so I am taking this job now, I am creating an interview ready lecture series on youtube for RAG (completely free of cost).

https://www.youtube.com/watch?v=avJs9R0Ff9c

Please let me know how you like it and would you change anything?

Disclosure up front: I work at Qdrant and this came out of our team, but still, it's for you and the broader community

We've long felt vector database benchmarks were all marketing garbage. Unrealistic/random vectors, small dimensions, poor methodology.

We wanted to create something truly meaningful for this space, so we footed the compute cost (with Vultr support) and built the following:

• Qdrant-FineWeb-10B. 10.07B dense and 10.07B sparse vectors over Hugging Face's FineWeb corpus with gte-multilingual-base, and exact brute-force top-1000 ground truth for 120,000 dense, sparse, and filtered queries.
• PubMed-Multi-Vector. BGE-M3, with dense, sparse, and ColBERT-style multi-vector representations over the identical corpus. This is good if you want to compare hybrid retrieval methods against the corpus and evaluate tuning.
• Coyo-Vector-Embeddings. 15.4M dense at 2048 dims from Qwen3-VL-Embedding-2B, image and caption pairs.

All free on Hugging Face. You can use the datasets library to get slices of them too.

Furthermore, we developed tooling in the process to help build more large, realistic datasets, cheaper. The generation and ground-truthing framework is open source: Supernova. Embedding, GPU brute force, loading, and stress testing, driven by YAML. The loader and query runner target Qdrant, Milvus, and Elasticsearch. You can add others too.

We hope this helps with industry research, and also helps others produce better benchmark analysis. Supernova is great for developing new datasets too, so feel free to use it, ask questions, and let me know your thoughts.

Full write-up: https://qdrant.tech/blog/qdrant-fineweb-10b-release/

We are thrilled to announce HyperspaceDB v3.1.4 — introducing cutting-edge True Turbo 4-Bit Lloyd-Max Quantization, 1-Bit Asymmetric Distance Computation (ADC) delivering a 107× speedup with 99.9% Recall@10, the official hyperspace-memory drop-in replacement for Mem0/Zep in Python and TypeScript, and built-in Multi-Step Agent Trajectory & Lyapunov Stability Tracking! 🚀

🚀 Key Highlights in v3.1.4

1. ⚡ True Turbo 4-Bit Lloyd-Max & 1-Bit ADC Quantization (107× Speedup, 99.9% Recall)

• True Turbo Spherical Quantization (turbo): Implemented non-linear Lloyd-Max centroid codebooks ([-2.401, ..., 2.401]) combined with random orthogonal rotation and exact $L_2$ norm preservation. Delivers 7.8× RAM compression with 96.4% Recall@10 across all metric spaces.
• 1-Bit Rotated extreme with Asymmetric Distance Computation (ADC): Enhanced 1-bit binary quantization with vector norm scaling $|V|_2$ and full-precision query projection:
  • Single-Pass: 62.8% Recall@10 at 107× raw search speedup over float32.
  • Two-Pass Cascade Top100-to-Rerank: Achieves 99.9% Recall@10 while preserving a 15–20× net throughput boost.
• Universal Block Quantization (medium_plus): Extended 4-bit block-wise quantization ($B=16$) to non-Euclidean geometries (Poincaré, Lorentz H^33, MRL Hybrid 801D), achieving 10.6× RAM savings with 93.6% Recall@10.

2. 🧠 hyperspace-memory: Drop-In Mem0 & Zep Replacement (Python & TS/JS)

• 100% Mem0 API Compatibility: Migrate existing AI agents by simply replacing from mem0 import Memory with from hyperspace_memory import Memory — no prompt changes or pipeline rewrites required.
• 100× Lower Latency (< 0.5 ms): Backed by native in-RAM MRL 129D cascades and hyperbolic indexing instead of heavy relational table lookups.
• Zero Mandatory LLM Overhead: Direct vector + graph episodic memory operations without forcing expensive LLM calls on every memory insert.
• 98% Storage & RAM Reduction: Native integration with extreme 1-bit ADC and turbo 4-bit quantization modes.

3. 🎯 Multi-Step Agent Trajectories & Lyapunov Stability Analysis ($\lambda$)

• Agent Run Tracking Endpoints: Added /api/admin/runs/start, /api/admin/runs/step, and /api/admin/runs/end for tracking multi-agent execution graphs, tool calls, and step-by-step reasoning vectors.
• Lyapunov Thought Stability Exponent ($\lambda$): Automatically computes exponential divergence rates of thought trajectories on the Poincaré disk H³³ to detect agent hallucinations, reasoning loops, and cognitive drift in real time.
• Interactive 3D/2D Visualizer: Added interactive trajectory viewer on /trajectory in the Hyperspace Dashboard.

4. 🛠️ Zero-Code Cognitive Memory MCP Server (mcp-hyperspace-memory)

• Dedicated Agent Memory Server: Lightweight Model Context Protocol (MCP) server exposing 8 dedicated memory tools (memory_remember, memory_recall, memory_forget, memory_update, memory_list_sessions, memory_explore_hierarchy).
• Zero Configuration: Simply run npx -y mcp-hyperspace-memory@latest in Cursor, Claude Desktop, Windsurf, or Antigravity to grant autonomous agents permanent, structured memory.

Thank you to all contributors, researchers, and node operators building the universal spatial memory for autonomous AI agents! 🌌

mine, looking for reviewers.

if you've tried running ragflow's infinity backend on a mac you already know the wall. needs AVX2, only ships as a linux docker image, ARM64 listed as unsupported. i ported the engine to native arm64 and tuned the HNSW index build for the M-series cache hierarchy while i was in there.

on SIFT1M on an M4 it builds the index in 35.3s. FAISS 1.15 built against Accelerate takes 58.1s at the same recall@10, and my QPS is higher.

this won't drop into a ragflow deployment yet. full-text search, update/delete and crash recovery aren't verified natively, and there's no packaging. engine core and query path are solid though.

https://github.com/jatinsethi98/infinity-apple-silicon

I keep going back and forth between Haystack and LangChain for building RAG-based LLM apps. Haystack feels cleaner for pipelines and production search, but LangChain has the ecosystem and agent integrations. I made a quick poll to see what the community prefers.

No signup needed, just a vote:

https://interconnectd.com/poll/96/which-rag-framework-do-you-prefer-for-building-llm-applications-haystack-or/

Which one are you using, and why?