The article sits on an assumption that if we just wait long enough, the unreliability of deep learning approaches to AI will just fade away and we'll have a full-on "drop-in remote worker". Is that a sound assumption?

This works even if the coin lands heads 99% of the time, as long as it's consistent (but you'll probably have to flip a bunch of times in that case).

Take sqrt(2)^sqrt(2), which is either rational or not. If it's rational, we're done. If not, consider sqrt(2) ^ (sqrt(2) ^ sqrt(2)). Since (a^b)^c = a^bc, we get sqrt(2) ^ (sqrt(2))^2 = sqrt(2)^2 = 2, which is rational!

It feels like a bit of a sleight of hand, since we don't actually have to know whether sqrt(2)^sqrt(2) is rational for the proof to work.

As a layperson, it seems like we (patients / society) would benefit from having more doctors, i.e. opening up more residency slots and admitting more people to med school, but there's probably a lot I don't understand about the issue. Not sure if it's a lack of political willpower to do this, or if there are other reasons why the number of doctors we train is so restricted.

[1] https://pubmed.ncbi.nlm.nih.gov/29710082/ ("PAs performed more skin biopsies per case of skin cancer diagnosed and diagnosed fewer melanomas in situ, suggesting that the diagnostic accuracy of PAs may be lower than that of dermatologists")

I've found all of the RAG applications I've tried to be pretty underwhelming, but semantic search itself (especially combined with full-text search) is very cool.

The core idea is to take precinct-level election results and visualize them with one dot per vote, but distribute those dots based on block-level population density. For both maps, this uses 2020 Census block non-incarcerated voting-age population totals to place the dots (most of the work to generate these block-level vote and population numbers was done by the redistrictingdatahub.org, with the exception of DC, CA, and PA).

The map uses MapLibre for the front end and a vector-tile service called Tippecanoe to generate the tiles.

I was inspired by maps like this one: https://x.com/kennethfield/status/1363974716826869760 (the author has an excellent book of 101 visualizations of US Election data), but wanted to make a version that uses precinct-level data and offers the side-by-side comparison of 2016 vs 2020.

I hope it's okay to post this here despite the political nature - it was an interesting project from a tech/cartography standpoint and it's cool to see the political geography of the US.

Comments URL: https://news.ycombinator.com/item?id=41898922

Points: 1

# Comments: 0

This works with just an OpenAI API Key, but sounds much better with ElevenLabs.

Comments URL: https://news.ycombinator.com/item?id=41329086

Points: 1

# Comments: 0

Some queries that should work:

- A zip code (should be fastest, shows block-by-block population density)

- An address (block-level population density within the surrounding zip code)

- A demographic/population/housing indicator (e.g. "$500k+ homes", "percent of people who drive to work" - shows US States and you can double-click to see more detail)

- A comparison between two indicators (e.g. "median income vs homeownership rate") - this shows two maps which zoom & pan together

You can also try to search for an indicator and a place, e.g. "population density by zip code in Los Angeles County" - this only works sometimes though, I'd like to made it more reliable.

Searching these demographic indicators is tricky and I haven't totally solved it, but I think this works reasonably well. The search backend uses LLMs for query parsing, result selection, & embeddings, and uses postgres full text search + pgvector for retrieval. The app is hosted on CloudFlare Workers and mostly written in TypeScript.

I posted this as a Show HN about a month ago, but am posting again because I've made some pretty substantial changes since then (block-by-block data and comparisons are new).

[1] Specifically, population and occupied/vacant/total housing unit counts, with some randomness added by the Census for privacy

Comments URL: https://news.ycombinator.com/item?id=41282983

Points: 3

# Comments: 0

A lot of the stories are free to read online without buying it but I thought the few dollars for the ebook was worth it

Really appreciate the feedback!

As far as the second issue - when people search for things way outside of the available data - I have not done much to address this, but really should. This happens for more plausible queries too, e.g. "Crime Rate" seems like it could be cataloged by the Census, but is not part of the tables indexed by the site (ACS Detailed Tables). It selects variables somewhat randomly here when it should really say something like "no relevant results found"

- Barring serious bugs, BlockAtlas won't "lie" to users. It may fail to find something relevant, or misunderstand a query, but the results (map title & data) will faithfully reflect the underlying Census estimates

- BlockAtlas covers a much wider set of Census data than other tools I've seen. Almost every "Detailed Table" from the American Community Survey is available, across the entire range of release years (2005-2022). There are ~29,000 demographic indicators in the search index as it stands, plus some combinations of indicators (e.g. "X and above") for popular tables

Similar LLM+Census things I've seen have used an approach akin to "replicate some data into my DB, have LLM generate SQL over it", which makes it hard to avoid issues with both of these points. I've taken a bit of a different approach - creating a search index over metadata, i.e. searching for API parameters and pulling the data itself directly from the Census. That way, the LLM is limited to "selecting between known-valid options", rather than generating a SQL query and displaying the results under a potentially-misleading name.

This is the second iteration of Blockatlas - the first was a ChatGPT plugin. The LLM would query my API for candidate variables, and generate a link to my site with the variables to display and the map title as query parameters. This made for a cool demo but ultimately was very hard to trust - the LLM could select a map title which was not at all reflected by the variables in question, or could combine variables in a nonsensical way, so it failed to solve the "don't lie to users" problem. The plugin ("GPT" now) is still available, but the standalone search engine is my effort to remedy those issues.

The tech stack: The frontend uses React for the search form and Leafet map. API is written in Typescript and hosted on Cloudflare Workers. The search indexes are in a Postgres DB using pgvector + OpenAI embeddings as well as pg's built-in full-text-search feature, and the OpenAI API is used for query-parsing and result reranking/selection as well (gpt-3.5-turbo).

I think there's a ton of room for improvement here, but wanted to gauge public interest a bit before putting more time into this (I have a newborn and a full time job, so it's been hard to carve out time to work on this lately).

Comments URL: https://news.ycombinator.com/item?id=40984765

Points: 3

# Comments: 6

What makes the most sense to be is to be really selective about what new technologies to use, and try to really learn ~one thing per project. E.g. my current project is a small search engine, and I've spent a lot of time exploring / figuring out how to use LLM Embedding models and vector indices for search relevance (vs. falling back on using ElasticSearch the same way we use it at work), but I'm using tools that are familiar to me for the UI/db/infrastructure.

(posted on HN here: https://news.ycombinator.com/item?id=40534868)