I have finished a RAG system with a demo account and wanted to ask how to find work, and the rules reference a link to a Discord group for job requests, and the link does not seem to work. Can anyone point me to resources finding clients, or any helpful insight in how to do so? Thank you.

Following up other recent posts also about the same issue.

About 1 year ago we established RAG quality monitoring where in particular we tracked content precision and recall using Ragas. But recently we discovered a significant degradation in this, and the root cause was removal of a bunch of docs belonging to another track (don’t ask me why, just corporate work moments).

It was the moment we realised that we need somehow to track data quality itself, and not something we see as in/out. Some metrics that we consider we colud track:

- Staleness - how many of vector embeddings contain outdated information
- Orphaned embeddings - how many of vector embeddings point to data sources that no longer exist
- Deleted-but-retrievable - how many times RAG returns vector embeddings that we actually (we think) deleted from RAG

I see it as kinda scheduled job that does this assessment although it needs quite some time to write and test it. Any advice on what we can use?

Yesterday I nearly declared a production retrieval emergency that didn't exist, and the mechanism is general enough that anyone running hybrid search should check for it.

**Setup:** hybrid retrieval over personal memory — vector similarity + BM25, fused with Reciprocal Rank Fusion, optional cross-encoder rerank on top for some tiers. Every search logs `top_score` for quality monitoring.

**The scare:** analyzing 10,706 logged searches, I applied the obvious threshold — top_score < 0.3 = weak retrieval. Result: 62% "failures," a dozen users at "100% failure with avg score 0.017," and a terrifying month-over-month "degradation" trend. One of the "100% failed" users was a paying customer with a thousand searches. I was halfway into incident mode.

**The tell:** a search for an exact entity name — a guaranteed hit — logged top_score 0.0426. And those "failing" users all averaged 0.016–0.021. Then it clicked: RRF scores are 1/(k + rank) with the standard k=60. Top rank = 1/60 ≈ 0.0167. My "catastrophic" users weren't failing — **their top result was rank-1 almost every time.** avg 0.017 is what perfect RRF retrieval looks like.

What actually happened: requests that go through the reranker log cosine-style scores (0–1 scale, 0.3+ = good). Requests on the raw RRF path log fusion scores (0.016–0.05 scale, where 0.017 = excellent). Both landed in the same `top_score` column with no scale tag. Every aggregate over that column — means, z-scores, my failure thresholds, even the health monitoring cron — was averaging apples with orbital velocities. The "month-over-month degradation" was just the RRF-path share growing as more traffic moved to hybrid.

**What survived scale-correction:** true failure (zero results) was 9–13%, driven mostly by two accounts whose agents were querying literally empty stores — a real integration problem, but a completely different one than "retrieval is broken."

**Lessons, generalized:**

1. **A fused ranking score is not a similarity.** RRF outputs rank information, not confidence. The moment you fuse, your score's absolute value stops meaning what your dashboards think it means.
2. **Never store scores from different scoring regimes in one unlabeled column.** Log a `score_kind` (or a scale-aware quality label computed at write time, which is what we shipped: strong/weak/no_match with per-scale bands). Analysis-time guessing is how you get 3am false incidents.
3. **The only scale-free failure signal is emptiness.** Zero results means the same thing on every path. When in doubt, count zeros, not thresholds.
4. **Validate your alarm against a known-good query before believing it.** One exact-match search that "scored 0.04" saved me from paging myself.

Sources for the RRF math: Cormack, Clarke & Buettcher (2009), "Reciprocal Rank Fusion outperforms Condorcet and individual rank learning methods" — the k=60 default everyone inherits comes from there.

Disclosure per rule 3: the production system is Mengram (mengram.io), a memory layer for AI agents — but the trap applies to any RAG stack mixing rerankers with fusion scoring. Nothing here requires my product to check: grep your score column and look for a bimodal cluster around 1/60.

Hi folks - for context I'm a solo-founder and have spent a few years working on variants of the "company brain" (i.e. a knowledge base across Drive/SharePoint/internal docs that can be queried and kept in sync). Wanted to share some learnings from my own trial-and-error at QX Labs.

There's a consensus that knowledge graphs are needed for serious systems, but tbh GraphRAG and use of full-blown graph databases like Neo4j is complete overkill for most cases. I ended up building a more practical/attainable solution that takes the ideas behind GraphRAG and implements them in a simpler and cheaper way. Hopefully it will save you the grief if you're working on similar things!

