u/JasonReed1

Picked these up after going back and forth for a while. Replaced a pair of Z623s that were getting on my nerves. Desk is small, sitting maybe 3 feet away.

First impression was honestly underwhelming. They sounded thin out of the box and I was kind of regretting it. Took maybe a week before I stopped noticing. Probably my ears recalibrating after years of the Logitech bass shelf, not break in.

Stuff I like: vocals sit better, no more sub box under the desk eating leg room, the remote is dumb but I use it more than I thought. Wood vinyl looks fine in person.

Stuff that's been a slight letdown: at low volumes they kind of disappear. Like if I want background music while reading they need to be turned up more than feels right for an apartment. Maybe that's just how speakers this size work, the Z623s with the sub had presence at low volume even if the bass was sloppy.

Bluetooth is bad. Everyone said it would be. They were right. 3.5mm from the PC works fine.

No regrets overall, just calibrating expectations.

Inheriting things you didn't build is a normal part of this job, but inheriting an unstructured ETL designed without operational thinking is its own special hell.

Background. Our internal RAG system was set up about 14 months ago by an ML engineer who has since left the company. Smart guy, did good work on the model and retrieval side. But the ingestion pipeline he set up reflects what someone optimizes for when they're trying to win a demo, not what someone optimizes for when they're going to be paged at 2am about it.

Specifics. The chunking strategy is a custom recursive splitter with about a dozen configured separators tuned to our specific document mix at the time. PDFs, DOCX, Confluence exports, some scraped HTML. Chunk size 750, overlap 150, except for legal docs where it's 1200/200, except for tables which get extracted separately and have their own splitter. Embedding model is fine. Vector store is fine. Reranker is fine.

The chunking config is what's killing me. Three problems:

First, it has no version. The splitter logic lives in a Python module that's been edited maybe 30 times across 14 months with no migration story. If I change a separator, do I re-chunk and re-embed every doc? Currently the answer is "we re-chunk new docs with new logic and old docs keep their old chunks forever." This means the index is a stratified mess of chunks produced under different rules. Nobody on the AI side noticed. I noticed because I'm the one writing the lineage queries.

Second, the per-doctype overrides are undocumented. Why 1200/200 for legal? I don't know. The original engineer's commit message says "legal needs more context." Cool. Is that still true? Has anyone tested it lately? No idea.

Third, there's no eval set tied to chunking choices. So if I change the splitter to something more sane, I have no way to prove it didn't make retrieval quality worse. I'd be flying blind through a change to a load-bearing config.

What I want to do is rip the whole thing out and replace it with something boring. One splitter, one chunk size, document type stored as metadata, recency stored as metadata, let the retrieval layer handle the rest. But that requires a full re-embed of the corpus, which is its own project, and it requires building an eval set first so I can measure the change, which is another project.

The bit I keep getting stuck on is the eval question. Hard to argue for fixing something when you can't measure whether your fix made it better, and I haven't found a path to a defensible eval set that doesn't eat months.

Still chewing on whether this is worth advocating for or whether it's just debt the company is fine carrying.