News for hackers. Stuff that matters.

Alyx1337

Re:Bringing the end-user into the AI picture on Saturday February 17, 2024 @03:44AM (#39407636)
Most engineers focus on the algorithm or the model in the AI space. Doing so, they forget the most essential and time-consuming part: ensuring your project is practical and accessible to your end-user. This post looks at two real-life use cases of how to build AI projects focused on the end-user.
Thank you very much!
Thanks! There are ways to shave off the latency: hosting locally, using quantized/smaller models, streaming data instead of doing the tasks sequentially
Exactly my thought, I was like "Jarvis has got to be just a 2030 version of an LLM".

Yeah I actually considered making a spotter AI using computer vision in a game like ARMA 3 or Squad but kind of difficult. I made a spotter for ground vehicles on aerial imagery using YOLOv5 here: https://github.com/AlexandreSajus/Military-Vehicles-Image-Re...

There's a French defense company, Preligens, that actually does this currently

That was exactly my thought haha, I want Jarvis at home. You could easily modify my code to run a local LLM instead
Great! What do you guys have in mind in terms of products using these tools. Yeah unfortunately it's hard to shave on latency.
Yeah I had the same issue so I used (stole) this answer on StackOverflow: https://stackoverflow.com/questions/46734345/python-record-o... Basically there's a library that records until it detects a silence
Uh oh I hope I'm not in trouble
Thanks! I don't know a lot about this but someone shared this local voice assistant in the comments: https://github.com/KoljaB/LocalAIVoiceChat Could be a good lead
Deepgram advertised itself as being the fastest, and I wanted to focus on limiting response delay so I chose it. I hope I did not get misled.
How did you find these? I was literally looking for tutorials all day long and could not find something. These projects look insane!
Re:Python Charting: Taming Big Data Without Crashing on Tuesday December 12, 2023 @08:31AM (#38611834)
Hey guys! I work at Taipy; we are a Python library designed to create web applications using only Python. Some users had problems displaying charts based on big data, e.g., line charts with 100,000 points. We worked on a feature to reduce the number of displayed points while retaining the shape of the curve as much as possible and wanted to share how we did it.
If this is really your sentiment, I strongly invite you to try out Taipy. This was exactly our reaction when we decided to build Taipy. Streamlit was already somewhat popular, but it would always fail at the production stage when we tried using it for consulting missions. Any application in production generally has a significant workload in the back-end, multiple pages, and users. Streamlit's approach of re-running your code outside cached variables limits it to POCs, as you said.

That is why we created Taipy. We wanted an easy-to-learn Python library to create front-end for data applications while remaining production-ready: we use callbacks for user interactions to avoid re-running unnecessary code. Front and back-end run on separate threads so your app does not freeze whenever a computation runs.

We also focus on providing pre-built components to allow the end-user to play around with data pipelines quickly. These components allow the user to visualize the data pipeline in a DAG, input their data, run pipelines, and visualize results...

We actually used Streamlit in the past. Our gripe with it was how the backend event loop was managed. Basically, Streamlit re-runs your code at every user interaction to check what's changed (unless you cache specific variables which is hard to do well). When your app has significant data or a significant model to work with or multiple pages or users, this approach fails, and the app starts freezing constantly. We wanted a product that is the compromise between the easy learning curve of Streamlit while retaining production-ready capabilities: we use callbacks for user interactions to avoid unnecessary computations, front and back-end are running on separate threads. We also run on Jupyter notebooks if that helps.
Yeah, you got it right. Taipy is not about AI but more about providing a way for people who work in AI and data to create a front-end for their project without having to learn other skills outside of Python.