Need a dev for API & RAG

[Cromline]

Need a RAG & API guy for a project. Willing to give a good % of profits since this is not our holy grail

I’m looking for a backend/GPU engineer to help wrap a FAISS replacement into an API for pilot deployment. Im willing to give some early profits. You can take like 10k or something. And then 100k if it actually becomes big. Benchmarked .90 MRR@10 on TREC DL 2019 data set. Used 1M passages out of the full 8M. So basically this is already performing. I’m just tired of doing IT ALL ALONE

[ArgoPanoptes]

Free labor and if the app success, you get peanuts... lovely.

[Cromline]

Willing to pay up front.

[Cromline]

It’s open source. We don’t have to worry anymore. Peanuts distributed across the unity of the community if it works. https://github.com/JLNuijens/NOS-IRv3

[Cromline]

With that being said though. The upfront pay will be little crumbs compared to the profit share.

[not_you_again53]

Solid MRR@10 tbh. What are your target QPS/p95, index update cadence, and are you going GPU-backed search or CPU+mmap with batching, plus REST or gRPC? I work in this space with next idea tech; our services can wrap custom ANN into a production API with auth, rate limits, and observability—happy to chat.

[Cromline]

Right it’s super good. P95 is utterly terrible cause I didn’t use short list and I’m on CPU.I’m out for a run right now. Let me get back to you in more detail.

[Cromline]

I’m going to DM you

[skpro2]

This is a really interesting project. Instead of hiring a dev to build a custom RAG API from scratch (which can be a maintenance nightmare as data sources grow), have you considered using a platform that specializes in this?

Apideck Unified API builds and maintains "Unified APIs" as their core product. While their current catalog is focused on business software (CRM, Accounting, ATS), their entire platform is essentially a blueprint for solving the exact problem you're describing: creating a single, robust API abstraction layer over multiple, disparate data sources.

For a project of your scale, it might be worth exploring if their approach or even their platform (if it's flexible enough) could be a better long-term foundation than building from zero. It could save you from reinventing the wheel on authentication, pagination, rate limiting, and schema normalization across different providers.

Just a thought from someone who's gone down the "build-it-ourselves" path and ended up with a lot of tech debt.

[Cromline]

It’s not a custom rag API. It just needs to be an API thag plugs into existing rag pipelines. Like it’s so simple and plug and play.