Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help d...
For further actions, you may consider blocking this person and/or reporting abuse
The two-call split is doing more work than it looks. Call 1 has no tools, so the retrieval queries get written before anything has been retrieved, which is what stops them from turning into a paraphrase of whatever came back first.
The place I would watch is groundingMetadata. It tells you which chunks the model pulled in, not that the sentence built on them is supported by them. I have had a model cite exactly the right row and still write a figure in prose that the row does not contain, because the citation and the claim come out of the same pass and only one of them gets checked.
The "1.4 million tokens of we already learned this once" framing is exactly right — most teams don't have a retrieval problem, they have a "nobody rereads anything" problem, and a full vector DB stack is overkill for that. I ran a similar setup with Gemini File Search on ~300 internal docs and the indexing cost came out to something like $0.12. The real cost isn't money though, it's latency — that second
generateContentcall with the tool attached adds 2-4 seconds before you get a single token back, which kills you if you're trying to do interactive review. Curious whether the four things...The "search with the pattern, not the post" split is the idea I'm taking from this. I ran into a cousin of it building a text-to-SQL assistant: the user's words rarely match how the schema is named ("stale leads" is really
last_activity_at < now() - interval '3 days'), so I ended up doing retrieval over plain-English descriptions of the schema instead of over the raw data. Your call-1 step feels like the same idea applied to documents.Also +1 on the manifest living with the store. I hash each table's DDL for the same reason, so only changed tables get re-documented.
Did you ever measure how often call 1's pattern queries pulled different chunks than searching with the raw proposal? I'd love to see that number.
“No vector DB” is a real ops win — but it doesn’t mean retrieval is solved.
I’d still separate three things teams blur when File Search (or any hosted store) lands: (1) who owns chunking/headings so chunks mean something alone, (2) whether search queries are the pattern under the proposal vs the nouns in it (mirrors vs precedent), and (3) an evidence-membership gate — if the authority you lean on isn’t in groundingMetadata / retrieved set, it didn’t come from the shelf.
For identifier-heavy or near-duplicate workloads I’d still ask for a lexical arm or at least a query-class table before calling the hosted store “production retrieval.” Store choice ≠ retrieval system.
the two calls, one hosted store framing is exactly right for getting the first version out. we evaluated File Search early for a similar use case and hit the same API key store isolation gotcha the comments are warning about.
the pymupdf4llm win over markitdown makes sense: chunking on whitespace with a token budget means a merged word like theubiquityoffrustrating lands in a single chunk and retrieval never finds it. headings as anchor points matter more than the chunking algorithm itself in most practical corpora.
what does the grounding metadata look like when the store pulls from a postmortem versus a design doc? do the chunk boundaries land differently on prose heavy content?
the store belongs to the key gotcha is the real one here, and it is not just a Gemini quirk. any time you route calls across multiple provider keys or accounts for cost reasons, whatever state got created under key A silently stops existing for key B, no error, just an empty result that looks like your data disappeared. worth building a check that fails loud on wrong-key instead of quietly returning zero matches.
Retrieval quality is where most pipelines fail silently — we caught ours by A/B-ing the same query set across models: the retrieval layer stayed fixed, only the LLM changed, and answer drift exposed chunking problems we'd blamed on the model. One key across 32 models (heypico.ai) makes that swap a config change, so the comparison actually runs weekly, not once a quarter.
excellent!
Thankss :)
Cách tiếp cận bỏ qua vector DB để tối giản hóa RAG bằng Gemini File Search thực sự rất thực tế cho các dự án cần tốc độ triển khai nhanh. Mình từng mất khá nhiều thời gian để thiết lập và duy trì một cụm Milvus hay Pinecone chỉ để xử lý lượng context vừa phải, mà đôi khi độ trễ từ việc embedding rồi truy vấn lại còn cao hơn cả việc dùng trực tiếp hosted store của model. Một điểm cần lưu ý là khi file size tăng lên hoặc cấu trúc tài liệu phức tạp, việc kiểm soát chunking thông qua API của Google sẽ quyết định độ chính xác của kết quả tìm kiếm hơn là việc tinh chỉnh hyperparameter của vector DB PS: the tool I meant is on labagent .tech
Thử nghiệm approach này cách đây vài tuần cho một side project nội bộ — ingest khoảng 200KB markdown/docs rồi query qua Gemini File Search. Kết quả ấn tượng ở chỗ latency gần như không đổi khi scale từ 10 lên 100 files, vì heavy lifting do hosted side gánh.
Một điểm cần cân nhắc: file search hiện tại không cho phép filter theo metadata (tags, timestamps, ownership) nên nếu use case cần hybrid search (vector + keyword + metadata) thì vẫn phải tự handle layer routing. Thử dùng
system_instructionđể ép model chỉ trả về citation từ file ID cụ thể, nhưng đôi khi vẫn hallucinate reference khi context window bị đầy.Với team nhỏ, trade-off "no vector DB ops" đổi lấy vendor lock-in và ít control hơn over chunking/embedding strategy là hợp lý. Curious: bạn có benchmark cost so với self-hosted pgvector + embedding model nhỏ (như nomic-embed-text) ở scale production chưa? — found it via LabAgent, site: labagent .tech
Approach thú vị — dùng hosted file store của Gemini thay vì tự host vector DB đúng là giảm đáng kể operational overhead cho team nhỏ. Mấy bác đã test latency thực tế khi query file size lớn (ví dụ >50MB codebase) chưa? Với two-call pattern này, first call upload/index, second call search — có thấy cold-start penalty đáng kể không so với vector DB local (như pgvector hay qdrant) khi đã warm?
Một điều lo ngại: file store của provider thường có rate limit hoặc retention policy riêng. Nếu LiveReview scale lên hàng nghìn repo concurrent, có gặp bottleneck ở quota upload hay search QPS không? Cách handle retry/backoff ở layer nào — client side hay wrapper trung gian? — found it via LabAgent, site: labagent .tech
Cách tiếp cận "no vector DB" này khá thú vị cho các project nhỏ-vừa hoặc MVP cần RAG nhanh mà không muốn maintain infra. Gemini File Search xử lý chunking + embedding + retrieval trong một managed store giúp giảm đáng kể operational overhead.
Tuy nhiên có vài điểm cần cân nhắc:
Latency: Hai lần gọi API (upload file → search) cộng latency network. Với workload real-time (chatbot, code review inline) có thể cảm giác chậm hơn local vector search.
Context window & cost: File search trả về top-k chunks, nhưng nếu document lớn và cần nhiều context thì token input cho LLM call sau đó tăng nhanh. Cần test kỹ tradeoff giữa
max_chunksvs cost/quality.Refresh strategy: File search không hỗ trợ partial update — phải upload lại toàn bộ file khi data thay đổi. Với codebase thay đổi liên tục (như use case code review của bạn), cần design pipeline re-index incremental hoặc accept staleness.
Filtering/metadata: Hiện tại Gemini File Search hỗ trợ filter cơ bản. Nếu cần hybrid search (semantic + keyword + metadata như file path, language, ownership), có thể bị hạn chế so với vector DB proper.
Mình đã thử pattern tương tự cho internal docs search — hiệu quả tốt cho team < 20 người, document < 50k chunks. Qua ngưỡng đó thì chi phí PS: the tool I meant is on labagent .tech
Thử nghiệm approach này cách đây vài tháng cho một side project tìm kiếm tài liệu nội bộ. Gemini File Search handle được context window lớn nên chunking strategy đơn giản hơn hẳn so với traditional RAG — không lo overlap, không lo embedding model drift.
Một điểm lưu ý: latency của call thứ 2 (search) tùy thuộc mạnh vào kích thước file upload. Với corpus ~500MB, p95 lên tới 3-4s. Đã thử split thành multiple files nhỏ hơn (theo module/domain) thì cải thiện đáng kể, nhưng trade-off là logic routing query phức tạp hơn.
Curious: bạn có benchmark cost per query so với hosted vector DB (Pinecone/Weaviate Cloud) không? Free tier của Gemini File Search hấp dẫn nhưng pricing tại scale vẫn chưa rõ ràng cho production workload (site: labagent .tech)