5 ms·

It's just a different kind of data. Even without LLMs, sometimes I want a tutorial, sometimes I want the raw API specification. For some cases I absolutely pre

It's just a different kind of data. Even without LLMs, sometimes I want a tutorial, sometimes I want the raw API specification. For some cases I absolutely prefer an LLM, like discoverability of certain language features or toolkits. But for the details, I'll just google the documentation site (for the new terms that the LLM just taught me about) and then read the actual docs.

ethbr1 2y ago
Search is best viewed as a black box to transform {user intention} into {desired information}. I'm hard pressed to construction an argument where, with widely-accessible LLM/LAM technology, that still looks like: 1. User types in query 2. Search returns hits 3. User selects a hit 4. User looks for information in hit 5. User has information Summarization and deep-indexing are too powerful and remove the necessity of steps 2-4. F.ex. with the API example, why doesn't your future IDE directly surface the API (from its documentation)? Or your future search directly summarize exactly the part of the API spec you need?
- skydhash 2y ago
  I don't know the exact word for this case, but sometimes you want the surrounding information to what you're looking for. Often I skim documentations, books, articles,... not in search for a specific answer but to get the overview of what it discusses. I don't need a summary of a table of contents. But it's a very good tool for quickly locating some specific information. Something like Language Implementation Patterns (the book) |> Analyzing Languages (the part) |> Tracking and Identifying Program Symbols (the chapter) |> Resolving Symbols (the section) or Unit Testing: Principles, Practices,and Patterns (the book) |> Making your tests work for you (the part) |> Mocks and test fragility (the chapter) |> The relationship between mocks and test fragility (the section) |> Intra-system vs. inter-system communications or Python 3.13.3 Documentation (docs.python.org) |> The Python Standard Library |> Text Processing Services |> string
- theamk 2y ago
  Could never understand that obsession with summmarization. Sure, it may be be useful for long-form articles or for low-quality content farms, but most of the time you are not reading those. And if you are reading technical docs, especially good ones, each word is there for a reason. LLM throw some that information away, but they don't have your context to know if the stuff they throw away is useful or not. The text the summary omitted may likely contain an important caveat or detail you really should have known before starting to use that API.
  - skydhash 2y ago
    And if you go to a nicely formatted doc page (laravel) or something with diagrams (postgres), it throws all of these away too.

ethbr1 2y ago

Search is best viewed as a black box to transform {user intention} into {desired information}. I'm hard pressed to construction an argument where, with widely-accessible LLM/LAM technology, that still looks like: 1. User types in query 2. Search returns hits 3. User selects a hit 4. User looks for information in hit 5. User has information Summarization and deep-indexing are too powerful and remove the necessity of steps 2-4. F.ex. with the API example, why doesn't your future IDE directly surface the API (from its documentation)? Or your future search directly summarize exactly the part of the API spec you need?

skydhash 2y ago
I don't know the exact word for this case, but sometimes you want the surrounding information to what you're looking for. Often I skim documentations, books, articles,... not in search for a specific answer but to get the overview of what it discusses. I don't need a summary of a table of contents. But it's a very good tool for quickly locating some specific information. Something like Language Implementation Patterns (the book) |> Analyzing Languages (the part) |> Tracking and Identifying Program Symbols (the chapter) |> Resolving Symbols (the section) or Unit Testing: Principles, Practices,and Patterns (the book) |> Making your tests work for you (the part) |> Mocks and test fragility (the chapter) |> The relationship between mocks and test fragility (the section) |> Intra-system vs. inter-system communications or Python 3.13.3 Documentation (docs.python.org) |> The Python Standard Library |> Text Processing Services |> string
theamk 2y ago
Could never understand that obsession with summmarization. Sure, it may be be useful for long-form articles or for low-quality content farms, but most of the time you are not reading those. And if you are reading technical docs, especially good ones, each word is there for a reason. LLM throw some that information away, but they don't have your context to know if the stuff they throw away is useful or not. The text the summary omitted may likely contain an important caveat or detail you really should have known before starting to use that API.
- skydhash 2y ago
  And if you go to a nicely formatted doc page (laravel) or something with diagrams (postgres), it throws all of these away too.