outputparser: add `Defined` parser to extract a struct from LLM output

[erictse]

This introduces an output parser named 'Defined' as an improvement to the existing output parser 'Structured'.

A developer can define a struct with the proper tags which can generate a description of the desired output format for an LLM. The parser then returns a struct of the given type, populated with the data it extracted. The developer experience parallels what's described in this Build an Extraction Chain tutorial.

For best results, use this with the tool calling feature of your LLM.

Fixes https://github.com/tmc/langchaingo/issues/171 and https://github.com/tmc/langchaingo/issues/197

PR Checklist

• [x] Read the Contributing documentation.
• [x] Read the Code of conduct documentation.
• [x] Name your Pull Request title clearly, concisely, and prefixed with the name of the primarily affected package you changed according to Good commit messages (such as memory: add interfaces for X, Y or util: add whizzbang helpers).
• [x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• [x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. Fixes #123).
• [x] Describes the source of new concepts.
• [x] References existing implementations as appropriate.
• [x] Contains test coverage for new functions.
• [x] Passes all golangci-lint checks.

[erictse]

@tmc I've addressed the linter issues, but the tagalign issues remain for my test file. This feature may mean looking into disabling the tagalign linter may be more worthwhile. It wants to force reordering the json: struct tag key so it appears after describe:, reducing readability.

[erictse]

@FluffyKebab Hi, do you have any feedback on this PR for me? Haven't heard from anyone yet.

[erictse]

@eliben Sorry if I'm barking up the wrong tree. I'm not sure who should be reviewing/accepting PRs. Either way, do you have any feedback on this?

[eliben]

@erictse this isn't an area of langchaingo I was working on, so I think you'll have to wait for @tmc to review.

[erictse]

@tmc I've addressed your comments, including allowing untagged struct fields.

[tmc]

I like this broadly, but can’t help but think this represents a limited subset of what we might encode via https://github.com/invopop/jsonschema — which could be reused to handle tool reprs.

thoughts?

[erictse]

Using struct tags to generate JSON Schema looks promising! It should probably be on the roadmap.

However, here are reasons for not dropping this pull request:

• More is better (in the unpredictable world of LLMs). Some models may lack or be weaker at JSON Schema support than others. The developer can decide which structured data extraction approach is best for their situation.
• Easier to use. JSON Schema is more complex, which can take folks longer to work with. This feature is comparable to Pydantic classes, and for developers coming from Python, the concept would be familiar.
• Feature parity. LangChain supports both Pydantic classes and JSON Schema. See LangChain doc.
• Faster/cheaper(?) This is speculative, but JSON Schema is more verbose and complex–if it does happen to be more resource intensive for some models, having another approach is helpful.

[tmc]

That's all fair, let's do it!

Can you follow on with an example and some docs?