You just need a regular DB (Postgres, MongoDB, whatever you already use) and a search index (Azure AI search, Elastic, Qdrant - to handle hybrid vector + text search).

Why not vanilla RAG

Top-k RAG retrieval handles "find this specific fact" queries well (I refer to these as 'needle' questions). But it structurally cannot handle two other question shapes that come up regularly in practice:

• "Tell me everything about X" (needs the complete document set for an entity, not the top k passages)
• "Which fintech companies have we evaluated?" / "how many contracts mention X?" (needs an exact list/count over the corpus; no value of k fixes this)

Why not use GraphRAG

• Indexing cost. Microsoft were the ones who first proposed GraphRAG but they archived their solution accelerator for it. Their research states that vector-RAG indexing is <0.1% the cost of a full GraphRAG index. It's also telling that Azure AI search still isn't built around graphs.
• Research literature (e.g. "RAG vs GraphRAG", arXiv:2502.11371) also shows mixed results: graphs help on multi-hop/global summarization, vanilla RAG wins on direct lookup, and routing between them beats either.
• Entity resolution is hard and a lot of tools don't handle this well. If "Acme" and "ACME Holdings Inc." don't merge, the graph fragments. If they merge wrongly, errors compound transitively and silently. A lot of compute gets spent correcting these mistakes in a graph DB.
• A graph DB is another system to run, secure, back up and keep consistent per tenant.

What I built instead (a graph-like system inside a regular DB)

Entities and edges exist as ordinary records in the search index + document DB we already run. No graph database.

