The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Built an AI-powered Bengali question-answering system that retrieves information from a Bengali book and generates context-aware answers using RAG, embeddings, vector search, and an LLM.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Before adding AI to your SaaS, write the failure contract.Most AI feature briefs describe what should happen when the model works.Production problems begin when it doesn’t.Before adding AI to an existing SaaS product, I think the team should define: 1. LatencyHow long can the user wait before the product falls back, continues asynchronously, or offers another path?2. UncertaintyWhat happens when the output is incomplete or confidence is too low? Does the product ask for clarification, request human review, or refuse the action?3. PermissionsWhich records can the model access for this user, role, and organization? AI should inherit the product’s access rules rather than bypass them.4. Action boundariesCan the AI recommend, draft, or execute? Sending an email, changing a payment state, and updating a customer record should not share the same approval rules.5. CostWhat is the usage limit per user or tenant? Which model or workflow becomes the fallback when a request is too expensive?6. RecoveryCan the team see which model, prompt, data, and tool call produced the result? Can a failed workflow be retried without duplicating the action?Connecting an API is usually the easy part. The real product work is deciding how the feature behaves when reality does not match the demo.If you are building AI into a product, which part is hardest to define: latency, permissions, human approval, cost, or recovery?
Recovery is the one I find hardest to define. If an email goes out and the next step fails, I want the retry to know it was sent so the customer does not get it twice.
Another late night. Building a quant trading system an agentic model where different AI agents handle research, testing and risk, and none of them is allowed to place a trade on its own.
The hardest part so far? Being honest when the results say "not yet." Most strategies I've tested failed once real costs were included. That's exactly what testing is for.
Keeping The Psychology of Money and The Diary of a CEO close while I figure it out. What are you reading these days?
Curious how you’ve separated the agents from execution. When you say none can place a trade on its own, is that enforced through a separate execution service with fixed risk checks, human approval or both? I’d love to understand where the agent's decision-making ends and the hard rules take over.
AI-Powered Document API (RAG) — deployed on Render
FastAPI, PostgreSQL, OpenAI API, React, Docker, GitHub Actions
• Built a RAG backend: PDF ingestion, overlapping chunking, embedding-based retrieval, and OpenAI answers grounded in retrieved chunks, behind JWT auth with response caching.
• Debugged a chain of Render build and runtime failures (memory limits, dependency conflicts, ephemeral disk) and replaced a local FAISS index with PostgreSQL-stored embeddings and NumPy cosine similarity.
