blackkettle
Joined 15 years ago
Joined 15 years ago
I'm doing something pretty similar right now for internal meetings and I use a process like: transcribe meeting with utterance timestamps, extract keyframes from video along with timestamps, request segmented summary from LLM along with rough timestamps for transitions, add keyframe analysis (mainly for slides).
gpt-4o, claude sonnet 3.5, llama 3.1 405b instruct, llama 3.1 70b instruct all do a pretty stunning job of this IMO. Each department still reviews and edits the final result before sending it out, but I'm so far quite impressed with what we get from the default output even for 1-2hr conversations.
I'd argue the key feature for us is also still providing a simple, intuitive UI for non technical users to manage the final result, edit, polish and send it out.
Figuring out how to customize something in a project like LangChain is positively Byzantine.
- https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderb...
> Although there are physicists who wonder “Why did we even need to do this experiment; we all knew that antimatter has positive mass,” that sentiment is absolutely foolish. We must remember — and I say this as a theoretical physicist myself — that physics is 100% an experimental science. We can be confident in our theory’s predictions only insofar as we can test and measure what it predicts; as soon as we step outside of the realm of what’s been validated by experiment, we run the risk of stepping outside the realm of where our theory is valid. We just learned that Einstein’s general relativity passed another test, the antimatter test, and with it, our greatest science-fiction hope for achieving warp drive has completely evaporated.
But a multi-modal database that also supports embeddings in hybrid mode or _in addition_ to standard retrieval techniques is both still very useful, and probably sufficient.
What that means to me is that it is yet another vote in favor of less optimized but far more versatile and robust solutions like: OpenSearch, Elastic, and PostgreSQL. [when I say 'less optimized' I'm only referring to their current vectordb plugins, not the rest of the machinery]
OpenSearch and Postgre are phenonemal, robust, OSS tools and the only lingering downside seems to be that their vectordb implementations are still a bit less optimized for large collections - but that probably doesn't matter in practice.
Edit: Business APIs and payment fees is apparently the answer. I'm genuinely impressed I've been able to use it all these years for free without ever having a hint of this.
The relentless march towards obsolescence is hard to stop.