To your q, I make huge effort in making my prompts as small as possible (to get the best quality output), I go as far as removing imports from source files, writing interfaces and types to use in context instead of fat impl code, write task specific project / feature documentation.. (I automate some of these with a library I use to generate prompts from code and other files - think templating language with extra flags). And still for some tasks my prompt size reaches 10k tokens, where I find the output quality not good enough

This specific case worked well, I suspect, since LLMs have a LOT of previous knowledge with HTML, and saw multiple impl and parsing of HTML in the training.

Thus I suspect that in real world attempts of similar projects and any non well domain will fail miserably.

Comments URL: https://news.ycombinator.com/item?id=44795894

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44774524

Points: 7

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=43228735

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42952960

Points: 582

# Comments: 46

Comments URL: https://news.ycombinator.com/item?id=41943313

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41785087

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41679563

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41107250

Points: 4

# Comments: 0

Would be really helpful if you opened an issue in Github with a specific example, happy to look into that!

1. there some crazy links with lots of arguments and tracking stuff in them, so it gets very long, the refification turns them into a numbered "ref[n]" scheme, where you also get a map of ref[n]->url to do reverse translation.. it really saves a lot, in my experience. It's also optional, so you can be mindful when you want to use this feature..

2. I tried to keep it domain specific (not to reinvent HTML...) so mostly Markdown components and some flexibility to add HTML elements (img, footer etc).

3. Not sure I'm sold with replacing the switch, it's very useful there because of the many fall through cases.. I find it maintainable but if you point me to some specific issue there it would help

4. There are some built in functions to traverse and modify the AST. It is just JSON in the end of the day so you could leverage the types and write your own logic to parse it, as long as it conforms to the format you can always serialize it, as you mentioned..

5. The AST is recursive so not flat.. sounds like you want to either write your own AST->Semantic-Markdown implementation or plug into the existing one so I'll this in mind in the future

6. Sounds cool but out of scope at the moment :)

7. This feature would serve to help with scraping and kind of point the LLM to some element? Then the part I'm missing is how you would code this in advance.. There could be some meta-data tag you could add and it would be taken through the pipeline and added on the other side to the generated elements in some way..