• We use a small fixed ontology, which is the same for everyone: organization, person, product, project, event, location, etc., plus label fields (industry/category/topic). In our case we wanted to make it self-serve (i.e. doesn't require people to set up custom ontology) so were happy to trade off simplicity for specificity.
• Entity resolution follows a waterfall (to minimise cost): first we look up against an alias table (every variant of word/phrase that's been used for an entity in the past - free and fast). Next, we embed the word/phrase and do a similarity lookup. Last, we use a cheap LLM to adjudicate but only for ambiguous candidates. Merges are just an alias re-pointing on a hub record, so every merge is easily reversible (we run a daily cleanup job to true things up). We also tend to bias against over-merging: a false merge poisons things downstream, whereas a miss just fragments the data until the daily job fixes it.
• Edges in our system are not real edges between nodes, they're co-occurrence counts (i.e. these entities appear frequently together). They are represented as a top-N list on each entity record. Not typed relations, which is a deliberate trade-off that we make.
• Entity summaries are lazy (built on first request, cached), straight from the LazyGraphRAG lesson. Costs scale with what people ask about, not corpus size.
• The agent has access to four tools to handle different types of retrieval scenarios: hybrid passage search (default), resolve (extract everything-about-X with filters applied), expand (one hop along co-occurrence), and facet (exact counts/lists via the search engine's aggregations). The counting questions that top-k can never answer become deterministic facet queries.
• Daily consolidation trues everything up (re-adjudicates uncertain merges, recomputes edges exactly, prunes deleted docs), gated so unchanged corpora cost zero.

Did it work?

We set up an evaluation harness to track performance (~1,000-doc corpus, with graded questions across needle/entity/multipart/aggregation/thematic classes - I'll probably write about this separately when I get time). Needle questions already performed very well with vanilla RAG but all other question classes improved meaningfully with this pseudo-graph approach.

Limitations of this approach

• No multi-hop path reasoning. The agent loops one hop at a time if it wants depth, but this can bloat context. Graph DBs can more reliably find tenuous connections across multiple hops without exploding context.
• Co-occurrence is not the same as typed relationships. We know two entities appear together, not why. In a normal graph DB you'd have e.g. WORKS_FOR, INVESTED_IN, CUSTOMER_OF etc. The problem is that relationship types can vary a lot by use case.
• Conservative merging means occasional temporary duplicates.
• True "summarize the themes of the whole corpus" global questions are still better served by community-detection approaches I deliberately didn't build. Full GraphRAG will still deliver higher quality there.

For ref I have a full write up on how it works here: https://www.minimumviablefounder.com/p/why-ai-company-brains-fail

Keen to exchange notes on this, or hear if you've had a more positive experience with GraphRAG.

Hey everyone! I’m building a multimodal RAG pipeline where Mistral OCR annotates images before they go into a vector store with document text.

Issue: Mistral OCR processes images in isolation, so the annotations miss out on critical document context.

Looking for advice on:

Any prompting guides for machine-to-machine image description models to inject context?

Any alternative models or workflows that natively factor in surrounding document context?

Would love to know how you all handle this!

If you are running local LLMs, your hard drive is likely bleeding gigabytes without you realizing it. Between default model weights, duplicate quantization formats, and forgotten vector embeddings, local AI setups are silent storage hogs.

Here is how you can systematically track down and clean up the clutter directly from your terminal:

• Locate hidden Hugging Face and Ollama model weights: By default, Hugging Face caches everything in ~/.cache/huggingface/hub and Ollama stores models under ~/.ollama/models. Run du -sh ~/.cache/huggingface/ to see how much space is currently locked up.
• Prune redundant quantization formats and unused embedding databases: Review your downloaded models and delete redundant variations (like keeping both Q4_K_M and Q8_0 when you only use one). Clear out stale Chroma, FAISS, or Pinecone local vector database caches residing in your project directories.
• Automate routine garbage collection: Set up a lightweight shell script to periodically check cache growth and alert you before your drive hits capacity.

Fore More Information

I put together the complete, production-ready automated cleanup script along with an interactive storage calculator to help map out your directories.

Direct links to the complete article.

drop a comment below

I’m building DStudio, an open-source desktop app centered around DeepSeek V4. DeepSeek remains the main reasoning model and manages the conversation, while smaller local models handle specialized tasks:

- Qwen2.5-VL reads images
- Qwen Image generates and edits images
- Qwen3 Embedding searches documents semantically
- Poppler extracts PDF text and page information

This ecosystem exists because DeepSeek V4 is excellent for reasoning and long context, but loading every multimodal capability inside the same large model would be inefficient. DStudio routes tasks to specialized models and then returns their results to DeepSeek for the final answer.

I recently added long-PDF retrieval. DeepSeek decides whether to create an overview, read an exact physical page or search the entire document. For semantic search, DStudio creates and caches one embedding per page, retrieves the six most relevant pages and sends only those to DeepSeek.

On a 1,000-page test PDF, it found a passage placed on page 777 from a paraphrased question. Initial indexing took about 25 seconds; later searches took around 0.23 seconds.

I’m looking for feedback: should retrieval use page embeddings or overlapping chunks? Should I add BM25 or a reranker? And how would you efficiently support scanned 1,000-page books?

https://github.com/sk8erboi17/DStudio

Hi everyone,

I'm building a production RAG system focused on scientific research papers (desalination, chemistry, membranes, engineering).

Current setup:

• ~17,367 PDF papers
• Around 25 GB of PDFs
• Qdrant vector database
• Hybrid search (Dense + BM25)
• Cross-encoder reranking
• Gemini 2.5 Flash for answering
• Chunk size: ~250 words with overlap
• Rich metadata
• Images and tables extracted separately

I'm currently using OpenAI text-embedding-3-large, but before indexing the entire corpus (~17k papers), I want to make sure I'm choosing the best embedding model because switching later would require a complete re-index.

I'm mainly optimizing for:

1. Retrieval quality (most important)
2. Scientific / technical terminology
3. Numerical accuracy
4. Long-term maintainability
5. Storage efficiency
6. Indexing speed
7. Cost (secondary)

Models I'm considering:

• OpenAI text-embedding-3-large
• BGE-M3
• gte-large-en-v1.5
• Jina Embeddings v3
• Nomic Embed Text
• Voyage AI
• Any other recommendations?

Questions:

1. Which embedding model currently gives the best retrieval quality for scientific literature?
2. Has anyone benchmarked these models specifically on academic PDFs instead of generic MTEB?
3. Would you still choose OpenAI today if cost wasn't the primary concern?
4. Is there any newer embedding model released recently that clearly outperforms these?
5. If you were starting a new large-scale RAG system today, which embedding model would you choose and why?

I'd really appreciate hearing from people who have tested these models in production rather than benchmark scores alone.

Thanks!

This is the context:

Hi, so I've made a corrective rag pipeline that goes from ingesting documents to retrieving files, reranking, using a LLM model to decide if the documents returned are okay and selecting the ones to use to generate an answer. It is a pipeline to help service desk employees to better answer tickets. It's around 1000 articles of documentation, most of them with 1000 tokens. I've chunk to max of 512 tokens per chunk. There are also some rest full api docs, that show the parameters.

Overall, even though the documentation is lacking and a bit outdated, it manages to retrieve and answer.

For this, I'm using some small models (8b) for answers, due to current constraints; I may be given access to a better model with API if I manage to show why and how this can be an asset.

Some details about why this was done:

The quality of the answer our clients get, depends a lot on who the agent answering is. We have a lot of knowledge gaps and many things that people don't know how to answer. This was a movement to try to address and allow them to give better answers

Some minor details:

I've been given this task even though it's outside my area because I was already looking into it, but I'll have to make a presentation soon. Unfortunately the base was done with IA before I got it and it made some weird choices, some that I couldn't simply take it back without redoing everything

My doubts are (if you guys can give me a direction, may it be scientific articles, docs, wiki... I would appreciate it)

1 How could I ingest the service desk tickets and issues from azure DevOps? Most of them lack a clear answer, so I would like an idea of a standard to propose for the answers, since ingesting now seems like it would make more noise for the retrieval

2 One thing that they want is to use an agent to connect onto the clients DB to analyze problems and situations passed by the client, but I'm unsure of the best way to do it.i would appreciate a direction

3 overall, what is a good strategy to deal with more articles? I feel like the documentation is very similar from one article to another and not in depth enough

4 any other tips to give me, would be appreciated

Thanks and sorry for the long text

I put together a small Python/Flask example for searching support tickets by meaning instead of exact keywords.

It uses Telnyx AI Inference embeddings to turn ticket text into vectors, stores them in memory with numpy, and ranks results with cosine similarity.

The app includes:

POST /index to embed and index tickets

POST /search to search by meaning

POST /tickets to add a new ticket

GET /stats to inspect the index

a bundled sample support-ticket dataset

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/semantic-search-python

Useful for support search, duplicate ticket detection, internal knowledge search, or as a first step before moving to pgvector/Qdrant/Weaviate/Pinecone.

Any feedback welcome.

Hey everyone, I need some help.

I'm working on a RAG-based project and I'm looking for customer support knowledge base documents.

For example, if it's a banking customer support team, do they have internal documentation that covers product details, policies, FAQs, troubleshooting steps, workflows, etc.?

If there are any publicly available knowledge bases or datasets, I'd really appreciate it if you could share them.

Also, if you work in customer support (banking, sales, telecom, e-commerce, SaaS, etc.) and have any sample documentation that you're allowed to share (after removing any confidential information), I'd be grateful if you could share that as well. It would be a huge help for learning and experimentation.

Thanks in advance!

need some ideas for projects that would look great on resume and i can also publish a research paper pls helpp...

We kept getting asked internally which of these to pick, semantic model, knowledge graph, RAG, plain markdown, open format, so instead of guessing I actually went and pulled the research on each.

Every vendor selling one of these will tell you it's the answer. It usually isn't, not on its own. Each one solves a different failure mode, and the wrong pick doesn't make an agent fail loudly. It just answers confidently and wrong.

RAG's still the right default for fact lookup across a big, loosely structured corpus, contracts, tickets, docs. That said, Chroma tested 18 frontier models in 2025 and found accuracy degrades unevenly as retrieved context grows. Even one distractor passage measurably hurt performance, so more retrieval isn't automatically better retrieval.

Knowledge graphs are the one people over-invest in before they actually need it. They're genuinely good at multi-hop reasoning, "who reports to whom, and which of them also churned," and Microsoft's 2024 research had GraphRAG beating plain vector RAG 72% of the time on comprehensiveness. But if your questions are single-fact lookups, you're paying graph-maintenance costs for nothing.

Semantic models are the one that actually moved my opinion. dbt Labs ran a 2026 benchmark where agents querying a governed semantic layer hit 98-100% accuracy on business questions. Same models writing raw text-to-SQL against the full schema: 84-90%. Same model, just given a definition instead of a guess.

And then there's markdown plus grep, which sounds almost too simple to be real advice. For a small, well-organized corpus it's genuinely fine. No vendor will ever pitch you this one, since none of them sell it.

Most teams land on two or three of these, not one. Full writeup with all the sourcing: https://www.revos.ai/blog/structuring-data-for-ai-agents

Curious what combination people here have actually landed on, and what pushed you off your first choice.

posted here a little while back about stale embeddings after doc edits, got a lot of good info from that thread so figured i'd ask here again.

working on a RAG setup for some internal docs and a chunk of them have tables mixed in with regular paragraphs (like a section of text, then a table, then more text). my current chunker just splits by character count so it sometimes cuts a table in half or merges it weirdly with the paragraph before/after it.

do people usually handle tables as a separate chunk type entirely? or convert them to some kind of markdown/text representation first and then chunk normally? curious how much this actually matters for retrieval quality vs. just being a nice-to-have

still fairly new to this so not sure if this is a solved problem with a standard approach or something everyone just handles differently depending on their data

Hey!

I wanted to tell you about a project that's been going on for a while.

We (I use “we” because, since it's open source, I see it as something that belongs to the community rather than something personal) built Skeg because we got tired of the usual painful trade-offs in the vector database space. Most solutions force you to choose between high recall, reasonable memory usage, or actually staying fast when the workload gets real (sustained ingest, multi-tenancy, memory pressure, etc.).

Skeg takes a different approach.

It is disk-first: full vectors live on storage, while only small, carefully quantized indexes stay in RAM. This gives excellent recall at a fraction of the memory footprint compared to traditional in-memory engines. It is especially strong in environments where RAM is contested — think SaaS platforms with hundreds or thousands of tenants, RAG systems running next to large language models, or even embedded/edge scenarios.

Key design principles:

• Strong multi-tenancy by construction (true isolation, hard quotas, fair cache eviction)
• Redis-compatible protocol for easy adoption
• Very good performance on ARM (we invested heavily in platform-specific optimizations and SIMD)
• Focus on production predictability: it handles churn gracefully without sudden latency spikes

We wrote it in Rust for the usual reasons: performance, reliability, and control over every detail that matters when you care about efficiency.

The project is open source and we’re actively developing it. If you work with semantic search, recommendations, RAG pipelines, or any kind of similarity search and you care about memory efficiency and operational simplicity, I think Skeg might be interesting for you.

Repo: https://github.com/skegdb/skeg

I’d genuinely love to hear your thoughts or what problems you’re currently facing with vector databases.

Any feedback or support is welcome.

Thank U

English isn't my first language, so if anything isn't clear or sounds strange, please excuse me.

Sharing this here since it's directly relevant to what gets discussed in this sub. It's a hands on session on August 8, led by Brian Bønk, a Data Platform MVP and Microsoft FastTrack Solution Architect.

It covers the full RAG pipeline, ingestion, chunking, metadata enrichment, indexing, and vector search, then goes deeper into retrieval quality engineering specifically, precision, recall, latency trade offs, and actual tuning strategies instead of just defaults. There's also a section on evaluation and governance, building test harnesses and regression checks, and an extension pattern on knowledge graphs for cases where similarity search alone can't capture relationships between entities. There's also a piece on using Fabric and Power BI to surface grounded answers in a way business teams will actually adopt.

It's aimed at people building or maintaining RAG systems that need to hold up against real, messy enterprise data rather than a clean demo. You come out with an actual rollout plan rather than just slides.

Link for anyone interested: https://www.eventbrite.co.uk/e/design-enterprise-grade-rag-systems-with-llms-vector-search-tickets-1992561384740?aff=rrag

Hi everyone,

I've been working on an open-source project called Aktilot, an AI workspace focused on engineering teams.

This week I added GitHub connector support, so Aktilot can securely connect to repositories and answer questions using repository context.

Some examples:

• Explain this repository architecture.
• Find where authentication is implemented.
• Summarize recent changes.
• Answer questions about the codebase.

The long-term goal isn't to build another chatbot, but to create an AI workspace that understands an engineering team's knowledge across GitHub, documentation, tickets, and collaboration tools.

I'm currently planning connectors for:

• Jira
• Confluence
• Slack
• Google Drive

I'd genuinely appreciate feedback from the OSS community.

What engineering integrations would you find most useful?

GitHub: https://github.com/vikas0686/Aktilot
Website: https://aktilot.com

Been wanting to build this for a while, finally sat down and did it. It's a Flask app where you upload a PDF, it chunks and embeds it, and then you can ask questions and get answers pulled only from that document, not from the model's own training data.

Stack is pretty simple: Ollama for the chat model and the embedding model, ChromaDB as the vector store, Flask tying it together. Nothing exotic.

How it works, roughly:

• PDF gets split into overlapping chunks so sentences don't get cut off between pieces
• Each chunk gets turned into an embedding and stored in Chroma with PersistentClient, so it's saved on disk instead of disappearing every time you restart the app
• When you ask something, the question also gets embedded, Chroma finds the closest matching chunks, and those get handed to the model as context
• Prompt explicitly tells the model to only use that context and say it doesn't know if the answer isn't there, otherwise it'll just make something up from its own memory

Tested it by asking something not in the PDF and it correctly said it didn't know instead of guessing. Also tested with wifi off and it kept working, since the model, embeddings, and vector store all run locally with no external api calls in the loop.

Hi everyone,

I'm working on extracting the hierarchical structure of long PDF documents (legal/regulatory text, lots of numbered sections) and would like to gather some feedback on my approach before committing to it.

What I've done so far: I render each PDF page to an image and run it through Baidu's DeepSeek-OCR model. It returns each detected block with a bounding box [x0, y0, x1, y1], a label (title, text, list, table, header, footer, etc.), and the recognized text. The OCR quality itself is genuinely good as the text comes out clean.

The problem: the labels can't always be trusted. At this stage I want to extract and detect all the titles in my document, but sometimes a title element gets classified as something else (like normal body text).

Concrete example:

Say my section has the following hierarchy:

ANNEX I — GENERAL PRINCIPLES AND PROCEDURES
└── TITLE I — FOREIGN CURRENCY INVESTMENT
    └── A. Currency distribution
        └── 1. Redistribution of reserves
            ├── (a) Introduction
            │       body text
            │       list
            │       ...
            ├── (b) Procedure for a normal redistribution of reserves
            │       body text
            │       list
            │       ...
            └── (c) Procedure for an ad hoc redistribution of reserves
                    body text
                    list
                    ...

Logically, every element aside from the body text and lists should be detected as title. But the model output is:

label='title'  x0=475  y0=157  x1=548  width=73   text='ANNEX I'
label='text'   x0=480  y0=229  x1=542  width=62   text='TITLE I'
label='title'  x0=334  y0=181  x1=690  width=356  text='GENERAL PRINCIPLES AND PROCEDURES'
label='title'  x0=407  y0=368  x1=616  width=209  text='A. Currency distribution'
label='title'  x0=408  y0=392  x1=634  width=226  text='1. Redistribution of reserves'
label='title'  x0=163  y0=416  x1=304  width=141  text='(a) Introduction'
label='title'  x0=163  y0=544  x1=578  width=415  text='(b) Procedure for a normal redistribution of reserves'
label='title'  x0=163  y0=219  x1=586  width=423  text='(c) Procedure for an ad hoc redistribution of reserves'

The top-level section marker TITLE I was labeled text, while all the other components were labeled correctly as title.

What I'm considering: since I have the text plus features I can derive from the coordinates (indentation/x0, centered-vs-left-aligned, line height, vertical gaps, whether the text matches a numbering pattern like A. / 1. / (a), all-caps, word count, etc.), I was thinking of treating this as a sequence labeling problem and training a CRF (or BiLSTM-CRF) to re-classify each line into title / text / list / table.

My questions:

• Is a CRF a reasonable choice here, or is there a better-suited approach for this kind of layout/structure labeling?
• Should I consider a GNN approach?
• Am I overcomplicating this? Would a simpler rule/heuristic system be more robust, given that the numbering is fairly regular?

Note #1: this approach should be as general as possible, so that I can reuse it for my other legal documents.

Note #2: titles aren't always in the same horizontal position. Some are centered (e.g. ANNEX I, TITLE I, A. Currency distribution all sit around xc≈511, the page center), while deeper items like (a)/(b)/(c) are left-aligned at x0=163. So I can't rely on indentation/x0 alone to identify or rank titles — a centered title's x0 mostly reflects its text length (a short centered line has a large x0, a long one a small x0), which means raw x0 can even invert the apparent nesting. This is part of why I'm leaning toward a sequence model that combines text + geometry in context rather than a pure indentation rule.

I run a trade intelligence service that pulls corporate event news from Korean (OpenDART), Japanese (EDINET), Hong Kong exchange notices (Chinese), and English wire services. When the same merger announcement lands across all four sources, my knowledge graph ends up with four separate Event nodes for one real-world incident.

The naive fix is string similarity between event summaries. It breaks for two reasons. First, a Korean summary and an English one share almost no tokens even when they describe the same event. Second, two genuinely distinct events between the same companies (a supply contract and a separate lawsuit filed the same week) can share most of their vocabulary. String matching cannot tell coincidence from coreference.

What I built is a two-stage resolver that runs read-only against the graph. Stage one forms candidate event pairs using rule-based filters: shared canonical entity, date buckets within 72 hours, matching event type or Jaccard token overlap threshold. This stage is cheap and keeps the LLM bill bounded. Stage two sends each surviving pair to a model for a three-way verdict: same, related, or distinct. Only "same" verdicts feed into union-find clustering.

The three-way label is the part that mattered most in practice. Collapsing "related" into "same" would merge a contract announcement with a lawsuit between the same two firms. Collapsing it into "distinct" would scatter genuine follow-on coverage across jurisdictions. Union-find handles transitivity on discrete verdicts rather than having the model reason over a whole group at once.

The 72-hour window is the part I trust least. Cross-border coverage of the same incident usually lands within three days, but slow regulatory follow-ups can arrive a week later and get missed. Widening the window quadratically inflates candidate pairs. I chose the cheaper side for now.

Full write-up including the resolver design and why the 72-hour constraint is a genuine tradeoff: https://hannune.ai/blog/cross-document-event-coreference-east-asia

For anyone doing local RAG: a lot of "save this for later" tools push you toward cloud embeddings. This is the opposite - a browser extension + local daemon that captures a page, chunks it, embeds it locally, and pushes vectors into your vector store.

Architecture and reasoning (including the daemon vs extension split) are in the README: https://github.com/Adithyaa71/snarevec

Right now it's one-page-at-a-time web capture, but the next version is close and adds a fair bit:

>>Drag local files, PDFs, and raw data straight into the clip dialog and embed them alongside web pages.

>>Batch embedding - select multiple pages/sources and embed them together in one pass instead of one by one.

>>(exploring) a unified "collection" view so a set of related sources embeds into the same namespace.

Would love feedback on two things specifically: the chunking strategy (the part I'm least confident is optimal right now), and what you'd want out of the batch/local-file flow before it ships.

hey all, first post here (made this account just to ask this lol). i'm pretty new to RAG in general, been learning as i go the past few weeks.

so i built a simple RAG setup (chunking + embeddings + vector db, using langchain) for our internal docs. it works fine at first but whenever someone edits one of the source files, the chatbot still answers with the old info for like... a while? sometimes it never updates unless i manually rerun the whole ingestion script from scratch.

is this just how RAG works and i have to re-embed everything every time something changes? that seems really inefficient if you have thousands of docs and only one paragraph changed. or is there some way to only update the chunks that actually changed?

sorry if this is a dumb question, still trying to wrap my head around a lot of this. just trying to understand if i'm missing a step or if this is a known limitation people work around somehow

User-uploaded content is useful, but it creates a difficult trust problem.

A document may contain:

• Hidden prompt injection
• Misleading instructions
• Malicious links
• Sensitive information
• Encoded content
• Instructions aimed at future users
• Text that attempts to manipulate retrieval
• False information written to look authoritative

Basic malware scanning does not solve this.

The file may be technically clean while the text remains adversarial.

A safer ingestion workflow may need:

• File-type validation
• Content sanitization
• Access controls
• Source labeling
• Quarantine before indexing
• Human approval
• Trust-level metadata
• Separate vector collections
• Expiration policies
• Continuous monitoring

Would you completely isolate user-uploaded content from trusted internal documents, or rely on metadata and filtering inside one knowledge base?

Inspired by Andrej Karpathy's autoresearch, I built autoretrieval to apply the same idea to RAG optimization.

The project gives an AI agent a RAG pipeline, an evaluation dataset, and a target metric. The agent modifies the pipeline, runs an eval, checks if the F2 score improves, and keeps or discards changes automatically.

The evaluation dataset can be generated from your own documents, creating question and reference-highlight pairs for your domain.

The agent can test changes to chunking, embedding models, keyword filters, and retrieval logic while keeping a record of every experiment.

The goal is to let an AI agent handle the repetitive trial and error involved in improving a RAG system.

This was successful at more than doubling the F3 score of an already optimized RAG pipeline in a couple hours.

Give it a try here: https://github.com/daly2211/autoretrieval