Grab some baked goods at Hewn (in Evanston), visit the Bahai temple, and then walk across the street to Gillson Park to wander the Lake Michigan shore and eat your goods from Hewn.
The easternmost portion of Northwestern's campus also has a nice walking/biking path along the lakeshore with a great view looking back towards the Chicago skyline.
I've mostly written technical, code-centric posts on Python, ML, and data science. Some of my early posts (2013) were wildly popular at the time and hit the top of HN and various subreddits.
I haven't written much recently, but I've been trying to branch outside of technical posts as I felt like my profession had started to become too much of my identity.
I initially built this same "chat with PDFs" prototype with LangChain and qdrant. I then rebuilt it from scratch for the sake of learning and comparison.
Some context: I've been a jack-of-all-trades data scientist / machine learning engineer for the past 15 years (officially titled as an MLE the last four years).
I share that only because I think it plays a role in how I'm typically accustomed to working.
1. I found LangChain to be overkill for this use-case. While it might allow some to move more quickly when building, I found it to be cumbersome. My suspicion is this is largely because of my background - I understand how to build much of what's "under the hood" in LangChain. Because of this, I think it felt overly abstracted and I found the docs difficult to navigate and sometimes incomplete.
2. I used Qdrant via their docker image and it was simple to setup and start using. I didn't try to push the limits with it, so I can't say anything about performance. Because Qdrant runs as an http service, I found that it didn't fit well into my workflow - I'm accustomed to being able to visually inspect my data inside the interpreter, debugging, trying out commands, interacting and experimenting with my results, etc. Again, my suspicion is this is my own bias in how I typically work. Qdrant otherwise seemed very nice.
3. LanceDB felt powerful yet lightweight, and fit well into my workflow. It was far more intuitive for me. It was as if sqlite, the python data ecosystem, and a vector database had a child and named it LanceDB. Under the hood, it's built on Apache Arrow and integrates nicely with pandas, allowing me to seamlessly go from LanceDB table on disk, to pandas dataframe, and into some analysis or investigation of my LanceDB query results. This line [1] is a great example of why I liked it. This feels nicer to me than the world of API params and HTTP requests.
Not specific to this model, but beyond the large players (OpenAI, Cohere, etc) are there any free hosted versions of the open(ish) LLMs? Even the smaller 7B parameter ones? I'm prototyping out a project and using OpenAI for now, but it feels like there has to be a hosted alternative somewhere.
I spent some time today exploring HuggingFace's Inference API but if the model is sufficiently large (> 10gb), HF requires you to use their commercial offerings.
I recently prototyped out a "chat over PDF documents" project.[1] I opted to use LanceDB for vector (embeddings) storage and retrieval and found it really nice to use.
Imatinib (Gleevac) revolutionized treatment for patients with chronic myeloid leukemia (CML). Prior to the drug’s discovery, CML patients generally had seven years to live (possibly less depending on how advanced the cancer was). Now their lifespan mirrors the general population.
I’d highly recommend the book The Philadelphia Chromosome if you’re interested in learning more.
Here's an excerpt from their October 2019 letter to shareholders. TL;DR - they're a public company and the markets told them they needed to keep growing in order to survive.
> For restaurant inventory, we will rapidly expand our recent pilots of putting non-partnered restaurants on the platform. For reasons we’ve discussed many times, we believe non-partnered options are the wrong long-term answer for diners, restaurants and shareholders. It is expensive for everyone, a suboptimal diner experience and rife with operational challenges. With that said, it is extremely efficient and cheap to add non-partnered inventory to our platform and it can at least ensure that all of our current and potential new diners have the option to order from any of their favorite restaurants now, even if it’s not the best solution. By leveraging non-partnered options, we believe we can more than double the number of restaurants on our platform by the end of 2020.
> At the same time, because we know that partnered relationships are critical to the long-term success of this business, we will be investing aggressively in our independent restaurant sales organization to support converting as many of these non-partnered restaurants to partnered relationships as quickly as possible and to take advantage of other innovations in the restaurant space, like virtual restaurants.
This was GrubHub's original model. Restaurant's don't want to pay a flat fee when they don't see enough orders they feel is necessary to justify said fee.
Having recently road tripped across the country for a move to SF, I found myself admiring the design of national park signage. It feels very timeless and iconic.
I agree. Hadley Wickham (a very prolific author of important R libraries) wrote a great paper about this method using one of his libraries. I'm a Python + pandas user, but his paper really helped me understand the approach better: https://vita.had.co.nz/papers/plyr.pdf
Sprout Social | http://www.sproutsocial.com | Engineering & Non-Engineering | Chicago, IL & Seattle, WA | ONSITE | Full-time
Sprout Social builds social media management tools for businesses of all sizes. We are built on the idea that the world is better when businesses and customers communicate freely. We exist to help streamline and enhance those conversations — with customers, prospects and enthusiasts.
From an engineering perspective, we do not operate as lone wolves, cowboy coders, or "10x devs." Instead, we're building diverse, collaborative teams that get the best results sustainably. We follow Spotify's engineering model with squads being made up of platform, front-end, QA, design, and product managers, all working together to drive our product initiatives to successful outcomes.
Our platform team uses Java, Python, MySQL, and NSQ, while our front-end team uses React, Redux, Ember, ImmutableJS, and Gulp, all to build highly scalable software that is used by more than 20,000 organizations around the world. Companies like Dropbox, Zendesk, Fender, Brooks Running, Seattle Cancer Care Alliance, and Evernote rely on our products to create stronger relationships with their customers.
If you're a creative, highly motivated, and inquisitive learner, we'd love for you to come build great software with us.
