This would be cool. I suspect that people don't implement this model because it's a long tail of users requesting this. This is totally feasible technically.
838 karma · joined April 2, 2010
javascript:window.location="http://"+window.location.search.match(/id=(\S+)/)[1]+".com"
See https://www.grammarly.com/blog/engineering/deep-learning-swi... for more details - it's very similar to the architecture described by the FUTO folks.
One key difference is that the learned model does not decode in a context sensitive manner but does it a word at a time. The main reason is because we wanted to release this soon and wanted the user's personal dictionary (i.e. contact names, etc... to show up correctly when swiped). It would have been nice if we could have followed through with the context sensitive decoding as described by the FUTO folks. It would really help with accuracy when dealing with words like:
1. (food, good, hood) 2. (you, toy, rot) 3. (our, or, it) etc...
(Disclaimer: I am one of the authors of the Grammarly swipe system as described in the linked blog post).
While the provided schema has a "quantity" field, it doesn't mention the units.
<code>
class Item(BaseModel):
name: str
price: float = Field(description="per-unit item price")
quantity: float = Field(default=1, description="If not specified, assume 1")
establishment_name: str
date: str = Field(description="YYYY-MM-DD")
total: float = Field(description="The total amount of the receipt")
currency: str = Field(description="The currency used for everything on the receipt")
items: list[Item] = Field(description="The items on the receipt")
There needs to be a better evaluation and a better provided schema that captures the full details of what is expected to be captured.
> What kind of error should it return if there's no total listed on the receipt? Should it even return an error or is it OK for it to return total = null?
Additionally, the schema allows optional fields, so the LLM is free to skip missing fields if they are specified as such.
We’re the PyTorch Mobile Team (https://github.com/pytorch/pytorch/) working on making PyTorch broadly available for a plethora of mobile devices both within Facebook and outside. We’re interested in motivated engineers in this space who are willing to work remotely (within the US).
PyTorch is the most popular AI framework within the research community, and we’re working on making it production ready (especially on mobile devices).
You can see here (https://ai.facebook.com/tools/pytorch/) that the journey for Mobile (marked experimental) has just gotten started, and you’ll be jumping on to the bandwagon as it starts to leave the station!
Please drop us an email at (agaurav at fb dot com and dhruvbird at fb dot com), and we’d love to chat if this sounds interesting to you!
1. Were the numbers for the chart "Willingness to wait in a city 2013 v/s 2014" generated based on estimates from the Uber app or real wait times that were logged once the customer was picked up?
2. Also, looking at the same graph, it seems some of the rides that were not completed because the ETA was < 4.5 minutes (Probability=1) could have trivially been completed had Uber just dispatched the driver a little later (or had the driver delayed him/her-self a bit).
3. What is the volume of rides as a % for each range of waiting times for the ETA?
4. What is the revenue per ride as a % of total revenue for each range of waiting times for the ETA?
should be...
you know what it should be ;)