ichiwells
Joined 1 year ago
Karma
29
Submissions
6
Member since
Mar 1
Recent submissions
Comment · 1 year ago
Thank you so much for sharing this!
We are using ruby to build a powerful AI toolset in the construction space, and we love how simple all of the SaaS parts are and not reinventing the wheel, but the ruby LLM SDK ecosystem is a bit lagging, so we've written a lot of our own low-level tools.
(btw we are also hiring rubyists https://news.ycombinator.com/item?id=43865448)
Comment · 1 year ago
Ichi | Remote (US) | Full-Time | Senior Software Engineer, Full Stack | LLM-powered construction code compliance
Ichi is building an AI-powered professional toolset to transform construction permitting and code compliance. We're helping municipalities, plan examiners, architects, and construction professionals streamline the permitting process to reduce bottlenecks—ultimately accelerating construction timelines in an $11T global industry.
We're a small team (you == employee #6) backed by Costanoa Ventures looking for a high-ownership Senior Software Engineer (8+ years exp) who can build from scratch and deeply cares about product quality. You'll design and implement product features that integrate intuitive UX and powerful multi-modal (and multi-model) LLM pipelines, working directly with users to refine our approach.
Tech stack: Ruby, Rails, Python, React, TypeScript, GraphQL, Postgres, AWS.
Must have: Full stack experience, product intuition, and interest in LLMs.
CS degree or equivalent preferred; we work on hard problems and first-principles thinking and attention to detail are essential.
Our name "Ichi" (Japanese for "city", and "one") reflects our mission to improve the physical spaces around us through never-before-possible technology and bridging a fundamental information asymmetry.
Comment · 1 year ago
One of apple’s biggest missed with “AI” in my opinion, is not building a universal search.
For all the hype LLM generation gets, I think the rise of LLM-backed “semantic” embedding search does not get enough attention. It’s used in RAG (which inherits the hallucinatory problems), but seems underutilized elsewhere.
The worst (and coincidentally/paradoxically I use the most) searches I’ve seen is Gmail and Dropbox, both of which cannot find emails or files that I know exist, even if using the exact email subject and file name keywords.
Apple could arguably solve this with a universal search SDK, and I’d value this far more than yet-another-summarize-this-paragraph tool.
Comment · 1 year ago
I would actually start with the Rails Guides docs, they’re very good and running the given commands should actually work:
https://guides.rubyonrails.org/getting_started.htm
Just have a toy app you want to build in mind
Comment · 1 year ago
I run engineering for a venture backed AI-first startup and we use Ruby/Rails.
For us, it made sense to leverage one of the best domain modeling and ORM frameworks out there. Most of our inference is http calls to foundational models, but we can still fine tune and host models on GPUs using Python.
Inference matters, but part of building an effective user platform are the same old SaaS problems we’ve had before, and Rails just works. Inbound and outbound email done in a day. Turning an OCR’d title from ALL CAPS into Title Case is one method call and not a whole custom algorithm, etc.
A lot of people seem to think Ruby is slow for some reason but it’s as fast as Python, and with falcon as fast as node for async behavior. Safe to say the application language taking 0.03 seconds instead of 0.003 seconds when you have to wait 3 seconds for first token is absolutely not the bottleneck with LLM heavy workflows, anyway.
And yes, metaprogramming is a powerful tool with which you can easily shoot yourself in the foot. We culturally just don’t write any code that’s not greppable so don’t use method_missing kinds of things unless it’s in a robust gem like active record. Pretty trivial problem to solve really.
PS - We’re hiring, if that philosophy aligns with you!
Comment · 1 year ago
> Finally, building HNSW indices in Postgres is still extremely slow (even with parallel index builds), so it is difficult to experiment with index hyperparameters at scale
For anyone coming across this without much experience here, for building these indexes in pgvector it makes a massive difference to increase your maintenance memory above the default. Either as a separate db like whakim mentioned, or for specific maintenance periods depending on your use case.
``` SHOW maintenance_work_mem; SET maintenance_work_mem = X; ```
In one of our semantic search use cases, we control the ingestion of the searchable content (laws, basically) so we can control when and how we choose to index it. And then I've set up classic relational db indexing (in addition to vector indexing) for our quite predictable query patterns.
For us that means our actual semantic db query takes about 10ms.
Starting from 10s of millions of entries, filtered to ~50k (jurisdictionally, in our case) relevant ones and then performing vector similarity search with topK/limit.
Built into our ORM and zero round-trip latency to Pinecone or syncing issues.
EDIT: I imagine whakim has more experience than me and YMMV, just sharing lesson learned. Even with higher maintenance mem the index building is super slow for HNSW
IchiPlan.com
"The Trusted Source for Code Compliance"
Problem: The Rent is Too Damn High.
Permitting buildings and homes takes months and months across many back-and-forth cycles. The majority of time, permits are "idle"/queueing. Liability concerns prevents the government permit-issuing entities from telling residents and developers how to actually fix problems quickly and efficiently. They instead submit into the black box and a month later get another ambiguous comment.
It’s information asymmetry that both sides actually want solved.
LLMs, Computer Vision and semantic search change what's possible.
Using AI + LLMs to make permitting easier -> make homes and buildings more affordable
Hiring! https://www.ichiplan.com/join_team
LinkedIn: /jeffreyryanwells