[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-qdrant-filter-first-rag-design-decoded-en":3,"article-related-qdrant-filter-first-rag-design-decoded-en":30,"series-tools-d1e26605-8b72-4be1-833e-c57583968f37":82},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"d1e26605-8b72-4be1-833e-c57583968f37","qdrant-filter-first-rag-design-decoded-en","Qdrant’s filter-first RAG design, decoded","\u003Cp data-speakable=\"summary\">I turn Raunaq’s vector DB comparison into a copyable filter-first \u003Ca href=\"\u002Ftag\u002Frag\">RAG\u003C\u002Fa> setup.\u003C\u002Fp>\u003Cp>I've been building RAG systems long enough to know when the stack is lying to me. The demo works, the embeddings look fine, the similarity scores look tidy, and then the first real filter shows up and the whole thing starts behaving like a raccoon in a server rack. I ask for a user’s documents, or a date range, or one source only, and suddenly retrieval gets weird. Sometimes I get too few chunks. Sometimes I get the wrong chunks. Sometimes everything is “technically correct” and still useless.\u003C\u002Fp>\u003Cp>That’s the part people keep skipping. Vector search is not just “find the nearest neighbors.” In production, it is “find the nearest neighbors inside a subset.” That one extra sentence changes everything. I’ve watched teams bolt metadata filters onto a vector index like it’s a checkbox, then spend weeks wondering why recall tanks under multi-tenancy or why query latency turns into a lottery. It’s not a tuning problem. It’s an architecture problem.\u003C\u002Fp>\u003Cp>Raunaq’s \u003Ca href=\"https:\u002F\u002Fraunaqness.substack.com\u002Fp\u002Fvector-databases-for-rag\" target=\"_blank\" rel=\"noopener noreferrer\">Vector Databases for RAG\u003C\u002Fa> is the cleanest write-up I’ve seen on that exact tension. He compares \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\" target=\"_blank\" rel=\"noopener noreferrer\">pgvector\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fwww.trychroma.com\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">ChromaDB\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fqdrant.tech\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Qdrant\u003C\u002Fa> through the lens that actually matters: what happens when your vector query has to respect metadata too. He doesn’t hand-wave it. He breaks down the indexing tradeoffs, the failure modes, and the cases where each system quietly falls over.\u003C\u002Fp>\u003Ch2>The real problem is not similarity, it’s subset similarity\u003C\u002Fh2>\u003Cblockquote>“A real-world vector search isn’t just ‘find similar vectors’ — it’s ‘find similar vectors within a subset.’”\u003C\u002Fblockquote>\u003Cp>What this actually means is that your retrieval layer is always doing two jobs at once: semantic ranking and scope enforcement. If I’m building a customer support assistant, I don’t want the most similar ticket in the entire company. I want the most similar ticket from this tenant, this project, this time window, maybe even this document type. That scope is the whole game.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780566507204-rtv6.png\" alt=\"Qdrant’s filter-first RAG design, decoded\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Raunaq’s framing matters because it explains why so many RAG systems feel fine in a notebook and then become annoying in production. The moment I add a filter like \u003Ccode>user_id = X\u003C\u002Fcode>, I’ve created a second retrieval problem. The vector index knows about meaning. The metadata index knows about rows. They do not naturally cooperate. That’s the tension.\u003C\u002Fp>\u003Cp>I ran into this hard on a multi-tenant knowledge base project. The “good enough” prototype used a single vector table and a metadata column for tenant ID. It worked until one tenant had 100x more documents than the others. Then recall got unpredictable. Queries that should have returned 10 chunks would return 3, or 4, or 10 if I got lucky. Nothing in the logs screamed failure. The database was doing exactly what I asked, which is the annoying part.\u003C\u002Fp>\u003Cp>How to apply it: before you pick a vector store, write down the subset \u003Ca href=\"\u002Fnews\u002Fsec-draft-plan-puts-crypto-rules-first-en\">rules first\u003C\u002Fa>. Not the embedding model. Not the chunk size. The subset rules. Ask: what filters are mandatory, how selective are they, and how often do they change? If you can’t answer that, you’re choosing storage blind.\u003C\u002Fp>\u003Cul>\u003Cli>Single-user or loose filtering: simpler systems are fine.\u003C\u002Fli>\u003Cli>Tenant isolation or strict ACLs: you need filter-aware retrieval.\u003C\u002Fli>\u003Cli>High-cardinality metadata: assume the naive plan will disappoint you.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Post-filtering is the sneaky way to lose recall\u003C\u002Fh2>\u003Cp>Raunaq’s breakdown of post-filtering is the part I wish more people would read twice. The idea is simple: retrieve the nearest vectors first, then apply the metadata filter after the fact. It sounds efficient because it uses the vector index. It is efficient, right up until the filter gets selective.\u003C\u002Fp>\u003Cp>What this actually means is that the database can return a top-k list that looks mathematically valid and still be wrong for your application. If the filter only lets through 1% of your corpus, the vector index may happily hand you 10 candidates and 8 of them get thrown away. You asked for 10 results. You got 2. The system doesn’t apologize.\u003C\u002Fp>\u003Cp>That’s the ugly part of pgvector’s default behavior in filtered searches. Raunaq points out that pgvector lives inside Postgres, which is great for operational simplicity. I agree. I’ve used that setup and I’d do it again for a lot of internal tools. But if you lean on HNSW first and filter later, you are betting that the candidate pool is large enough to survive the filter. When it isn’t, recall degrades silently.\u003C\u002Fp>\u003Cp>I’ve seen teams misread this as “our embeddings are bad.” No. The embeddings are fine. The retrieval strategy is wrong for the filter shape. That distinction saves a lot of pointless model churn.\u003C\u002Fp>\u003Cp>How to apply it: if you use post-filtering, oversample aggressively and measure recall against filtered ground truth. Do not trust top-k alone. Test the worst-case tenant, the narrowest date range, the smallest source set. Those are the queries that expose the lie.\u003C\u002Fp>\u003Cul>\u003Cli>Use post-filtering only when filters are loose.\u003C\u002Fli>\u003Cli>Expect silent under-delivery if the filter is narrow.\u003C\u002Fli>\u003Cli>Instrument “requested k vs returned k” as a first-class metric.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Pre-filtering is honest, but it can get slow fast\u003C\u002Fh2>\u003Cp>ChromaDB takes the opposite route: filter first, then search inside the filtered set. Raunaq describes it clearly. SQLite handles metadata, gets the matching IDs, and then the system brute-forces the vector search over those IDs. No HNSW magic for filtered queries. Just correctness.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780566512984-6uze.png\" alt=\"Qdrant’s filter-first RAG design, decoded\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>What this actually means is that Chroma picks predictability over sophistication. If a filter matches a subset, you get complete results from that subset. That’s nice. I respect that. I’ve used Chroma in local workflows where I wanted the thing to work now, not after three hours of infrastructure fiddling. For that job, it’s excellent.\u003C\u002Fp>\u003Cp>But the tradeoff is obvious once the filtered subset gets big. If you have hundreds of thousands of vectors in the matching set, brute force is now the bottleneck. The HNSW index only helps when you’re not filtering much. So filtered queries scale about as well as your subset size allows, which is a polite way of saying “not great.”\u003C\u002Fp>\u003Cp>There’s another operational wrinkle Raunaq calls out: Chroma’s embedded mode keeps the whole setup simple, but the metadata and vector index can drift if you crash in the wrong window. That is the kind of thing you don’t care about in a notebook and absolutely care about when you’re trying to trust retrieval in production.\u003C\u002Fp>\u003Cp>How to apply it: use pre-filtering when you value correctness and the filtered subset is small. It’s a good fit for local apps, prototypes, and narrow query scopes. It is not the right answer if every query scans a giant tenant slice.\u003C\u002Fp>\u003Cul>\u003Cli>Great for local development and small deployments.\u003C\u002Fli>\u003Cli>Good when filtered subsets are tiny.\u003C\u002Fli>\u003Cli>Poor when filtered subsets are large and frequent.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Qdrant is built like someone expected filters from day one\u003C\u002Fh2>\u003Cp>Raunaq’s strongest point, in my opinion, is that Qdrant is not just “another vector DB.” It is the one in his comparison that treats filtering as a core storage concern instead of a bolt-on. That changes the whole shape of the system.\u003C\u002Fp>\u003Cp>What this actually means is that Qdrant co-designs the payload index and the vector index. It doesn’t pretend metadata is an afterthought. It stores vectors in segments, keeps payload indexes for fields like \u003Ccode>user_id\u003C\u002Fcode>, and uses that metadata to guide traversal. When the filter is selective, it can adapt. When it’s broad, it can stay in the vector index. That’s the behavior I want from a retrieval system.\u003C\u002Fp>\u003Cp>I’ve had the least friction with systems that admit the query is mixed-mode from the start. Qdrant does that. Raunaq’s explanation of the filter bitmap is the key detail: the database builds a set of eligible IDs from the payload index, then only counts vector candidates that pass. That sounds like a small implementation detail. It isn’t. It’s the difference between “maybe works” and “actually respects the filter.”\u003C\u002Fp>\u003Cp>There’s also a practical storage angle here. Qdrant gives you in-memory, memory-mapped, and on-disk vector storage options. That matters when the corpus grows beyond RAM. I like that it doesn’t force one storage posture on every deployment. The mmap default is the one I’d reach for first because it lets the OS do the caching work instead of making me babysit memory usage.\u003C\u002Fp>\u003Cp>How to apply it: if your app has multi-tenancy, per-user ACLs, or selective metadata filters, start with a filter-aware engine like Qdrant. Don’t wait until you’ve already built the wrong abstraction. That rewrite is always more annoying than the upfront choice.\u003C\u002Fp>\u003Ch2>Segmented storage is why Qdrant feels less brittle\u003C\u002Fh2>\u003Cp>One thing I appreciated in Raunaq’s post is the storage diagram. Qdrant’s segmented layout is not just an internal implementation detail. It’s a reason the system behaves better under constant writes.\u003C\u002Fp>\u003Cp>What this actually means is that new data goes into appendable segments, and background optimization merges and rebuilds without taking the whole collection offline. That’s a very different story from “stop the world and rebuild the index.” I’ve lived through both patterns. One is boring in a good way. The other is a maintenance headache disguised as normal operations.\u003C\u002Fp>\u003Cp>Segmented storage also explains why Qdrant can keep working while the dataset changes. The system is designed around continuous ingestion and background compaction. For RAG apps that ingest docs all day, that matters more than people admit. Retrieval quality is not just about index theory. It’s about whether your system stays sane while content is being added, deleted, and rebalanced.\u003C\u002Fp>\u003Cp>How to apply it: if your corpus is mutable, ask how the database handles writes, compaction, and index rebuilds. If the answer sounds like a maintenance window, keep looking. RAG systems do not stop being queried just because you need to reorganize storage.\u003C\u002Fp>\u003Cp>Also, if you’re comparing vendors, don’t just ask about query speed. Ask what happens after 10 million inserts, after deletes, after tenant churn, and after the first bad deploy. That’s where architecture shows up.\u003C\u002Fp>\u003Ch2>Pick the database that matches your filter pain\u003C\u002Fh2>\u003Cp>Raunaq’s comparison is useful because it doesn’t pretend there’s one winner. There isn’t. There’s only the system that matches your query shape and your tolerance for operational complexity.\u003C\u002Fp>\u003Cp>What this actually means is:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>pgvector\u003C\u002Fstrong> is the sane choice when you already run Postgres, your filters are loose, and you want everything in one place. It is boring in the best way.\u003C\u002Fli>\u003Cli>\u003Cstrong>ChromaDB\u003C\u002Fstrong> is the fast path for local development and small-scale retrieval where correctness matters more than filtered-query scale.\u003C\u002Fli>\u003Cli>\u003Cstrong>Qdrant\u003C\u002Fstrong> is the one I’d pick when filtered retrieval is the product, not an edge case.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>I’m deliberately not pretending there’s a universal answer here. I’ve used Postgres-based vector search because it was the right tradeoff. I’ve also watched that same choice become a liability once access control and tenant filtering got serious. Both can be true. The mistake is treating vector search as a standalone feature instead of a query-planning problem.\u003C\u002Fp>\u003Cp>How to apply it: write your decision around filter selectivity, not around branding. If you can’t describe your 95th percentile query in terms of subset size, you’re not ready to choose a database. That’s the part most teams skip, and then they spend their budget rediscovering it in production.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Filter-first RAG retrieval spec\n\nUse this when you need semantic search inside a metadata subset.\n\n## 1) Define the subset first\n- tenant_id: required \u002F optional\n- source: required \u002F optional\n- date_range: required \u002F optional\n- ACL rules: required \u002F optional\n- expected selectivity:\n  - broad: >50% of corpus\n  - medium: 5%–50%\n  - narrow: \u003C5%\n\n## 2) Pick the retrieval strategy\n- broad filters: post-filtering can work\n- medium filters: use oversampling and measure recall\n- narrow filters: prefer filter-aware retrieval\n\n## 3) Store each chunk with metadata\n{\n  \"id\": \"chunk_123\",\n  \"tenant_id\": \"tenant_a\",\n  \"source\": \"docs\",\n  \"doc_id\": \"doc_456\",\n  \"created_at\": \"2026-06-02T00:00:00Z\",\n  \"tags\": [\"billing\", \"policy\"],\n  \"embedding\": [\u002F* vector *\u002F],\n  \"text\": \"chunk text here\"\n}\n\n## 4) Retrieval contract\nInput:\n- query_text\n- filters\n- top_k\n\nOutput:\n- results must satisfy filters\n- results may oversample internally\n- if fewer than top_k exist, return fewer and say so\n\n## 5) Database choice rules\n- pgvector: already on Postgres, loose filters, low ops overhead\n- ChromaDB: local dev, small corpora, simple setup\n- Qdrant: selective filters, multi-tenancy, production retrieval\n\n## 6) Test cases you should run\n- no filter\n- single tenant filter\n- highly selective tenant filter\n- date range filter\n- combined tenant + source filter\n- worst-case tenant with smallest corpus\n\n## 7) Metrics to log\n- requested_top_k\n- returned_count\n- filter_selectivity\n- latency_ms\n- recall_on_test_set\n- fallback_used\n\n## 8) Retrieval prompt note\nOnly pass chunks that satisfy the filter.\nIf fewer chunks are available, do not invent missing context.\n\n## 9) Example decision note\n\"We chose Qdrant because our retrieval is tenant-scoped and filters are often selective.\"\n\"We chose pgvector because our data already lives in Postgres and filters are broad.\"\n\"We chose ChromaDB for local prototyping and offline document search.\"\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>That’s the part I’d copy into a design doc before I wrote a line of retrieval code. It forces the team to answer the questions that actually matter, and it keeps the database choice tied to query behavior instead of vibes.\u003C\u002Fp>\u003Cp>Raunaq’s original post is at \u003Ca href=\"https:\u002F\u002Fraunaqness.substack.com\u002Fp\u002Fvector-databases-for-rag\" target=\"_blank\" rel=\"noopener noreferrer\">raunaqness.substack.com\u002Fp\u002Fvector-databases-for-rag\u003C\u002Fa>. My breakdown is derivative of his comparison, but the template above is mine, built from the same filter-first lesson and shaped for reuse in an actual RAG design review.\u003C\u002Fp>","I break down Raunaq’s vector DB comparison and turn the filter-first lesson into a copyable RAG schema.","raunaqness.substack.com","https:\u002F\u002Fraunaqness.substack.com\u002Fp\u002Fvector-databases-for-rag",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780566507204-rtv6.png","tools","en","3ead09ec-5656-4165-9bb0-f602add3c409",[17,18,19,20,21],"RAG","vector databases","Qdrant","pgvector","ChromaDB",[23,24,25],"Vector search in production is really subset search plus similarity.","Post-filtering can silently under-deliver when filters are selective.","Filter-aware databases matter most for multi-tenant RAG systems.",0,"2026-06-04T09:48:00.130764+00:00","2026-06-04T09:48:00.102+00:00","a7343b93-37cc-4634-a2bc-707f6275bdb6",{"tags":31,"relatedLang":41,"relatedPosts":45},[32,34,36,37,39],{"name":17,"slug":33},"rag",{"name":19,"slug":35},"qdrant",{"name":20,"slug":20},{"name":21,"slug":38},"chromadb",{"name":18,"slug":40},"vector-databases",{"id":15,"slug":42,"title":43,"language":44},"qdrant-filter-first-rag-design-decoded-zh","Qdrant 讓 RAG 先過濾再找相似","zh",[46,52,58,64,70,76],{"id":47,"slug":48,"title":49,"cover_image":50,"image_url":50,"created_at":51,"category":13},"e66cde5d-1c33-4efa-8f2b-09fb8b19d184","claude-partner-network-learning-path-launches-en","Claude Partner Network Learning Path launches","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780578178350-y5ya.png","2026-06-04T13:02:27.771106+00:00",{"id":53,"slug":54,"title":55,"cover_image":56,"image_url":56,"created_at":57,"category":13},"2e2f6903-c431-447c-9bd6-cb6a4e3534a5","nvidia-research-gpu-template-en","NVIDIA research turns GPU docs into a template","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780567411737-vw5o.png","2026-06-04T10:02:58.56908+00:00",{"id":59,"slug":60,"title":61,"cover_image":62,"image_url":62,"created_at":63,"category":13},"7f8470a6-2ce0-48fb-9e14-f1fd599df36e","anthropic-code-review-tool-ai-generated-code-en","Anthropic’s code review tool turns AI code into reviewable work","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780563809948-86d0.png","2026-06-04T09:02:57.599265+00:00",{"id":65,"slug":66,"title":67,"cover_image":68,"image_url":68,"created_at":69,"category":13},"1247e920-56ea-4e12-9d8c-5a4a7d4df9dd","why-tether-is-right-to-push-local-ai-memory-into-everyday-de-en","Why Tether Is Right to Push Local AI Memory Into Everyday Devices","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780542172839-ie86.png","2026-06-04T03:02:19.993669+00:00",{"id":71,"slug":72,"title":73,"cover_image":74,"image_url":74,"created_at":75,"category":13},"5a3a734e-3a35-41f2-b9b4-b5c1a73f8471","databricks-model-serving-llm-deploy-guide-en","Databricks Model Serving turns LLM deploys simpler","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525995152-os47.png","2026-06-03T22:32:51.502635+00:00",{"id":77,"slug":78,"title":79,"cover_image":80,"image_url":80,"created_at":81,"category":13},"48313ddd-9ba5-4525-8a13-40619b929be5","opencode-digitalocean-model-freedom-en","OpenCode+DigitalOcean 让你切换模型","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525112937-2ydt.png","2026-06-03T22:18:07.524286+00:00",[83,88,93,98,103,108,113,118,123,128],{"id":84,"slug":85,"title":86,"created_at":87},"8008f1a9-7a00-4bad-88c9-3eedc9c6b4b1","surepath-ai-mcp-policy-controls-en","SurePath AI's New MCP Policy Controls Enhance AI Security","2026-03-26T01:26:52.222015+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"27e39a8f-b65d-4f7b-a875-859e2b210156","mcp-standard-ai-tools-2026-en","MCP Standard in 2026: Integrating AI Tools","2026-03-26T01:27:43.127519+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"165f9a19-c92d-46ba-b3f0-7125f662921d","rag-2026-transforming-enterprise-ai-en","How RAG in 2026 is Transforming Enterprise AI","2026-03-26T01:28:11.485236+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"6a2a8e6e-b956-49d8-be12-cc47bdc132b2","mastering-ai-prompts-2026-guide-en","Mastering AI Prompts: A 2026 Guide for Developers","2026-03-26T01:29:07.835148+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"3ab2c67e-4664-4c67-a013-687a2f605814","garry-tan-open-sources-claude-code-toolkit-en","Garry Tan Open-Sources a Claude Code Toolkit","2026-03-26T08:26:20.245934+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"66a7cbf8-7e76-41d4-9bbf-eaca9761bf69","github-ai-projects-to-watch-in-2026-en","20 GitHub AI Projects to Watch in 2026","2026-03-26T08:28:09.752027+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"9f332fda-eace-448a-a292-2283951eee71","practical-github-guide-learning-ml-2026-en","A Practical GitHub Guide to Learning ML in 2026","2026-03-27T01:16:50.125678+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"1b1f637d-0f4d-42bd-974b-07b53829144d","aiml-2026-student-ai-ml-lab-repo-review-en","AIML-2026 Is a Bare-Bones Student Lab Repo","2026-03-27T01:21:51.661231+00:00",{"id":124,"slug":125,"title":126,"created_at":127},"6d1bf3f6-e191-4d30-b55b-8a0722fa6afe","ai-trending-github-repos-and-research-feeds-en","AI Trending Tracks Repos and Research Feeds","2026-03-27T01:31:35.709532+00:00",{"id":129,"slug":130,"title":131,"created_at":132},"010539a1-4c3a-4bd3-937a-26616422ee0d","awesome-ai-for-science-research-tools-map-en","Awesome AI for Science Is Becoming a Real Research Map","2026-03-27T01:46:50.89513+00:00"]