I've been digging into how different platforms handle custom chatbots for internal docs, especially since we manage a lot of kernel troubleshooting guides and performance runbooks. The idea of a low-overhead, always-available internal assistant is pretty appealing, so I gave Writesonic's Botsonic a spin to build one.
The setup is mostly point-and-click, but the interesting bits are in the "knowledge" configuration. You feed it documents (PDFs, text, even web links), and it creates embeddings. For our use case, I uploaded a mix of markdown files from our internal wiki (mostly performance tuning guides and syscall documentation).
Here's a snippet of the kind of structured data it handled well, from a `bpf_trace.md` file I included:
```markdown
# Monitoring syscall latency with eBPF
- Use `tracepoint:syscalls:sys_enter_*` and `tracepoint:syscalls:sys_exit_*`.
- Calculate delta between enter and exit events.
- Consider overhead: each probe adds ~1-2µs.
```
The bot correctly answered questions about estimated overhead and which tracepoints to use, pulling directly from that doc.
A few things I noticed from a system perspective:
* The ingestion process is asynchronous. Upload a doc, and it takes a minute or two to process. Would be nice to have a webhook or callback when it's done.
* There's a hard limit on file sizes and counts depending on your plan. We hit the limit quickly with our documentation repo.
* The "train on website data" feature is handy, but it seems to crawl only publicly accessible pages. For internal wikis, you still need to export and upload.
The real test was asking it nuanced questions like: "What's the difference between `strace` overhead and eBPF overhead for monitoring `openat` calls?" It synthesized info from three different documents to give a coherent answer about context switches vs. in-kernel filtering.
Has anyone else tried building a technical/internal knowledge bot with this or similar tools? I'm particularly curious about:
* How it handles conflicting information in source documents.
* The actual retrieval latency – feels sub-200ms, but I haven't measured it properly.
* Whether you can point it at a git repository directly for auto-syncing.
System calls per second matter.