4 ms·
I work at a company with an LLM-adjacent tool. The best solution we could find for this problem was a combination of a Wiki + "Saved Programs" (executable scri
by gavinray 4mo ago
I work at a company with an LLM-adjacent tool.
The best solution we could find for this problem was a combination of a Wiki + "Saved Programs" (executable scripts).
When you ask a question, the system does a fuzzy Wiki search to see if any topic has relevant info. Wiki links serve as "graph edges" that form a Knowledge Graph.
So lets say I ask "What products from the FOOBAR API sold least last month?"
The agent would look up "FOOBAR API", and then write a script to call the "products" endpoint with a date range + SQL fetch from "sales" DB and do whatever it needs to do.
If none of this info exists (URL to FOOBAR, location of "sales" data), the agent asks for more info and offers to update the wiki for future.
- nimonian 4mo agoVery close to this at my company. We have docs each of which having its description in the yaml. An MCP tool lists the doc sections, a full section with its descriptions, or the entire contents of a doc. A kind of progressive disclosure. Works really well. We even write "skills" this way so they can be used in all our chat environments.
- xtiansimon 4mo agoDoes this solution use a private/local LLM or something else? Sorry if the answer is obvious. I’ve just started considering this for an internal wiki to my company.
- gavinray 4mo agoWe use Opus/Codex models
- smcleod 4mo agoSimilar conclusion I've come to. For all the complex RAG and many SaaS startups selling knowledge engines - what we keep falling back to is simple a wiki (markdown) + simple tools to solve problems and help answer questions programmatically where possible. Cheap, fast, low complexity and no lock-in.